Only after sending the mail, I noticed that it is simply a convention matter: in pcff.frc the LJ parameters are given as r-eps, while in the original oplsaa.frc you have defined them as A-B pairs. May I ask you please to add a sanity check of LJ-type used in the forcefield source file.
–Vitalie
vitalie,
please note that i am pretty much clueless in terms of conventions and force field details for msi2lmp. this is code that was written long ago and basically kept limping along by various people over time for their respective purposes.
most of my modifications to the code were bugfixes, portability improvements, code quality improvements and adding features that have little to do with force fields as such. the OPLS support is for the most part contributed code. i didn’t see your original post and particularly not the attachments, so i cannot comment on the details or have an idea of how to implement what you are asking for.
axel.
Axel,
The problem with my original mail was the attachment size, it’s still awaiting a moderator’s decision. Attached to this mail are gzip-archives with the test case. Sorry for the inconvenience with the file size and formats, I got the data from the students, they used a somewhat larger box for testing.
Concerning the convention issue, lammps adopts epsilon-sigma parameters for pair_style lj/cut, the same holds for the original Materials Studio/MSI forcefield format. For some reason the contributed OPLS-AA forcefield file switched to the A-B convention instead of native epsilon-sigma definition. Since the rest of the msi2lmp code for class I and II forcefields uses epsilon-sigma convention, so I think this issue can be fixed by simply checking the type of nonbonded parameters in the user provided .frc file. However, I am not sure how to accomplish this.
–Vitalie
decane.car.gz (56.4 KB)
decane.data.gz (161 KB)
decane.mdf.gz (14 KB)
oplsaa.frc (71.2 KB)
Axel,
The problem with my original mail was the attachment size, it's still
awaiting a moderator's decision. Attached to this mail are gzip-archives
with the test case. Sorry for the inconvenience with the file size and
formats, I got the data from the students, they used a somewhat larger box
for testing.
Concerning the convention issue, lammps adopts epsilon-sigma parameters
for pair_style lj/cut, the same holds for the original Materials Studio/MSI
forcefield format. For some reason the contributed OPLS-AA forcefield file
switched to the A-B convention instead of native epsilon-sigma definition.
Since the rest of the msi2lmp code for class I and II forcefields uses
epsilon-sigma convention, so I think this issue can be fixed by simply
checking the type of nonbonded parameters in the user provided .frc file.
However, I am not sure how to accomplish this.
when looking to the msi2lmp source code and comparing the bundled force
field files, i see the following:
the msi2lmp implementation completely ignores the "@type" specifier (and
others) in the .frc file and simply adopts the following convention:
class 1 force fields are specified in A-B notation, class 2 force fields in
r0-epsilon. since LAMMPS uses the latter, you get the wrong output with the
provided .frc files since it does not match the conventions. the oplsaa.frc
file bundled with msi2lmp, however, agrees with the conventions of the code
and thus would translate the file correctly, if there was the additional
paramters for the CT-CT-CT-CT dihedral. i just added that parameter and the
resulting conversion looks reasonable. i am attaching this file. please
note that the data file you attached was generated with an outdated version
of msi2lmp.
adding support for the various MSI flags and settings in the frc files and
making it more compatible with force field files that are not bundles with
msi2lmp would require a significant rewrite of the tool and probably access
to the MSI software for reverse engineering or at least an extensive set of
input/output examples. i don't have time and interest. i am really only
maintaining the package because there is nobody else. i needed it to work
on windows and in the process of making that work, i noticed a some issues.
i have tracked those down and cleaned up the code as far as i could. i've
collected a few examples over time that were provided and wrote a little
regression test script to validate that the code remains functional as it
is. that's it.
axel.
oplsaa.frc (8.11 KB)
small update. i’ve reviewed the process of parsing force field files in msi2lmp and inserted some code that checks if the @type attribute is consistent with what msi2lmp expects. the force field file that you provided, still won’t work, since the dihedrals are in a different representation from what msi2lmp expects. i did update the bundled oplsaa.frc file with the missing parameters, so that can now be used for decane. if other parameters are missing for additional atoms types or bond/angle/dihedrals, please edit the force field file accordingly with mentioning the reference paper they have been taken from, and i’ll include it. please note, that only published parameters can be distributed.
axel.