So far most of the output data of pbsa are directed to standard out, i.e.
the output file as in sander, so there has been no need to use a
complex/automatic management of files. But I agree with you it's time to be
more strict in managing i/o when more developers are getting involved in
coding.
Ray
On Tue, Jul 10, 2012 at 3:20 AM, Jan-Philip Gehrcke <jgehrcke.googlemail.com
> wrote:
> On 07/09/2012 10:04 PM, Jason Swails wrote:
> > On Mon, Jul 9, 2012 at 2:57 PM, Jan-Philip Gehrcke
> > <jgehrcke.googlemail.com>wrote:
>
> >>
> >> 1) Shouldn't there be a central automatic 'newunit management' system in
> >> PBSA for preventing I/O collisions? Especially for large projects, the
> idea
> >> of relying on hard-coded numbers like `phifilenum=64` in pb_force.F90
> seems
> >> to be risky. Are there plans for using the Fortran 2008 `newunit`
> feature,
> >> which automatically selects a unit number that does not interfere with
> >> other units in use?
> >>
> >
> > We try to stay away from the 'bleeding edge' of the Fortran standard if
> > possible since it will severely limit portability across different
> > compilers and compiler versions (and HPCs are notoriously averse to
> > frequent updates, for good reason). There are convenient enough
> > workarounds to the 'newunit' intrinsic such that it's not worth ending
> > support for older compilers just to use that feature.
> >
>
> Jason, that sounds reasonable. Nevertheless, I have not seen an
> automatic management of unit numbers in pbsa. I assume someone has a
> good overview over the manually assigned numbers :-)
>
> > Thanks!
> > Jason
> >
>
>
>
> _______________________________________________
> 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 Tue Jul 10 2012 - 08:30:04 PDT
