Hi Maryam,
If the simulation just hung this is probably because of some glitch in the
interconnect, maybe a loose connection in a cable or a possible issue with
the file system going offline and then coming back on - e.g. filesystems
mounted over NFS can often show such problems.
The simplest thing to do is just to restart the simulation. Take a look at
the top of the restart file where the first line will show the number of
atoms and the 'time' that the restart was written. From this work out how
many steps you need to get from this to 20ns and adjust nstlim in the mdin
file accordingly. Next set irest=1 and ntx=5 in the mdin file and restart
your job selecting a new output file, a new mdcrd and new restart file and
providing the old restart file as the -c argument and the job will restart
from where the last restart file was written and then continue to run from
then onwards.
Good luck,
Ross
> -----Original Message-----
> From: amber-bounces.ambermd.org [mailto:amber-bounces.ambermd.org] On
> Behalf Of Maryam Hamzehee
> Sent: Sunday, March 01, 2009 11:34 PM
> To: AMBER Mailing List
> Subject: RE: [AMBER] binding free energy
>
> Dear Don and Ross
> Many thanks for your suggestions; It seems that there is enough space in
> my hard, I used the " df -h " command and here is the information about
> it:
>
> Filesystem Size Used Avail Use% Mounted on
> /dev/sdc1 69G 41G 25G 63% /
> tmpfs 1012M 0 1012M 0% /dev/shm
> /dev/sdb1 151G 189M 144G 1% /mnt/sdb1
> /dev/sda1 151G 189M 144G 1% /mnt/sda1
>
> I believe that the sudden pause of my simulation (using pmemd) is not
> related to disk filling up. If I want to continue my simulation, what I
> have to do, as I saied before, simulation has already done up to 8.4 ns,
> can I continue just as the 8.4 ns up to 20 ns.
>
>
> Thanks in advance for your help,
> Maryam
>
>
> --- On Sun, 3/1/09, Ross Walker <ross.rosswalker.co.uk> wrote:
>
> From: Ross Walker <ross.rosswalker.co.uk>
> Subject: RE: [AMBER] binding free energy
> To: "'AMBER Mailing List'" <amber.ambermd.org>
> Date: Sunday, March 1, 2009, 8:59 PM
>
> Hi Don,
>
> > It would be nice if sander and pmemd would try to be a little more
> > failsafe when writing the restrt file. For example, one could move
> > the previous restrt file to a temporary location in the same directory
> > (filesystem), write the new restrt, and then, if successful, delete
> > the old. Of course, this would cause temporary spikes in disk usage
> > that might make failure on a near-full filesystem come sooner rather
> > than later. But I think it would be worth it to have failures from
> > which one can recover more easily.
>
> Amber 10 can already do something close to this. You just set ntwr<0 and
> then every time it writes a restart file it will just append an increasing
> number to the end of it. This way you can keep all restart files and you
> avoid the problems of corruption happening during a restart write since
> you
> don't overwrite previous restarts so only loose at most the time between
> the
> point of corruption and the previous restart write.
>
> This of course does nothing to help you if you don't have the disk space
> to
> store them all.
>
> All the best
> Ross
>
>
> /\
> \/
> |\oss Walker
>
> | Assistant Research Professor |
> | San Diego Supercomputer Center |
> | Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
> | http://www.rosswalker.co.uk | PGP Key available on request |
>
> 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
>
>
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Mar 04 2009 - 01:12:04 PST
