AMBER Archive (2008)

Subject: Re: AMBER: Compilation of amber8 patched with ramd

From: Francesco Pietra (chiendarret_at_gmail.com)
Date: Tue Jun 24 2008 - 16:52:09 CDT

Running the general serial test for amber8, all PASSED except
newton_raph (forrtl: severe (174) segmentation fault). That likely
because no bugfix was applied (and it can't) to amber8 before patching
with ramd. I was unable to trace what newton_raph is expected to do,
so that may I ask whether this is a problem for running ramd? To this
concern:

./Run.ramd
diffing mdout.ramd.save with mdout
PASSED

Can I safely pass to parallel compilation?

Thanks
francesco

On Tue, Jun 24, 2008 at 6:28 PM, Francesco Pietra <chiendarret_at_gmail.com> wrote:
> OK, renouncing to the MKL libraries, led to a correct (serial)
> compilation. Actually, it was my fault not to do that before as I am
> not going to use qmmm with Amber8 and MKL libraries give problems (on
> my platform, in parallel) for qmmm even in Amber10
> Thanks
> francesco
>
> On Tue, Jun 24, 2008 at 5:07 PM, Vlad Cojocaru
> <Vlad.Cojocaru_at_eml-r.villa-bosch.de> wrote:
>> Dear Francesco ,
>>
>> Below is a summary of the bugfixes that interfere with the RAMD patch. We
>> are studying the problem but for now we can only recommend compiling AMBER8
>> with the RAMD patch without these bug fixes. I know this is not ideal. Maybe
>> you should also compile the AMBER8 without the MKL libraries since anyhow
>> you'll use it just for the RAMD runs.
>>
>> As for porting RAMD to Amber 10. We definitely consider it. For now, the
>> limiting factor is my lack of experience with Fortran and parallel
>> computing.
>>
>> Good Luck,
>> Vlad
>>
>> -------------------------------------------------SUMMARY RAMD and AMBER8
>> BUGFIXES (message from our
>> administrator)----------------------------------------------------------------------------
>> The following patches are towards force.f, sander.f and runmd.f and might
>> interfere with the ramd patch:
>>
>> http://amber.scripps.edu/bugfixes80.html
>>
>> force.f
>> bugfix.33 <http://amber.scripps.edu/bugfixes/8.0/bugfix.33>: The forces for
>> "cap" water are not accompanied by a corresponding energy term. /(See also
>> bugfixes 40, 43 and 45, below
>>
>> sander.f
>> /bugfix.7 <http://amber.scripps.edu/bugfixes/8.0/bugfix.7>: Using a
>> restraintmask or a bellymask that invokes distance comparisons will fail.
>> bugfix.13 <http://amber.scripps.edu/bugfixes/8.0/bugfix.13>: Several fixes
>> to sander.QMMM
>> bugfix.47 <http://amber.scripps.edu/bugfixes/8.0/bugfix.47>: Fixes MPI calls
>> in /sander/ when the /noBTREE/ is set during compilation.
>> bugfix.52 <http://amber.scripps.edu/bugfixes/8.0/bugfix.52>: Manual setting
>> of /lastrst/ needs to be allowed for regular Ewald simulations.
>>
>> runmd.f
>> bugfix.25 <http://amber.scripps.edu/bugfixes/8.0/bugfix.25>: Langevin
>> dynamics will fail when the target temperature is changed during the run.
>> bugfix.32 <http://amber.scripps.edu/bugfixes/8.0/bugfix.32>: The /mden/ file
>> can contain a bad value for pressure when the pressure is not being
>> regulated.
>> bugfix.54 <http://amber.scripps.edu/bugfixes/8.0/bugfix.54>: The /ntt=2/
>> option in sander can result in average temperatures that are too high.
>> bugfix.56 <http://amber.scripps.edu/bugfixes/8.0/bugfix.56>: Update to
>> bugfix.54, which failed to work properly in parallel.
>>
>> Some of the above might still be possible to patch together with the ramd
>> patch. But this i did not test.
>>
>> I would recommend to only select the patches from the bugfixes page that are
>> needed. If one of the above bugfixes are needed, we need to have a look at
>> the differences in the patches?
>> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>>
>> Francesco Pietra wrote:
>>
>> I am trying to compile (serial) amber8 - patched with contributed
>> software RAMD - on a UMA type dual opetron machine, Debian Linux lenny
>> amd64.
>>
>> The RAMD patch, which only modifies sander
>> (http://projects.eml.org/mcm/software), has to be applied before any
>> bugfix is applied to amber8 (although, perhaps, bugfix not related to
>> sander might have been applied; not tried; I just tried bugfix.all and
>> it prevented the RAMD patch to be applied)
>>
>> Now
>> $ ./configure ifort
>> AMBERHOME set to /usr/local/amber8
>> Setting up for architecture ifort
>> MKL_HOME is set to /opt/intel/mkl/10.0.1.014/
>> Using MKL libraries from /opt/intel/mkl/10.0.1.014/lib/32
>> Using parallel communication library: none
>> config.h created successfully
>>
>> $ make serial
>>
>> gave error:
>> ifort -o addles lesmain.so addspace.o readprm.o writprm.so readcrd.o
>> writcerd.o pick.o rline.o nxt.o intgr.o find.o of.o geti.o unit.o
>> getc.o alert.o echo.o get4c.o getd.o wlesprm.o lesprm.o les2prm.o
>> checksz.o ../lib/random.o ../lib/mexit.o ../lib/nxtsec.o
>> -L/opt/intel/mkl/10.0.1.014//lib/32 -lvml -lmkl_lapack64 -lmkl -lguide
>> -lpthread
>>
>> ld: skipping incompatible
>> /opt/intel/mkl/10.0.1.014/lib/32/libmkl_intel.so when searching for
>> libmkl_intel.so
>>
>> ld: cannot find libmkl_intel,so. Actually this is present where it was
>> searched. Thus incompatibility?
>>
>>
>> serial error 2
>>
>>
>> Is it known (or imaginable) if the the problem is raised by having
>> patched sander with ramd, or these mkl libraries (which I used for
>> both amber10 and dock6.2) are too new for amber8 (not bugfixed)
>> anyway? In the first case I could try by commenting out MKL_HOME in my
>> .bashrc.
>>
>> I am in contact with the German group for RAMD, too. However,
>> presently there is no one capable of adapting RAMD to current times.
>>
>> It is clear that my only interest with amber8 if to have it running
>> patched with RAMD. Otherwise I have both amber10 and amber9 installed.
>> In a way, my question is a jump into the past.
>>
>> Thanks
>>
>> francesco pietra
>> -----------------------------------------------------------------------
>> The AMBER Mail Reflector
>> To post, send mail to amber_at_scripps.edu
>> To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
>> to majordomo_at_scripps.edu
>>
>>
>>
>> --
>> ----------------------------------------------------------------------------
>> Dr. Vlad Cojocaru
>>
>> EML Research gGmbH
>> Schloss-Wolfsbrunnenweg 33
>> 69118 Heidelberg
>>
>> Tel: ++49-6221-533266
>> Fax: ++49-6221-533298
>>
>> e-mail:Vlad.Cojocaru[at]eml-r.villa-bosch.de
>>
>> http://projects.villa-bosch.de/mcm/people/cojocaru/
>>
>> ----------------------------------------------------------------------------
>> EML Research gGmbH
>> Amtgericht Mannheim / HRB 337446
>> Managing Partner: Dr. h.c. Klaus Tschira
>> Scientific and Managing Director: Prof. Dr.-Ing. Andreas Reuter
>> http://www.eml-r.org
>> ----------------------------------------------------------------------------
>>
>>
>
>
>
> --
> Dr Francesco Pietra
> Professor of Chemistry
> Accademia Lucchese di Scienze, Lettere e Arti, founded in 1594
> Palazzo Ducale
> 55100 Lucca (Italy)
> 

-- 
Dr Francesco Pietra
Professor of Chemistry
Accademia Lucchese di Scienze, Lettere e Arti, founded in 1594
Palazzo Ducale
55100 Lucca (Italy)
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber_at_scripps.edu
To unsubscribe, send "unsubscribe amber" (in the *body* of the email)
      to majordomo_at_scripps.edu