Hi Bill,
Well, at the time dev was done, the flush() capability, rooted in the C std libraries I believe, was not particularly reliable from the various fortrans we were using (so we are talking amber 7 through amber 10 dev here). In particular, flush() either didn't really work, or due to interface changes (I think SGI was the culprit on this one), it could corrupt the stack (so I just looked at old comments in the pmemd code on these issues). I had a LOT of fun dealing with the different fortrans back in the day, and ultimately found that closing and reopening was the only reliable way to get stuff dumped to disk from any old fortran. I think I was dealing mostly with issues around making the run results visible to users during the run on some of the higher performance file systems, which would do things like possibly buffer mdout in the system until the job completed. Sort of annoying. Anyway, any fortrans that are coming out of public domain compiler efforts including c would presumably work, but there are a
lot of other fortrans in the world, even still. As to the current problem, I know of no way it should be happening for standard i/o, other than OS-related settings or problems, but I have not looked to see if anything happened in amber 11. I DID, a long time ago, develop a whole block of code for controlled and delayed i/o from the master (helped with performance issues at really high processor count to actually incrementally dump things like coordinates and restarts - makes the master response times from step to step more predictable, and thus easier to load balance). BUT this code never made it into any main release - the benefit was small (maybe a couple of % if memory serves) and specific to pretty high processor count and certain machines, and I deemed the risk of a partial write too high for the benefit. On the other hand, I do wonder what might be happening if NetCDF is selected, under the covers (NetCDF could be doing interesting things in the name of efficiency, you never know). But we have not
been getting any useful info from the users about their exact conditions...
Regards - Bob
________________________________________
From: Bill Ross [ross.cgl.ucsf.EDU]
Sent: Saturday, December 24, 2011 1:26 PM
To: amber.ambermd.org
Subject: Re: [AMBER] Restart file for pmemd not showing all information
> If memory serves, really the only way we could flush the buffers during
> a run was an actual close and reopen cycle
How about flush()?
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gfortran/FLUSH.html
Though I think close/open would be easier to trust.
Bill
_______________________________________________
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 Sat Dec 24 2011 - 15:00:02 PST
