On Wed, Oct 19, 2011 at 8:06 PM, Nicolas Bock <address@hidden
> Hi Jose,
> let me add to what Matt said, that we are seeing this compiler problem here
> as well. We usually work around it the same way you did, by turning off all
> compiler optimizations (-O0). I had put something along those lines into the
> makefiles, but it sounds like that this work around is broken right now. I
> will have a look at the makefiles and see why.
> Please let us know if you run into any other problems.
> On Wed, Oct 19, 2011 at 16:44, Matt Challacombe <address@hidden
>> Hi Jose,
>> You've been busy ... and done well. Briefly, FreeON should be pretty
>> with MPI for parallel clones -- that is MPI enabled NEB band
>> Generalized MPI, that is within a single configuration or clone is broken
>> though, and
>> will not be supported in this current instantiation. We are in process of
>> re-writing many of the algorithms in FreeON and their parallel
>> implementation rather
>> than trying to maintain outdated paradigms.
>> However, we are using the current version to do biochemical calculations
>> on the 300-500
>> atom level (NEB), and it is quite stable at this level of parallelism,
>> giving what I consider
>> a reasonable turn around at the "good" level of accuracy (about 7 digits
>> in total energy).
>> If that seems like the kind of capability you are looking for, we are more
>> happy to try to support your efforts. Maybe you've sent us the info in
>> your e-mail, but if
>> you could let us know in future, what is your gcc, kernel version # etc.
>> All the best, Matt and Nick
>> PS. Also feel free to write back to me at this e-mail.
>> On Wed, Oct 19, 2011 at 2:15 AM, Jose R. Valverde <address@hidden
>>> Hi all,
>>> I am trying to compile freeON with (some) MPI support. I know.
>>> Anyway, when I use --enable-parallel-clones it breaks compiling
>>> Ktrax-preprocessed.f, which being just a huge list of trivial assignment
>>> statements it shouldn't. The reason given is that the compiler runs out
>>> of virtual memory. This is likely unrelated to freeON, as this machine
>>> has 72GB RAM and when the compiler breaks it has allocated only about
>>> 2.9Gb of them.
>>> Now, this looks in all respects as a problem with the optimizer,
>>> and indeed, if I compile the file manually turning off all specific
>>> optimization options, it compiles OK and the build proceeds:
>>> mpif90 -g -O2 -march=native -I. -I../Modules -I. -I..
>>> -I../OneE -I../Modules/MMA/LookUpTables_800_6x -c -o KTrax.o
>>> instead of
>>> mpif90 -g -O2 -march=native -msse -msse2 -mfpmath=sse
>>> -ffast-math -ftree-vectorize -pipe -ffixed-line-length-none -I.
>>> -I../Modules -I. -I.. -I../OneE
>>> -I../Modules/MMA/LookUpTables_800_6x -c -o KTrax.o
>>> I haven't tried many combinations to see which is the exact compiler
>>> flag causing this behavior, but I guess while this may be a bit slower,
>>> it will still work and be not too bad (-O2 remains).
>>> Well, the compilation is going on now, and once it is finished
>>> I'll run the validation checks and let you know, but in principle it
>>> should pass.
>>> Scientific Computing Service
>>> Solving all your computer needs for Scientific