AMBER Archive (2009)

Subject: Re: [AMBER] pmemd compile error....

From: Robert Duke (rduke_at_email.unc.edu)
Date: Tue Mar 24 2009 - 07:19:45 CDT

Sorry, there is just not enough new info to go on here, to be able to help
you. I strongly suspect you are mixing 32 and 64 bit code (ie. your
executables are one type and some library you call is the other), but I
don't know for sure. You may be able to get some help from your hp folks;
you may have to look at how other applications build; but clearly you are
doing something wrong in the build process. There is every reason to
believe that pmemd and sander will both run fine, but you have some serious
detective work to do to figure out how to build applications on this
machine. When you try to build pmemd or sander, in uniprocessor mode,
configure "out" as much extraneous stuff as possible - so don't include math
libraries or netcdf, for instance, until you get something working. Be sure
to use the public fft's with pmemd. Basically, you want to start with the
minimum of external stuff that you can, get that working, and then add
things if you need them. You are running uniprocessor sander and pmemd
outside the mpi startup mechanism, right?
Regards - Bob
----- Original Message -----
From: "Yiannis Georgiadis" <giannis_at_cc.uoa.gr>
To: "AMBER Mailing List" <amber_at_ambermd.org>
Sent: Tuesday, March 24, 2009 4:10 PM
Subject: Re: [AMBER] pmemd compile error....

> Dear Bob
>
> I didn't managed to run uniprocessor sander nor pmemd
> sander gives segmentation fault and pmemd is stopped with
> "STOP PMEMD Terminated Abnormally"
> a message existed in pmemd_lib.f90 code
>
> I found references on segmentation fault runnings
> when we call c routines from fortran
> as http://docs.hp.com/en/B3909-90002/ch04s05.html says
>
> any suggestion ?
>
> Yiannis Georgiadis
>
>
>
>
>
> Robert Duke wrote:
>> Hmmm. Insufficient information. For some reason, mpi initialization
>> seems to be failing in the 7th task. This may be a myriad of things, but
>> I would tend to suspect some sort of library or compilation problems. If
>> I were dealing with this personally, I would do the following:
>> 1) Take a known simple testcase - say the JACS benchmark.
>> 2) Compile the uniprocessor version of pmemd and run it on this machine -
>> any problems?
>> 3) If not, compiler sander or mpi test code on this beast - does sander
>> run the problem okay? There could be all kinds of "interesting" library
>> and mpi issues.
>> 4) If all that works, recompile parallel pmemd, but set F90_OPT_DFLT to
>> $(F90_OPT_DBG). This may give you a coredump from which you can get more
>> info.
>>
>> It looks to me like you are not even getting through mpi initialization
>> here, which basically says it is not a pmemd problem, per se, but
>> something about how you are compiling/linking in this environment. I
>> really don't know though, given the limited info.
>>
>> Oh one thing. You say you "recompiled with 64bit compiler because the HP
>> supercomputer has more than 1 GB stack limit". Okay, BAD move. You
>> absolutely don't want to be matching 32 and 64 bit code unless the mixing
>> is supported by the libraries, and generally there are libraries that
>> will be used for a 32 or 64 bit executable. You simply can't get into
>> memory problems with pmemd on a 32 bit executable with more than say 4
>> processors, and it costs typically at least 5% to go into 64 bit mode due
>> to the expansion of code/data associated with the use of 64 bit instead
>> of 32 bit pointers. So if you dinked with the build params, undink. The
>> pmemd code works on some systems with a 64 bit build (like ibm aix) but
>> it is slower, and tricky to get linked right, and can die in various
>> nasty hard to diagnose ways. So "64-bit good, 32-bit bad, is highly
>> faulty logic". It is only good to use 64 bits if you have massive
>> amounts of data, and you don't. Attached is a graphic showing resident
>> memory requirements of pmemd (on 4 processors), and the stack memory is a
>> small fraction of the total memory used. And note, you can't run
>> problems larger than 999,999 atoms with pmemd, but that is a file format
>> problem, not a memory usage problem. Now you CAN get into memory
>> problems with pmemd, but it requires 1) running on 1 or a very few
>> processors, 2) using a really large problem - multiple 100's of thousands
>> of atoms, AND 3) setting the cutoff to something like half the boxsize -
>> then the pairlist will be just huge, and you can blow up on that. Be sure
>> to use an 8 or 9 angstrom cutoff in pmemd running pme - very little in
>> the way of good reasons to do otherwise.
>>
>> Hope this helps - Bob Duke
>> (getting any new system up that has not been previously configured can be
>> sort of a pain - sorry)
>>
>> ----- Original Message ----- From: "Giorgos Lamprinidis"
>> <lamprinidis_at_pharm.uoa.gr>
>> To: "AMBER Mailing List" <amber_at_ambermd.org>
>> Sent: Thursday, March 19, 2009 11:06 AM
>> Subject: [AMBER] pmemd compile error....
>>
>>
>> Duke,
>>
>>
>>
>> My colleague Giannis Georgiadis re-compiled pmemd with 64bit compiler
>> because our HP supercomputer has more than 1GB stack limit for 64bit
>> applications. We shall increase the stack limit for the 32bit version to
>> 400MB (this is the maximum) when he reboot the computer.
>>
>> The warning messages disappeared but the Terminated Abnormally errors are
>> still there without any other messages..
>>
>> ...................
>>
>> STOP PMEMD Terminated Abnormally!
>>
>> STOP PMEMD Terminated Abnormally!
>>
>> STOP PMEMD Terminated Abnormally!
>>
>> STOP PMEMD Terminated Abnormally!
>>
>> STOP PMEMD Terminated Abnormally!
>>
>> STOP PMEMD Terminated Abnormally!
>>
>> STOP PMEMD Terminated Abnormally!
>>
>> STOP PMEMD Terminated Abnormally!
>>
>> MPI Application rank 6 exited before MPI_Init() with status 0
>>
>> Failed sending message: (Unable to connect to socket (Connection
>> refused)).
>>
>> ....................
>>
>>
>>
>> Any suggestions plz?
>>
>>
>>
>> Dr George Lamprinidis
>> _______________________________________________
>> AMBER mailing list
>> AMBER_at_ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>>
>>
>> _______________________________________________
>> AMBER mailing list
>> AMBER_at_ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database:
>> 270.11.20/2013 - Release Date: 03/19/09 19:03:00
>>
>>
>
>
> _______________________________________________
> AMBER mailing list
> AMBER_at_ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>

_______________________________________________
AMBER mailing list
AMBER_at_ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber