Hi Ross,
I will re-run my calculations.
Cheers,
Oliver
---------- Forwarded message ----------
From: Ross Walker <ross.rosswalker.co.uk>
Date: 2011/7/21
Subject: Re: [AMBER] Fwd: Periodicity in MD simulations
To: AMBER Mailing List <amber.ambermd.org>
Hi Oliver,
> I have found out that the oscillation artifacts stem from using
>
> mpirun -np 4 pmemd -O ...
>
> instead of
>
> mpirun -np 4 pmemd.MPI -O ...
>
> The first command creates four equal threads all writing to the same
> outputfiles I think, and I wonder why the results are not totally
> messed up,
Yes this is correct, all 4 threads run in serial with no knowledge of each
other, all writing to the same files. Depending on how your filesystem works
depends on how this behaves. If it supports locking then you will get
individual frames written by whichever thread tries to make the write to
mdcrd first. In summary thought the results will be incorrect and unusable..
> but MMPBSA calculation works fine on this data (giving comparable
> results to
> uncorrupted data).
This is mostly a function of the way MMPBSA works. It simply needs
uncorrelated trajectories representing a correct ensemble of states. This is
mostly what you get here since you have 4 trajectories that are all
independent giving you a trajectory file of mixed states. Hence you have
exactly what you need for MMPBSA. I would not trust it though and you should
probably re-run.
> Dear Amber Developers,
>
> could you please assert that it is not possible to run 'mpirun -np >1
> pmemd'.
> This is a really beasty thing.
Unfortunately while it is possible to attempt to catch typical users errors
this is one such case where it is not possible. The serial 'pmemd' knows
nothing about MPI and so has no way of knowing it is running under MPI. The
mpirun command is in it's simplest form a script that just launches a bunch
of totally independent executables. You can try this yourself, for example
try:
mpirun -np 4 /bin/ls
and see what you get. Or even worse try. 'mpirun -np 4 /bin/cp * ./'
The only reasonably reliable way to detect that the user was running non mpi
code with mpirun would be to have the mpi standard changed and then approach
the various MPI authors to have them put the various checks and balances in.
This is something that is not going to happen. Especially since there are
actually cases where people want to legitimately use mpirun to run serial
executables.
Unfortunately this is a case in science where you simply need to exercise
caution and due diligence. This is true in the laboratory and most people
accept that. E.g. if you mix the wrong reagents etc you do not expect the
round bottom flask to pop up an error message. The same is true in
computational chemistry and so I think it is unreasonable to always expect
the computer to know best.
All the best
Ross
/\
\/
|\oss Walker
---------------------------------------------------------
| Assistant Research Professor |
| San Diego Supercomputer Center |
| Adjunct Assistant Professor |
| Dept. of Chemistry and Biochemistry |
| University of California San Diego |
| NVIDIA Fellow |
|
http://www.rosswalker.co.uk |
http://www.wmd-lab.org/ |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
---------------------------------------------------------
Note: Electronic Mail is not secure, has no guarantee of delivery, may not
be read every day, and should not be used for urgent or sensitive issues.
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
--
Oliver Kuhn, Department of Bioinformatics,
Center for Medical Biotechnology, University of Duisburg-Essen,
Universitätsstr. 1-5, 45141 Essen, Germany
phone +49 201 183-3121, oliver.kuhn.uni-due.de
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Jul 21 2011 - 07:30:02 PDT
