Just a minor comment here: Newer Linux kernels are becoming increasingly
aggressive when it comes to file buffering, and even "flush" commands in
Fortran are unable to force writing of the buffer in many instances.
The only sure-fire way of forcing a buffer flush is to close the open file
unit. If you ensure that the job will finish before the wall time, you
will get a full file. Otherwise, you can modify the source code directly
to close this file and reopen it whenever you want its contents flushed.
The restrt file was recently treated this way (after the bugfixes are all
applied) to fix this issue with restart files.
HTH,
Jason
On Thu, Jul 26, 2012 at 6:18 AM, Jan-Philip Gehrcke <jgehrcke.googlemail.com
> wrote:
> Hey Agostino,
>
> let me just add my experiences on this topic. I've also seen that the
> distance file is written in a different way than other files (mdout for
> instance). But still, the resulting behavior depends on the environment
> (most likely on the file system in use). On one cluster, I've seen the
> distance file content being up to date just as "good" as the trajectory
> file. On another cluster, I have not seen any contents in that file
> until the sander process finished.
>
> I would agree that this file should be flushed more often during an SMD
> run in order to lose as few data as possible in case of an unexpected
> event.
>
> Jan-Philip
>
>
>
> On 07/26/2012 12:05 PM, Agostino Bruno wrote:
> > Dear developers,
> >
> > I am writing you because I just installed the new version of Amber
> (Amber12). After the installation I
> > performed the analysis test for all the tools available in amber, and
> everything went fine. Thus, I tried
> > to run a SMD job (of about 20ns), using the pmemd.MPI protocol. Also in
> this case everything went
> > fine, the only problem is a sort of delay of Amber (a sort of lag time)
> in writing the text file containing
> > the distance, the force and the work done during the simulations (this
> file is usually called dist_vs_t).
> > My concern refers about the fact that I am working on a public CPUs
> workstation cluster (a University
> > Consortium), where I have a limited number of hours for the queues and
> for the job (usually 72
> > hours), so when the time useful for the calculation was expired I
> obtained the exact number of frame
> > for the SMD run (i.e 2000 frames), but a reduced number of values in
> the dist_vs_t file (i.e 1500). I
> > think that this is due to the delay of Amber in writing the file text
> for the dist_vs_t file.
> >
> > I would ask you if exist a way to reduce the lag time with which amber
> write the dist_vs_t data, so as
> > to have the same number of frame and dist_vs_t values at the end of the
> calculation (when the
> > simulation is stopped, because of the expiration of the queues hour on
> the public workstation).
> >
> > Thank you very much for your collaboration
> >
> > Kindest regards,
> >
> > Agostino
> >
> > --
> > Agostino Bruno, PhD
> > Dipartimento Farmceutico
> > Universita' degli Studi di Parma
> >
> >
> > _______________________________________________
> > 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
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Jul 26 2012 - 05:30:03 PDT
