ParmEd / ParmEd

Parameter/topology editor and molecular simulator
https://parmed.github.io/ParmEd
384 stars 148 forks source link

Parmed .rst7 files not readable by VMD #1085

Open lvotapka opened 4 years ago

lvotapka commented 4 years ago

Hi Parmed developers,

I'm having trouble loading .rst7 files writted by parmed into VMD. The problem seems to stem from the second line of .rst7 file where the 'time' float is written after the number of atoms. VMD cannot recognize this format, as it is different output from AmberTools programs like LEAP.

For instance, here are the first few lines of a .rst7 file written by Parmed:

138 0.0000000e+00 12.9365262 18.2347232 4.1312179 13.5046409 18.9042909 4.6251275 13.3627488 17.3254947 4.2159913 12.0201362 18.2093010 4.5485474 12.8368855 18.6071131 2.7086296 12.2054840 17.8879943 2.1896728 ...

Here is what VMD could accept:

138 12.9365262 18.2347232 4.1312179 13.5046409 18.9042909 4.6251275 13.3627488 17.3254947 4.2159913 12.0201362 18.2093010 4.5485474 12.8368855 18.6071131 2.7086296 12.2054840 17.8879943 2.1896728 ...

That portion of the .rst7 file is written on the following line of amber/asciicrd.py (line 345 in my version):

self._file.write('%5d%15.7e\n' % (self.natom, self.time))

This could be disabled, by modifying to, say, a line like:

self._file.write('%5d\n' % self.natom)

Though some people may want to keep the time variable option available. If there was some way to make this only optional, I think it could save VMD users a lot of trouble.

swails commented 4 years ago

Restart files have the time written in that way, and have for decades. I've never experienced a problem with VMD reading these kinds of restart files. VMD should be able to read either format.

I suspect there's another underlying problem (are you sure you're using the "rst7" or "restart7" format option in VMD?

lvotapka commented 4 years ago

I'm definitely loading as "AMBER7 Restart" format in VMD. I'm using VMD 1.9.2. I believe that I've had this problem on more recent versions, however.

I've attached two files, one is a parm7 file generated by LEAP and an rst7 file generated by Parmed. If you have a build of VMD and want to try to load, then maybe you'll encounter the problem too.

chig.parm7.gz chig.rst7.gz

drroe commented 4 years ago

The problem seems to stem from the second line of .rst7 file where the 'time' float is written after the number of atoms. VMD cannot recognize this format, as it is different output from AmberTools programs like LEAP.

This is really a VMD issue then. The Amber restart format may have # atoms, or # atoms and time: see https://ambermd.org/FileFormats.php#restart

One way you could probably avoid all this for now is to use the Amber NetCDF restart format (assuming you're on a non-windows platform or using the WSL) by specifying netcdf along with parmout. The NetCDF restart is a superior format in every way.

swails commented 4 years ago

As Dan mentioned, the format spec clearly calls out the presence of the time variable that is not always printed.

VMD does properly parse the time. However, it assumes that the presence of a time stamp in the restart files implies the presence of velocities, which your example file does not have. If your file had velocities, then VMD would load it fine (I verified this by simply copying all but the first two lines to the end of the file, effectively generating nonsense velocities).

I've raised #1086 to try and work around this issue, but the Amber restart code was written by kind of an idiot (age 20-something @swails) and was a lot harder than it should have been.

I'd also recommend reporting this issue to the VMD mailing list so they can fix their parser as well. It shouldn't be hard for them to do (and VMD still has dedicated developers while ParmEd really doesn't).

FWIW, I also echo @drroe's recommendation for using NetCDF restart files.

lvotapka commented 4 years ago

Alright thanks guys, and sounds good to me. I'll reach out to the VMD developers and see if they would be able to fix this problem. I also coded an easy workaround that deletes that number automatically in the meantime. And you're not the only one who wrote bad code in his teens and twenties ;)