Hi Dan,
I'm sure this will be appreciated by more than just myself. I have my own
2c of comments below.
On Tue, Jan 11, 2011 at 5:49 PM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
> Hi All,
>
> In my efforts to add reading and writing of a new Netcdf restart
> format to sander I've had to work closely with the variables ntx,
> irest, and init and had some general comments/questions regarding
> them.
>
> ntx is used all over the place. In getcor() ntx 1, 5, and 7 are
> probably the values everyone uses (5 and 7 seem to have identical
> behavior). ntx=2 reads unformatted coordinates, ntx=3 reads
> unformatted coords and forces, and ntx=4 reads unformatted coords and
> velocities. If ntx=6 the code follows ntx=4, then will attempt to read
> box coords using rfree(); however rfree() seems to expect the file to
> be formatted while the coord file has been opened unformatted, so ntx
> 6 is effectively broken (and by the time getcor() has been called the
> box info has been read by the ewald routines anyway). Should ntx=6 be
> disabled?
>
> Also, I was thinking of making ntx=8 netcdf restart coord, and ntx=9
> netcdf restart coords and velocities. ntx is open, but there is one
>
Can we not just have one that means "netcdf restart"? Perhaps there can be
a flag of some sort that indicates whether velocities are present or not in
the netcdf file itself, or just have velocities written out (0s for
placeholders) every time a netcdf restart is written. I may be missing some
implementation difficulties inherent to netcdf/Fortran. Just thought I'd
ask/suggest.
reference to ntx=9 in ew_box.f (in firstbox() subroutine) that seems
> to consider ntx=9 a formatted restart. However, I can't find any other
> references to ntx=9. Does anyone have any more info, or any reason why
> I shouldn't use 8 and 9?
>
It would probably be best to remove the reference to 9 in ew_box.f? It's
undocumented and probably never used, anyway.
>
> Init is set based on irest (irest=0 is init=3 and irest=1 is init=4)
> and appears to be used solely in runmd.f as far as I can tell. Is the
> reason init is used instead of irest just a case of "If it ain't broke
> don't fix it" or is there something else I am missing?
>
init is also changed, though (changed to 4 if it's not equal to 4 to begin
with) once it hits a certain point in runmd, which means that all future
runmd calls will proceed as though it's a restart. I, for one, actually
think it's a better approach to use that extra variable that you lug around
and change rather than playing around with the value of an input parameter.
However, why 3 and 4 were chosen as opposed to 1 and 2 or .true. and .false.
escapes me. Probably some deprecated/removed functionality or something (in
any case, well before I started peeking at the code). I'm not one for
making that kind of change though, so at this point I'd chalk it up to if it
ain't broke don't fix it.
> Lastly, are there any objections to me putting this netcdf restart
> format into the git tree?
>
None for me.
Thanks!
Jason
>
> -Dan
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Graduate Student
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Jan 11 2011 - 17:00:03 PST