Open GoogleCodeExporter opened 8 years ago
By the way, does this (nrexcl "issue") imply that in the case of "dlp"
(DL_POLY) analysis the exclusions cover only nrexcl=1 ?
If so, I will have to do deal with that too!
AB
Original comment by abruk...@googlemail.com
on 14 Oct 2014 at 10:58
... Although I have not noticed any effects of that in the tutorial hexane case.
Original comment by abruk...@googlemail.com
on 14 Oct 2014 at 11:44
As I said earlier, this is not an issue! nrexcl=1 after the mapping is by
design to leave the full control over the exclusion to the user.
dlpoly topologies behave exactly like all other topologies. Exclusion in the
topology are honored if and only if the topology is not mapped using a mapping
file (even dummy 1:1 mapping).
In the hexane case, there are 2 bonds and 1 angle per molecule, which
effectively excludes all intra-molecular contributions to the non-bonded
distributions.
Original comment by christop...@gmail.com
on 15 Oct 2014 at 3:14
> nrexcl=1 after the mapping is by design to leave the full control over the
exclusion to the user.
- meaning ??? What is the user supposed to do about it, when csg_stat is used
within any VOTCA iteration? Do you imply the user has to substitute csg_stat
with his own analysis utility, or what?
The only way (that I know) the user can control the exclusion list is via
nrexcl in .top/.tpr files in the case of Gromacs, for which one has to omit the
mapping.
DL_POLY has no equivalent parameter, as it creates the exclusion list based on
the collective information in the FIELD file. Up to now (before I encountered
this confusing "feature") I assumed that in the case of ".dlpf" option VOTCA
creates exclusions for all bonded pairs within bonds, angles and dihedrals, if
any (DL_POLY does essentially that).
Original comment by abruk...@googlemail.com
on 15 Oct 2014 at 3:52
For the purely non-bonded iterations the original gromacs/dl_poly topology is
used and hence all exclusions are honored. Only for bonded iterations a 1:1
mapping has to be performed and exclusions are overwritten with the ones
generated by the mapping file(s). These exclusions are similar to nrexcl=1,
meaning VOTCA excludes all atoms interacting with a bond, angle or dihedral.
So, from what you described above, dl_poly uses nrexcl=1, too.
If the user needs more complicated exclusions for the distribution calculation
there are a couple of options.
In the case of purely non-bonded iterations one can specify a special topology
file (cg.inverse.$sim_prog.rdf.topol) when calling csg_stat. For bonded
iterations one can put extra ("phantom") bonded into the mapping file to
exclude more atoms. There might be cases where phantom bonds are not
sufficient, especially something like nrexcl=0, and hence nrexcl in the mapping
would be a nice feature to have. However one can always overload the
distribution calculation with a custom script, e.g. running g_rdf (see
calc_rdf_gromacs.sh).
Bonded iteration is fairly new feature and it still needs some work.
Original comment by christop...@gmail.com
on 15 Oct 2014 at 4:25
Alright, thanks for the hints!
> So, from what you described above, dl_poly uses nrexcl=1, too.
- Nope! One can say that DL_POLY uses nrexcl=1 for bonds (if any), 2 for angles
(if any), and 3 for dihedrals (if any). So it is a more complex algorithm for
exclusions, where one can easily have a combination of nrexcl values within the
same molecule (topology).
I did not touch this complication before, because if the analysis in VOTCA
iteration is always done with csg_stat (and any other VOTCA tools), then
everything is updated consistently, even though exclusion lists might differ
between VOTCA and DL_POLY (assuming VOTCA's single nrexcl >= DL_POLY's largest
nrexcl).
Original comment by abruk...@googlemail.com
on 15 Oct 2014 at 4:39
BTW, in the case of the analysis for non-mapped full-atom hexane system (using
the original trajectory), VOTCA and DL_POLY produce coinciding RDFs and other
distributions!
This was another reason for me not bothering about any difference in the
exclusion lists between the two.
Original comment by abruk...@googlemail.com
on 15 Oct 2014 at 4:47
Open a separate issue for that problem (or re-open issue #161) as the
implementation of this new feature has very little to do with your specific
issue.
Original comment by christop...@gmail.com
on 15 Oct 2014 at 4:53
Original issue reported on code.google.com by
christop...@gmail.com
on 11 Oct 2014 at 10:09