Hey,
this was kind of urgent to me, so I looked into the issue and resolved
it. Attached you can find the fixed version of the
amber12/AmberTools/src/pbsa/gen_dx_file.F90 as well as a patch file
created via
$ diff -u gen_dx_file.F90.orig gen_dx_file.F90 >
gen_dx_file.F90.newline.patch
As I've restructured the whole file en_dx_file.F90, the patch file is
not really expressive. Things I've worked on:
- fixed in subroutine `gen_dx_file`: if number of grid points is not an
integer multiple of 3, the required newline character after the last
data value is not written to DX output file.
- fixed in subroutine `gen_dx_file`: DX output file name contains
trailing spaces
- cleaned up in subroutine `gen_dx_file`: variable names, variable
declarations, code style
- outcommented entire subroutines `printphidx` and `gen_integer_dx_file`
in file gen_dx_file.F90 as they are not in use
- rewrote file header, now including a link to DX format specification,
the PBSA copyright header and author information
I tested the new code and did not observe any problems.
This is the first time I have worked with Fortran code. Ugh. I have
comments/questions:
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?
2) In the Amber Fortran code style guidelines it is stated that people
should not use the asterisk as format specifier. In gen_dx_file.F90,
however, this is used quite heavily. I did not work on that, because all
this Fortran formatting stuff seems to be pretty disgusting.
I hope that course of action is fine with you.
Cheers,
Jan-Philip
On 06/25/2012 07:44 PM, Ray Luo, Ph.D. wrote:
> I'm forwarding this to Wes for a look ...
>
> Ray
>
> ---------- Forwarded message ----------
> From: *Jan-Philip Gehrcke* <jgehrcke.googlemail.com
> <mailto:jgehrcke.googlemail.com>>
> Date: Mon, Jun 25, 2012 at 10:33 AM
> Subject: [AMBER] AmberTools 12 pbsa: missing newline character in OpenDX
> output
> To: AMBER Mailing List <amber.ambermd.org <mailto:amber.ambermd.org>>
>
>
> Hello,
>
> there seems to be a small problem in the OpenDX-file-writing-feature of
> pbsa in AmberTools 12. If the number of grid points is not an integer
> multiple of 3, a missing newline character in the footer of the file
> violates the format specification. These are the last few lines of a
> problematic DX file written by pbsa:
>
> 1.3079431969E+01 1.2508119413E+01 1.1935395284E+01
> 1.1363278074E+01 1.0795899087E+01 1.0246391314E+01
> 9.7028066689E+00 9.1626945187E+00 8.6272002140E+00
> 8.1016960668E+00 attribute "dep" string "positions"
> object "Electrostatic Potential" class field
> component "positions" value 1
> component "connections" value 2
> component "data" value 3
>
> There has to be a newline character before "attribute", according to
> http://www.poissonboltzmann.org/file-formats/mesh-and-data-formats/opendx-scalar-data
>
> VMD emits an error on attempting to load such a file. With the newline
> character, VMD loads the file properly.
>
>
> Regards,
>
> Jan-Philip Gehrcke
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org <mailto: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 Mon Jul 09 2012 - 12:00:02 PDT
