Gustavo,
Do you mind running the parallel tests and see if you are getting
similar failures as the following:
(1) test.sander.BASIC.MPI
(2) test.sander.GB.MPI
(3) test.sander.LES.MPI
(4) test.sander.QMMM.MPI
(5) test.sander.PIMD.MPI
All failures gave stdout error similar to the following:
rm_l_1_1573: (0.332031) net_send: could not write to fd=5, errno = 32
p0_1536: (2.523438) net_send: could not write to fd=5, errno = 32
I think the above tests are fundamentally serial jobs but running under
an MPI environment. I really have not done much digging within the test
scripts, though ... so I am guessing. Thanks for your help.
-Kim
Gustavo Seabra wrote:
> On 10/11/06, David A. Case <case.scripps.edu> wrote:
>> On Wed, Oct 11, 2006, Gustavo Seabra wrote:
>>
>> > I just checked out a clean copy of amber, and compilatin fails due to
>> > F95 compatibility problems. I attach here the compilation output and
>> > my config.h file. Although this is a mpi compilation, I get the same
>> > errors with serial.
>> >
>>
>> Seems like these errors are pretty easy to correct -- please just do so.
>>
>
> I needed sander running asap, so I went ahead and followed Dave's
> suggestion. Apart from the sander/schlegel_dg.f file which was
> corrected by Kim Wong, there were similar errors in a number of other
> files inside sander and dcqtp, which were stopping compilation. I
> corrected those old '$' suppress-newline formats in those files. (I
> hope the official maintainers won't mind...). The new files are on the
> tree now, and compile well (at least for me.)
>
> For those interested, the changes I did were, in ALL cases, to replace
> the '$' in a write statement by a ADVANCE='NO' :
>
> write (6,'(<<FORMAT>>,$)') ==> write (6,'(<<FORMAT>>)', ADVANCE='NO')
>
> Judging by the 'warnings' the compiler gives, there are a number of
> syntaxes that have disappeared in F95 that are still present. I have
> no idea why the compiler chose just this one as fatal.
>
> Gustavo.
> P.S.: The reason I went to get a new tree was that, before, I was only
> 'updating' my local copy, and at some point some calculations started
> to segfault with no apparent reason. It turned out to be one of those
> files being compiled with the old config.h: It compiled, but segfaults
> unpredictably. (My point here is that, even if the compiler didn't
> pick, we may get strange segfaults if we've been just updating for a
> while, as I was.)
Received on Thu Oct 12 2006 - 20:36:10 PDT
