Subject: review of C501: Parallelization of a Large-Scale Computational Earthquake Simulation Program From: "Jay W. Parker" Date: Fri, 15 Jun 2001 19:02:29 -0700 To: fox@csit.fsu.edu REFEREE'S REPORT Concurrency and Computation:Practice and Experience --------------------------------------------------------------------------- A: General Information Please return to: Geoffrey C. Fox Electronically Preferred fox@csit.fsu.edu Concurrency and Computation: Practice and Experience Computational Science and Information Technology Florida State University 400 Dirac Science Library Tallahassee Florida 32306-4130 Office FAX 850-644-0098 Office Phone 850-644-4587 but best is cell phone 3152546387 Please fill in Summary Conclusions (Sec. C) and details as appropriate in Secs. D, E and F. B: Refereeing Philosophy We encourage a broad range of readers and contributors. Please judge papers on their technical merit and separate comments on this from those on style and approach. Keep in mind the strong practical orientation that we are trying to give the journal. Note that the forms attached provide separate paper for comments that you wish only the editor to see and those that both the editor and author receive. Your identity will of course not be revealed to the author. C: Paper and Referee Metadata * Paper Number C501: * Date: June 15 2001 * Paper Title: Parallelization of a Large-Scale Computational Earthquake Simulation Program * Author(s): K.F. Tiampo , J.B. Rundle , S. Gross and S. McGinnis * Referee: Jay Parker * Address: 238-600 Jet Propulsion Laboratory/California Institute of Technology, 4800 Oak Grove Dr. Pasadena, CA 91109 Referee Recommendations. Please indicate overall recommendations here, and details in following sections. 1. publish as is xx>> 2. accepted provided changes suggested are made 3. reject D: Referee Comments (For Editor Only) I do find the extent of quoted "GA" code annoying, especially as it does not detail the "GA" part, but merely the parallelization of the chi-square or fitness function; see point 5 below. I suppose it becomes the editors choice whether to print it all or demand it be cut back. It is helpful to have a code example, but some can be reduced to a one-line description for code that bears on geophysics or instrument data input. Meanwhile the top-level code that implements the GA strategy is completely missing; I realize it's not where the "concurrency" is, but its lack makes the story feel incomplete. E: Referee Comments (For Author and Editor) This paper does not break fundamentally new ground in terms of algorithmic strategy, but it brings some of the parallelization issues for genetic algorthims and Green's function up to date in terms of current hardware available to a modest university effort. In addition it is significant in providing simple examples of parallel migration for workers in the earthquake field, which has few documented parallel applications to guide practitioners. I recommend publication in essentially the current form. There are some minor flaws, detailed below. F: Presentation Changes 1) The genetic algoritm description appears incomplete, or else difficult to follow. I could not determine what is the initial range of values for each parameter, and if the 100 levels for each remain static through the many generations, or if they become somehow adapted; if not, it is hard to see how solutions can ever get closer than 1% of the initial range. A sentence describing crossbreeding would also help, as well as if and how mutation (randomization?) is applied (are some fraction of the population assigned new random values at each step to ensure genetic richness? Or are all members -or just some- subject to random gene substitution? ) I realize some of that is in the references, but those contain many variant techniques and (I expect) undetermined strategic parameters that guide the algorithm. These should be called out in an unambiguous way, with some explanation as to how one selects good details. Similarly, the top-level GA code is missing, but should be included (or covered schematically, as you do for the Virt. Calif. code.) 2) Just prior to Eq. 2 appears the variable "N". It is not immediately clear if this is the number of fault segments, or the number of stress coefficients, or if these are the same. Since your faults are all vertical with purely horizontal slip, I suppose they are the same; but the text could be clearer with a very slight modification. 3) Figure 4 is confusing; I see no output from EQ_Simulator.c. Some minor rearrangement might help, and perhaps a brief expansion of the caption, to the effect that kinematic and stress greens function modules enable deformation and fault-failure (respectively) in the simulation. 4) The B.1.2 pseudocode appears wrong, in that time is updated inside the loop over segments (N). I suspect the time update should be in the next loop up. Is "time" the same as "t"? 5) It is not clear to me that so much detailed (GA) deformation code is helpful; are two versions of "fit" and such functions as "read_field_data" and "uxsph" worthy of taking up paper? I don't insist on the point, but if the editor wishes to save space, I raise the question. 6) The pseudocode appears to indicate you divide the greens function problem by partitioning the fault system segments among the processors, by dealing each out to available resources. So each processor has the geometry for the full problem, and the master processor collects all the results. This is a plausible strategy so long as the problem fits in single-processor memory, but may not scale to the ultimately possible sizes. Similarly your EQ simulator appears to partition over those segments that fail at a given step. If that's correct, it would be helpful to the reader to say so in another paragraph or two under section 4.3. In particular it helps to say what is the principal used to partition the full problem over processors. Then a few words as to why this strategy was chosen, and how you expect it to work out for much larger problems. If you can say anything definite about load balance and communication, that also aids the reader's intuition.