On Apr 27, 2010, at 10:30 PM, G.J. Parker wrote:
installed two versions of meep-mpi (0.20.3 and 1.1.1). they both use
the same prerequisite packages (fftw, harminv, guile, libctl,
openmpi & parallel hdf) w/ gcc 3.4.4 (RHEL 4.2)
both versions take the same ctl file that defines a 3d structure and
saves the reflected and transmitted flux. the execution time is
comparable.
re-running the same simulation but this time telling it to read in
the reflected flux (load-minus-flux), meep 1.1.1 takes significantly
longer to read the flux and is ~ 7x slower in execution speed (s/
step) than meep 0.20.3.
re-running the exact ctl file but commenting out the load-minus-flux
command, meep 0.20.3 is fast again.
That's very odd! The only thing that comes to mind is some kind of
floating point exception (arithmetic with underflow/overflow/NaN is
much slower), although I don't understand how that could differ
between the two versions of Meep. You can force Meep to crash when
there is a floating point exception by editing src/mympi.cpp to change
the line
#if defined(DEBUG_FP) && defined(HAVE_FEENABLEEXCEPT)
to
#if 1
Does this occur when running on a single processor? On a single
processor, it is relatively easy to run under a debugger (gdb) to find
out where/whether floating-point exceptions arise (instead of crashing
with the above line, it will halt in the debugger). (You will want to
configure Meep with --enable-debug in order to compile with debugging
flags.)
Steven
_______________________________________________
meep-discuss mailing list
meep-discuss@ab-initio.mit.edu
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
