Dear all,
I save positions from a simulation with a 0.5 fs time step to an XTC file using:
dump trajectory all xtc 100 positions.xtc
that is, the resulting stride is 50 fs. When I use gmx check on the
resulting file, it reports a stride of 50 ps. Is this an error in how
LAMMPS saves XTC, or does GROMACS perhaps make assumptions on the data
it should not?
Thank you,
Ondrej
Dear all,
I save positions from a simulation with a 0.5 fs time step to an XTC file using:
dump trajectory all xtc 100 positions.xtc
that is, the resulting stride is 50 fs. When I use gmx check on the
resulting file, it reports a stride of 50 ps. Is this an error in how
LAMMPS saves XTC, or does GROMACS perhaps make assumptions on the data
it should not?
from looking at the source code, i would say it is a bit of both.
what LAMMPS writes out is just the timestep number times the length of
the timestep, but without applying any unit conversion.
that can be a problem, since there is a factor of 1000.0 between the
time unit in LAMMPS for "units metal" versus "units real".
(BTW: also the length unit is not properly handled. for "units lj"
there is no scaling and for everything else numbers are divided by 10
(which applies only to "units real" and "units metal", since gromacs
expects nanometers, while LAMMPS uses angstrom).
i don't know what gromacs expects exactly for those, but it is likely
easier to change the code in LAMMPS since it already allows adjusting
for different unit systems. it might even be advantageous to implement
a "gromacs" unit setting.
axel.
If XTC files are Gromacs format and Gromacs
expect time in some defined unit, like ns …
then why don’t we have LAMMPS always
write “time” to the XTC file in that unit. As
Axel says, that would require a different
conversion for metal vs real vs other units.
Axel, there is already update->femtosecond
defined for each units system. So that
could be used in dump_xtc.cpp to hardwire
the output units.
Steve
If XTC files are Gromacs format and Gromacs
expect time in some defined unit, like ns ...then why don't we have LAMMPS always
write "time" to the XTC file in that unit. As
Axel says, that would require a different
conversion for metal vs real vs other units.Axel, there is already update->femtosecond
defined for each units system. So that
could be used in dump_xtc.cpp to hardwire
the output units.
i know. i already implemented it early this morning; including flags
to dump_modify to manually override the conversion factors to whatever
people desire (useful for units "si" and similar, since otherwise the
XTC compression scheme may not work so well, or truncated too much,
since the "precision" flag is an 'absolute' precision, i.e. relative
to nanometers).
just need to run some tests to make sure, i didn't mess anything up.
axel.
If XTC files are Gromacs format and Gromacs
expect time in some defined unit, like ns ...then why don't we have LAMMPS always
write "time" to the XTC file in that unit. As
Axel says, that would require a different
conversion for metal vs real vs other units.Axel, there is already update->femtosecond
defined for each units system. So that
could be used in dump_xtc.cpp to hardwire
the output units.i know. i already implemented it early this morning; including flags
to dump_modify to manually override the conversion factors to whatever
people desire (useful for units "si" and similar, since otherwise the
XTC compression scheme may not work so well, or truncated too much,
since the "precision" flag is an 'absolute' precision, i.e. relative
to nanometers).just need to run some tests to make sure, i didn't mess anything up.
here you are. the attached patch should implement the changes from above.
i tested with "real" and "metal" units and it seems to be working correctly.
in the process i found a bug of the femtosecond scaling factor for electron
units, so that is corrected as well.
axel.
lammps-xtc-unit-conversion.diff.gz (1.92 KB)