general questions; mapping file; csg_stat - RDF

[Wolfgang Verestek]

Hi all,

I've got a question about the rdf computation and the mapping file. I wrote some python code to create the mapping files from a lammps data file. Although there are several molecules i want to keep it to one mapping file for convenience. Also the ordering is not the same inside different molecules of the same type Instead I'm trying to use the residue IDs to keep track of the molecules.

In the attached small example there are 4 molecules (1/2 short PA6 chains and 3/4 two water molecules). :

Atom ID     1:79    PA6 #1

Atom ID   80:158  PA6 #2

Atom ID 159:161  Water #1

Atom ID 162:164  Water #2

So the first question is: Is this doable at all? OR am i misunderstanding sth very basic here?

the out put of 'csg_dump --top ../mapping.xml' looks ok to me.

I have 164 beads in 1 molecules
Boundary Condition: open

List of residues:
0 name: m1AA id: 0
1 name: m1AA id: 1
2 name: m1AA id: 2
3 name: m1AA id: 3

List of molecules:
molecule: 1 m1AA beads: 164
0 Name 1:m1AA:1 Type 3 Mass 12.0112 Resnr 0 Resname m1AA Charge -0.106
1 Name 1:m1AA:2 Type 4 Mass 1.00797 Resnr 0 Resname m1AA Charge 0.053
2 Name 1:m1AA:3 Type 4 Mass 1.00797 Resnr 0 Resname m1AA Charge 0.053
3 Name 1:m1AA:4 Type 3 Mass 12.0112 Resnr 0 Resname m1AA Charge -0.106

...

162 Name 1:m1AA:163 Type 11 Mass 1.00797 Resnr 3 Resname m1AA Charge 0.3991
163 Name 1:m1AA:164 Type 11 Mass 1.00797 Resnr 3 Resname m1AA Charge 0.3991

whereas 'csg_dump --top ../mapping.xml --cg ../mapping.cg.xml' shows that the resID gets lost (But isn't absolutely necessary anyways i guess) .
I have 164 beads in 1 molecules
I have 18 beads in 1 molecules for the coarsegraining
Boundary Condition: open

List of residues:
0 name: m1CG id: 0

List of molecules:
molecule: 1 m1CG beads: 18
0 Name 1 Type 1 Mass 56.1084 Resnr 0 Resname m1CG Charge 0
1 Name 2 Type 2 Mass 57.0523 Resnr 0 Resname m1CG Charge 0

...

16 Name 17 Type 5 Mass 18.0153 Resnr 0 Resname m1CG Charge 0
17 Name 18 Type 5 Mass 18.0153 Resnr 0 Resname m1CG Charge 0

Is there a way to adjust the boundary condition and the Resnr for the CG mapping?

So i went on to check the RDF 'csg_stat --top ../mapping.xml --trj ../chemistry.dump --options ../settings.xml --first-frame 0 --nframes 1' which leads to the plot given the below (data also attached in the zip file). By reading the all atom trajectory lammps snapshot and comparing the results with Ovito output the results somehow match qualitatively, at least in the beginning. for larger distances the decay somehow made me think that periodic boundary conditions are not enforced (the lammps dump file is in unwrapped coords). Is there a way to enforce periodic boundary conditions and backmapping into the cell (or could this be the reason at all)? Should i adjust the lammps dump file to have wrapped coords? Any other pitfalls i might not have considered?

Regards

Wolfgang

[Christoph Junghans]

On Mon, Apr 6, 2020 at 2:52 PM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

Hi all,

I've got a question about the rdf computation and the mapping file. I wrote some python code to create the mapping files from a lammps data file. Although there are several molecules i want to keep it to one mapping file for convenience. Also the ordering is not the same inside different molecules of the same type Instead I'm trying to use the residue IDs to keep track of the molecules.

In the attached small example there are 4 molecules (1/2 short PA6 chains and 3/4 two water molecules). :

Atom ID     1:79    PA6 #1

Atom ID   80:158  PA6 #2

Atom ID 159:161  Water #1

Atom ID 162:164  Water #2

So the first question is: Is this doable at all? OR am i misunderstanding sth very basic here?

It should be doable, you will create two mapping files though. Mapping.cg.xml is ok, but will need a mapping.water.xml as well. One of each molecule type. 

the out put of 'csg_dump --top ../mapping.xml' looks ok to me.

I would call this file "topology.xml" not mapping. 

I have 164 beads in 1 molecules
Boundary Condition: open

This might be the problem, try to add a line like

<box xx="4.03100" yy="4.03100" zz="4.03100"/> to your topology file to define the box size.

See above for the box size, there is "resid" property in the topology file, but I don't think you can to it after the mapping.  

So i went on to check the RDF 'csg_stat --top ../mapping.xml --trj ../chemistry.dump --options ../settings.xml --first-frame 0 --nframes 1' which leads to the plot given the below (data also attached in the zip file). By reading the all atom trajectory lammps snapshot and comparing the results with Ovito output the results somehow match qualitatively, at least in the beginning. for larger distances the decay somehow made me think that periodic boundary conditions are not enforced (the lammps dump file is in unwrapped coords). Is there a way to enforce periodic boundary conditions and backmapping into the cell (or could this be the reason at all)? Should i adjust the lammps dump file to have wrapped coords? Any other pitfalls i might not have considered?

See above for the boundary cond. question, so that should solve that. I think the lammps interface is not as well used as the gromacs one, hence you will find some more pitfalls.

Christoph 

Regards

Wolfgang

--
You received this message because you are subscribed to the Google Groups "votca" group.
To unsubscribe from this group and stop receiving emails from it, send an email to votca+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/votca/c8e63e00-48be-42db-8a77-de6e92dd11ef%40googlegroups.com.

--

Christoph Junghans
Web: http://www.compphys.de

[Wolfgang Verestek]

Dear Christoph,

thanks for your fast response. i followed you suggestion, renamed the files and added the box tag to the topology file (files attached). But the result stays the same. So, as you said that gromacs format is better supported i changed my output to gro87 format. No errors, but the discrepancy remains, regardless if i'm using wrapped or unwrapped coords in the conf.gro file. See below. Are there any other things i could change? Another format?

Is it possible to set the boundary conditions somewhere specifically? Or could it be that periodic images of the specific atoms are ignored (the simulation box is kind of small and close by region seems ok)?

Is there a way to visualize the xml or gro files? I know vmd, but that segfaults when reading the gro file.

Ultimately the whole thing should go into force matching. But i guess the results will be off if already the RDF is wrong?

Is it really necessary to have one file per molecule type and what distinguishes different molecule types? If i have several PA6 molecules with different length/count of monomers is that already different molecules?

Thanks and regards

Wolfgang

[Christoph Junghans]

On Tue, Apr 7, 2020 at 9:59 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

Dear Christoph,

thanks for your fast response. i followed you suggestion, renamed the files and added the box tag to the topology file (files attached). But the result stays the same. So, as you said that gromacs format is better supported i changed my output to gro87 format. No errors, but the discrepancy remains, regardless if i'm using wrapped or unwrapped coords in the conf.gro file. See below. Are there any other things i could change? Another format?

Is it possible to set the boundary conditions somewhere specifically? Or could it be that periodic images of the specific atoms are ignored (the simulation box is kind of small and close by region seems ok)?

Sorry, I didn't have time to look at your files yet, but does OVito handle exclusion in the same way as VOTCA?

Have a look at the output of "csg_dump --top topology.xml --excl"

Secondly you could use "csg_map --top topology --no-map --trj lammps.dump --out out.pdb", to check if the coordinates are read correctly. 

Christoph

Is there a way to visualize the xml or gro files? I know vmd, but that segfaults when reading the gro file.

Ultimately the whole thing should go into force matching. But i guess the results will be off if already the RDF is wrong?

Is it really necessary to have one file per molecule type and what distinguishes different molecule types? If i have several PA6 molecules with different length/count of monomers is that already different molecules?

Thanks and regards

Wolfgang

--
You received this message because you are subscribed to the Google Groups "votca" group.
To unsubscribe from this group and stop receiving emails from it, send an email to votca+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/votca/b4b7484f-2663-4fe6-a082-ad3c2ca1ef20%40googlegroups.com.

[Wolfgang Verestek]

Am Mittwoch, 8. April 2020 02:07:39 UTC+2 schrieb Christoph Junghans:

On Tue, Apr 7, 2020 at 9:59 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

Dear Christoph,

thanks for your fast response. i followed you suggestion, renamed the files and added the box tag to the topology file (files attached). But the result stays the same. So, as you said that gromacs format is better supported i changed my output to gro87 format. No errors, but the discrepancy remains, regardless if i'm using wrapped or unwrapped coords in the conf.gro file. See below. Are there any other things i could change? Another format?

Is it possible to set the boundary conditions somewhere specifically? Or could it be that periodic images of the specific atoms are ignored (the simulation box is kind of small and close by region seems ok)?

Sorry, I didn't have time to look at your files yet, but does OVito handle exclusion in the same way as VOTCA?

Have a look at the output of "csg_dump --top topology.xml --excl"

How should that look like? I'm not sure if i understand that format correctly, but it seems correct to me. in my data file Atom with id 1 is connectod to atoms 2 3 4 and 36. I assume this is non repetitive so id 4 does not show up again for atom id 4 and so on. I did not check the whole list, but the first 10 lines are correct.

I have 164 beads in 1 molecules

List of exclusions:
1 2 3 4 36
4 5 6 7
7 8 9 10
10 11 12
12 13 14
14 15 16 17
17 18 19 39
20 21 22 23 77
...

 

Secondly you could use "csg_map --top topology --no-map --trj lammps.dump --out out.pdb", to check if the coordinates are read correctly. 

apart from the bigger cell for the pdb (where this information is not included) the positions look ok. (lammps file in "black cores", pdb in transparent green).

Christoph

Is there a way to visualize the xml or gro files? I know vmd, but that segfaults when reading the gro file.

Ultimately the whole thing should go into force matching. But i guess the results will be off if already the RDF is wrong?

Is it really necessary to have one file per molecule type and what distinguishes different molecule types? If i have several PA6 molecules with different length/count of monomers is that already different molecules?

Thanks and regards

Wolfgang

--
You received this message because you are subscribed to the Google Groups "votca" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/votca/b4b7484f-2663-4fe6-a082-ad3c2ca1ef20%40googlegroups.com.

[Christoph Junghans]

On Wed, Apr 8, 2020 at 5:01 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

Am Mittwoch, 8. April 2020 02:07:39 UTC+2 schrieb Christoph Junghans:

On Tue, Apr 7, 2020 at 9:59 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

Dear Christoph,

thanks for your fast response. i followed you suggestion, renamed the files and added the box tag to the topology file (files attached). But the result stays the same. So, as you said that gromacs format is better supported i changed my output to gro87 format. No errors, but the discrepancy remains, regardless if i'm using wrapped or unwrapped coords in the conf.gro file. See below. Are there any other things i could change? Another format?

Is it possible to set the boundary conditions somewhere specifically? Or could it be that periodic images of the specific atoms are ignored (the simulation box is kind of small and close by region seems ok)?

Sorry, I didn't have time to look at your files yet, but does OVito handle exclusion in the same way as VOTCA?

Have a look at the output of "csg_dump --top topology.xml --excl"

How should that look like? I'm not sure if i understand that format correctly, but it seems correct to me. in my data file Atom with id 1 is connectod to atoms 2 3 4 and 36. I assume this is non repetitive so id 4 does not show up again for atom id 4 and so on. I did not check the whole list, but the first 10 lines are correct.

I have 164 beads in 1 molecules

List of exclusions:
1 2 3 4 36

This means the atom #1 is excluded with atom #2, #3,#4 and #36 and hence contributions from these pairs won't go into the RDF.

VOTCA automatically created exclusion (in same way as Gromacs does) for bonds, angles and dihedrals.

Christoph

  

To unsubscribe from this group and stop receiving emails from it, send an email to votca+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/votca/3cd73547-59da-4de8-894d-0345302ebeca%40googlegroups.com.

[Wolfgang Verestek]

Dear Christoph,

it seems to me, that the bonds in topology.xml do not influence the result of csg_stat. On contrary, i got the same results regardless of bonds being in topology.xml or not. The same is true for for wrapped or unwrapped coordinates. The only thing that did change the result was changing the cell size in the conf.gro by factor of 10 in each dimenstion which looks like the nonperiodic results from Ovito (but made it necessary to scale by a factor of 1000 to be in the same range of the plot). Furthermore, i confirmed the results of Ovito by VMD. The nonperiodic calculation in VMD oversitmates the first peak somewhat, but otherwise the results are in good agreement. The results don't match perfectly, but as i don't know how exactly VMD or Ovito compute the RDF i guess the match is good enough and the drop in the periodic VMD plot should be due to some other reason (maybe the g(r) plugin is limited to 3/4 cell lengt or sth.).

regarding scg_stat it still seems to me that the tail is smoothed or periodic images in different directions are omitted. Could that be? I can provide the files f necessary.

To view this discussion on the web visit https://groups.google.com/d/msgid/votca/3cd73547-59da-4de8-894d-0345302ebeca%40googlegroups.com.

[Christoph Junghans]

On Tue, Apr 14, 2020 at 8:40 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

Dear Christoph,

it seems to me, that the bonds in topology.xml do not influence the result of csg_stat. On contrary, i got the same results regardless of bonds being in topology.xml or not. The same is true for for wrapped or unwrapped coordinates. The only thing that did change the result was changing the cell size in the conf.gro by factor of 10 in each dimenstion which looks like the nonperiodic results from Ovito (but made it necessary to scale by a factor of 1000 to be in the same range of the plot). Furthermore, i confirmed the results of Ovito by VMD. The nonperiodic calculation in VMD oversitmates the first peak somewhat, but otherwise the results are in good agreement. The results don't match perfectly, but as i don't know how exactly VMD or Ovito compute the RDF i guess the match is good enough and the drop in the periodic VMD plot should be due to some other reason (maybe the g(r) plugin is limited to 3/4 cell lengt or sth.).

regarding scg_stat it still seems to me that the tail is smoothed or periodic images in different directions are omitted. Could that be? I can provide the files f necessary.

Ok now I am getting really confused, I just did a quick comparison of gmx rdf and csg_stat and the results are right on top of each other.

Could you do me a favor and try to follow:

```

apt-get install gromacs

cp /usr/share/gromacs/top/spc216.gro .

wget https://raw.githubusercontent.com/votca/csg/master/src/tools/references/spce/sources/grompp.mdp

wget https://raw.githubusercontent.com/votca/csg/master/src/tools/references/spce/sources/topol.top
gmx grompp -c spc216.gro -maxwarn 1
echo q | gmx make_ndx -f spc216.gro

echo -e "1\n1" | gmx rdf -f spc216.gro -s topol.tpr -n index.ndx -selrpos mol_com -seltype mol_com -bin 0.02

wget https://raw.githubusercontent.com/votca/csg/master/src/tools/references/spce/mapping.xml

wget https://raw.githubusercontent.com/votca/csg/master/src/tools/references/spce/settings_rdf.xml

csg_stat --options settings_rdf.xml --top  topol.tpr --trj spc216.gro --cg mapping.xml

csg_map --top  topol.tpr --trj spc216.gro --cg mapping.xml --out cg.dump

```

and then calculate the rdf from cg.dump with ovito and vmd and compare them with rdf.xvg and CG-CG.dist.new.

Christoph

 

--
Join us on Slack: https://join.slack.com/t/votca/signup
---

You received this message because you are subscribed to the Google Groups "votca" group.

To unsubscribe from this group and stop receiving emails from it, send an email to votca+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/votca/9c1da74b-2bca-4aa5-b1a1-f26123328000%40googlegroups.com.

[Wolfgang Verestek]

Am Dienstag, 14. April 2020 19:21:07 UTC+2 schrieb Christoph Junghans:

On Tue, Apr 14, 2020 at 8:40 AM Wolfgang Verestek wrote:

Dear Christoph,

it seems to me, that the bonds in topology.xml do not influence the result of csg_stat. On contrary, i got the same results regardless of bonds being in topology.xml or not. The same is true for for wrapped or unwrapped coordinates. The only thing that did change the result was changing the cell size in the conf.gro by factor of 10 in each dimenstion which looks like the nonperiodic results from Ovito (but made it necessary to scale by a factor of 1000 to be in the same range of the plot). Furthermore, i confirmed the results of Ovito by VMD. The nonperiodic calculation in VMD oversitmates the first peak somewhat, but otherwise the results are in good agreement. The results don't match perfectly, but as i don't know how exactly VMD or Ovito compute the RDF i guess the match is good enough and the drop in the periodic VMD plot should be due to some other reason (maybe the g(r) plugin is limited to 3/4 cell lengt or sth.).

regarding scg_stat it still seems to me that the tail is smoothed or periodic images in different directions are omitted. Could that be? I can provide the files f necessary.

Ok now I am getting really confused, I just did a quick comparison of gmx rdf and csg_stat and the results are right on top of each other.

Could you do me a favor and try to follow:

```

apt-get install gromacs

cp /usr/share/gromacs/top/spc216.gro .

wget https://raw.githubusercontent.com/votca/csg/master/src/tools/references/spce/sources/grompp.mdp

wget https://raw.githubusercontent.com/votca/csg/master/src/tools/references/spce/sources/topol.top
gmx grompp -c spc216.gro -maxwarn 1
echo q | gmx make_ndx -f spc216.gro

echo -e "1\n1" | gmx rdf -f spc216.gro -s topol.tpr -n index.ndx -selrpos mol_com -seltype mol_com -bin 0.02

wget https://raw.githubusercontent.com/votca/csg/master/src/tools/references/spce/mapping.xml

wget https://raw.githubusercontent.com/votca/csg/master/src/tools/references/spce/settings_rdf.xml

csg_stat --options settings_rdf.xml --top  topol.tpr --trj spc216.gro --cg mapping.xml

csg_map --top  topol.tpr --trj spc216.gro --cg mapping.xml --out cg.dump

```

and then calculate the rdf from cg.dump with ovito and vmd and compare them with rdf.xvg and CG-CG.dist.new.

Christoph

Ovito and VMD give nearly the same results (green X / blue square). I'm not sure how those two really compute the RDF. For Ovito I can set the cutoff and the number of bins (9.0, 45) and i think the bin center is on the x coordinates. In VMD i can set the cutoff and the delta (9, 0.2). As said, i'm not sure how the bins are decided inside those two progs, so this might lead to small offsets.

cg_stat on the other hand is a little bit off compared to ovito and vmd. But this could be imho due to the binning as mentioned before. qualitatively i think it's pretty much the same.

- regards

Wolfgang

 

 

To unsubscribe from this group and stop receiving emails from it, send an email to votca+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/votca/9c1da74b-2bca-4aa5-b1a1-f26123328000%40googlegroups.com.

[Christoph Junghans]

On Wed, Apr 15, 2020 at 05:56 Wolfgang Verestek <wolfgang...@gmail.com> wrote:

Am Mittwoch, 15. April 2020 13:52:01 UTC+2 schrieb Wolfgang Verestek:

Am Dienstag, 14. April 2020 19:21:07 UTC+2 schrieb Christoph Junghans:

On Tue, Apr 14, 2020 at 8:40 AM Wolfgang Verestek wrote:

Dear Christoph,

it seems to me, that the bonds in topology.xml do not influence the result of csg_stat. On contrary, i got the same results regardless of bonds being in topology.xml or not. The same is true for for wrapped or unwrapped coordinates. The only thing that did change the result was changing the cell size in the conf.gro by factor of 10 in each dimenstion which looks like the nonperiodic results from Ovito (but made it necessary to scale by a factor of 1000 to be in the same range of the plot). Furthermore, i confirmed the results of Ovito by VMD. The nonperiodic calculation in VMD oversitmates the first peak somewhat, but otherwise the results are in good agreement. The results don't match perfectly, but as i don't know how exactly VMD or Ovito compute the RDF i guess the match is good enough and the drop in the periodic VMD plot should be due to some other reason (maybe the g(r) plugin is limited to 3/4 cell lengt or sth.).

regarding scg_stat it still seems to me that the tail is smoothed or periodic images in different directions are omitted. Could that be? I can provide the files f necessary.

Ok now I am getting really confused, I just did a quick comparison of gmx rdf and csg_stat and the results are right on top of each other.

Could you do me a favor and try to follow:

```

apt-get install gromacs

cp /usr/share/gromacs/top/spc216.gro .

wget https://raw.githubusercontent.com/votca/csg/master/src/tools/references/spce/sources/grompp.mdp

wget https://raw.githubusercontent.com/votca/csg/master/src/tools/references/spce/sources/topol.top
gmx grompp -c spc216.gro -maxwarn 1
echo q | gmx make_ndx -f spc216.gro

echo -e "1\n1" | gmx rdf -f spc216.gro -s topol.tpr -n index.ndx -selrpos mol_com -seltype mol_com -bin 0.02

wget https://raw.githubusercontent.com/votca/csg/master/src/tools/references/spce/mapping.xml

wget https://raw.githubusercontent.com/votca/csg/master/src/tools/references/spce/settings_rdf.xml

csg_stat --options settings_rdf.xml --top  topol.tpr --trj spc216.gro --cg mapping.xml

csg_map --top  topol.tpr --trj spc216.gro --cg mapping.xml --out cg.dump

```

and then calculate the rdf from cg.dump with ovito and vmd and compare them with rdf.xvg and CG-CG.dist.new.

Christoph

Ovito and VMD give nearly the same results (green X / blue square). I'm not sure how those two really compute the RDF. For Ovito I can set the cutoff and the number of bins (9.0, 45) and i think the bin center is on the x coordinates. In VMD i can set the cutoff and the delta (9, 0.2). As said, i'm not sure how the bins are decided inside those two progs, so this might lead to small offsets.

cg_stat on the other hand is a little bit off compared to ovito and vmd. But this could be imho due to the binning as mentioned before. qualitatively i think it's pretty much the same.

You can pick the bins size for csg_stat in settings_rdf.xml and for gmx on command line so you can make it same as vmd for the comparison.

Christoph 

- regards

Wolfgang

forgot the plot

 

 

To unsubscribe from this group and stop receiving emails from it, send an email to votca+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/votca/9c1da74b-2bca-4aa5-b1a1-f26123328000%40googlegroups.com.

--

Christoph Junghans
Web: http://www.compphys.de

--

Join us on Slack: https://join.slack.com/t/votca/signup
---
You received this message because you are subscribed to the Google Groups "votca" group.

To unsubscribe from this group and stop receiving emails from it, send an email to votca+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/votca/12ef52f9-854d-4404-95e5-54437779ae7a%40googlegroups.com.

[Wolfgang Verestek]

bin size is the same. 0.2 in vmd, 0.02 in settings_rdf.xml.

I forgot the plot in the last post

 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/votca/9c1da74b-2bca-4aa5-b1a1-f26123328000%40googlegroups.com.

--

Christoph Junghans
Web: http://www.compphys.de

--
Join us on Slack: https://join.slack.com/t/votca/signup
---
You received this message because you are subscribed to the Google Groups "votca" group.

To unsubscribe from this group and stop receiving emails from it, send an email to vo...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/votca/12ef52f9-854d-4404-95e5-54437779ae7a%40googlegroups.com.

[Christoph Junghans]

Hmm, but it seems the dots are not at the same r values, or am I seeing this wrong?

Christoph 

To unsubscribe from this group and stop receiving emails from it, send an email to votca+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/votca/56cd974d-7a71-470f-b895-d95163c22596%40googlegroups.com.

[Wolfgang Verestek]

There is indeed a slight difference. but as stated before, i think qualitatively they are matching.

Second thing: I increased the cutoff to be more than half the box (9 -> 15 A). This results in the behavior that we have seen before. Also the VMD

To view this discussion on the web visit https://groups.google.com/d/msgid/votca/56cd974d-7a71-470f-b895-d95163c22596%40googlegroups.com.

[Wolfgang Verestek]

the RDF files if you want to check yourself

To view this discussion on the web visit https://groups.google.com/d/msgid/votca/56cd974d-7a71-470f-b895-d95163c22596%40googlegroups.com.

[Christoph Junghans]

On Wed, Apr 15, 2020 at 6:36 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

There is indeed a slight difference. but as stated before, i think qualitatively they are matching.

Second thing: I increased the cutoff to be more than half the box (9 -> 15 A). This results in the behavior that we have seen before. Also the VMD

Ok, now I see, well the box size is 18.6 A, a cutoff of more than 9.3 A isn't really physically meaningful and csg_stat should basically warn of that.

Christoph  

To unsubscribe from this group and stop receiving emails from it, send an email to votca+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/votca/6a39277e-ab3a-4e14-9a8b-831a1ddb24d1%40googlegroups.com.

[Christoph Junghans]

On Wed, Apr 15, 2020 at 6:55 AM Christoph Junghans <jung...@votca.org> wrote:

On Wed, Apr 15, 2020 at 6:36 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

There is indeed a slight difference. but as stated before, i think qualitatively they are matching.

Second thing: I increased the cutoff to be more than half the box (9 -> 15 A). This results in the behavior that we have seen before. Also the VMD

Ok, now I see, well the box size is 18.6 A, a cutoff of more than 9.3 A isn't really physically meaningful and csg_stat should basically warn of that.

https://github.com/votca/csg/pull/512 

[Wolfgang Verestek]

Am Mittwoch, 15. April 2020 14:55:59 UTC+2 schrieb Christoph Junghans:

On Wed, Apr 15, 2020 at 6:36 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

There is indeed a slight difference. but as stated before, i think qualitatively they are matching.

Second thing: I increased the cutoff to be more than half the box (9 -> 15 A). This results in the behavior that we have seen before. Also the VMD

Ok, now I see, well the box size is 18.6 A, a cutoff of more than 9.3 A isn't really physically meaningful and csg_stat should basically warn of that.

ok, thanks. But could give me a hint why such a cutoff is physically not meaningful? I understand that such a small system does have bad statistics etc. but the particle is not self-interacting (although the molecule is, but it's also doing that with cutoff of 0.5* box length). Isn't that exactly what periodic boundaries should cover? I mean, extreme case here, but...?

 

Christoph  

To view this discussion on the web visit https://groups.google.com/d/msgid/votca/6a39277e-ab3a-4e14-9a8b-831a1ddb24d1%40googlegroups.com.

[Christoph Junghans]

On Thu, Apr 16, 2020 at 1:37 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

Am Mittwoch, 15. April 2020 14:55:59 UTC+2 schrieb Christoph Junghans:

On Wed, Apr 15, 2020 at 6:36 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

There is indeed a slight difference. but as stated before, i think qualitatively they are matching.

Second thing: I increased the cutoff to be more than half the box (9 -> 15 A). This results in the behavior that we have seen before. Also the VMD

Ok, now I see, well the box size is 18.6 A, a cutoff of more than 9.3 A isn't really physically meaningful and csg_stat should basically warn of that.

ok, thanks. But could give me a hint why such a cutoff is physically not meaningful? I understand that such a small system does have bad statistics etc. but the particle is not self-interacting (although the molecule is, but it's also doing that with cutoff of 0.5* box length). Isn't that exactly what periodic boundaries should cover? I mean, extreme case here, but...?

Periodic boundaries follow minimum image convention, that means one only counts minimum of all distances in all periodic images.

Imagine a 1D box of length L and put one particle at 0 and another at L/2. Their distance will be L/2, but if you move it further away from 0, it will come closer to the periodic image of the 1st particle sitting at L and hence making the distance shorter again. In 3D there is another factor of sqrt(3), but I think that is the reason why VMD had 0s in the rdf for bigger distances.

Christoph

To unsubscribe from this group and stop receiving emails from it, send an email to votca+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/votca/6152ba41-02d8-4400-ade4-1f1b2e27f13d%40googlegroups.com.

[Wolfgang Verestek]

Am Donnerstag, 16. April 2020 16:38:40 UTC+2 schrieb Christoph Junghans:

On Thu, Apr 16, 2020 at 1:37 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

Am Mittwoch, 15. April 2020 14:55:59 UTC+2 schrieb Christoph Junghans:

On Wed, Apr 15, 2020 at 6:36 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

There is indeed a slight difference. but as stated before, i think qualitatively they are matching.

Second thing: I increased the cutoff to be more than half the box (9 -> 15 A). This results in the behavior that we have seen before. Also the VMD

Ok, now I see, well the box size is 18.6 A, a cutoff of more than 9.3 A isn't really physically meaningful and csg_stat should basically warn of that.

ok, thanks. But could give me a hint why such a cutoff is physically not meaningful? I understand that such a small system does have bad statistics etc. but the particle is not self-interacting (although the molecule is, but it's also doing that with cutoff of 0.5* box length). Isn't that exactly what periodic boundaries should cover? I mean, extreme case here, but...?

Periodic boundaries follow minimum image convention, that means one only counts minimum of all distances in all periodic images.

Imagine a 1D box of length L and put one particle at 0 and another at L/2. Their distance will be L/2, but if you move it further away from 0, it will come closer to the periodic image of the 1st particle sitting at L and hence making the distance shorter again. In 3D there is another factor of sqrt(3), but I think that is the reason why VMD had 0s in the rdf for bigger distances.

Christoph

Thanks for the explanation. I was not aware that every particle is considered just once. 

I might be wrong, but from my understanding two interactions in the periodic 1D case would be possible. E.g. for two particles "x" and "o" with periodic boundary "|": o would have one interactions with x for d<L/2 and a second one for 0.5L<d<L, the first at 2 units distance in positive/right direction and the second with at 7 units distance in negative/left direction. So if I understand you correct, only one image of the particle with the minimum distance is considered and all the other periodic images are neglected?

Image   -1    |    0    |    1

Dist     98765 432101234 56789

Sys  ....o.x..|....o.x..|....o.x..

Wolfgang 

To view this discussion on the web visit https://groups.google.com/d/msgid/votca/6152ba41-02d8-4400-ade4-1f1b2e27f13d%40googlegroups.com.

[Christoph Junghans]

On Thu, Apr 16, 2020 at 9:27 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

Am Donnerstag, 16. April 2020 16:38:40 UTC+2 schrieb Christoph Junghans:

On Thu, Apr 16, 2020 at 1:37 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

Am Mittwoch, 15. April 2020 14:55:59 UTC+2 schrieb Christoph Junghans:

On Wed, Apr 15, 2020 at 6:36 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

There is indeed a slight difference. but as stated before, i think qualitatively they are matching.

Second thing: I increased the cutoff to be more than half the box (9 -> 15 A). This results in the behavior that we have seen before. Also the VMD

Ok, now I see, well the box size is 18.6 A, a cutoff of more than 9.3 A isn't really physically meaningful and csg_stat should basically warn of that.

ok, thanks. But could give me a hint why such a cutoff is physically not meaningful? I understand that such a small system does have bad statistics etc. but the particle is not self-interacting (although the molecule is, but it's also doing that with cutoff of 0.5* box length). Isn't that exactly what periodic boundaries should cover? I mean, extreme case here, but...?

Periodic boundaries follow minimum image convention, that means one only counts minimum of all distances in all periodic images.

Imagine a 1D box of length L and put one particle at 0 and another at L/2. Their distance will be L/2, but if you move it further away from 0, it will come closer to the periodic image of the 1st particle sitting at L and hence making the distance shorter again. In 3D there is another factor of sqrt(3), but I think that is the reason why VMD had 0s in the rdf for bigger distances.

Christoph

Thanks for the explanation. I was not aware that every particle is considered just once. 

I might be wrong, but from my understanding two interactions in the periodic 1D case would be possible. E.g. for two particles "x" and "o" with periodic boundary "|": o would have one interactions with x for d<L/2 and a second one for 0.5L<d<L, the first at 2 units distance in positive/right direction and the second with at 7 units distance in negative/left direction. So if I understand you correct, only one image of the particle with the minimum distance is considered and all the other periodic images are neglected?

Yes, for the RDF only the first image is considered.

For force interactions it depends, Lennard-Jones usually only uses the first image, but coulomb interactions, as they decay slower, sum over all images (see Ewald summation).

Christoph

 

To unsubscribe from this group and stop receiving emails from it, send an email to votca+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/votca/11968a7e-fb3e-443d-8af5-a2773e241335%40googlegroups.com.

[Wolfgang Verestek]

Am Freitag, 17. April 2020 15:38:05 UTC+2 schrieb Christoph Junghans:

On Thu, Apr 16, 2020 at 9:27 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

Am Donnerstag, 16. April 2020 16:38:40 UTC+2 schrieb Christoph Junghans:

On Thu, Apr 16, 2020 at 1:37 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

Am Mittwoch, 15. April 2020 14:55:59 UTC+2 schrieb Christoph Junghans:

On Wed, Apr 15, 2020 at 6:36 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

There is indeed a slight difference. but as stated before, i think qualitatively they are matching.

Second thing: I increased the cutoff to be more than half the box (9 -> 15 A). This results in the behavior that we have seen before. Also the VMD

Ok, now I see, well the box size is 18.6 A, a cutoff of more than 9.3 A isn't really physically meaningful and csg_stat should basically warn of that.

ok, thanks. But could give me a hint why such a cutoff is physically not meaningful? I understand that such a small system does have bad statistics etc. but the particle is not self-interacting (although the molecule is, but it's also doing that with cutoff of 0.5* box length). Isn't that exactly what periodic boundaries should cover? I mean, extreme case here, but...?

Periodic boundaries follow minimum image convention, that means one only counts minimum of all distances in all periodic images.

Imagine a 1D box of length L and put one particle at 0 and another at L/2. Their distance will be L/2, but if you move it further away from 0, it will come closer to the periodic image of the 1st particle sitting at L and hence making the distance shorter again. In 3D there is another factor of sqrt(3), but I think that is the reason why VMD had 0s in the rdf for bigger distances.

Christoph

Thanks for the explanation. I was not aware that every particle is considered just once. 

I might be wrong, but from my understanding two interactions in the periodic 1D case would be possible. E.g. for two particles "x" and "o" with periodic boundary "|": o would have one interactions with x for d<L/2 and a second one for 0.5L<d<L, the first at 2 units distance in positive/right direction and the second with at 7 units distance in negative/left direction. So if I understand you correct, only one image of the particle with the minimum distance is considered and all the other periodic images are neglected?

Yes, for the RDF only the first image is considered.

For force interactions it depends, Lennard-Jones usually only uses the first image, but coulomb interactions, as they decay slower, sum over all images (see Ewald summation).

Christoph

That does not sound very consistent to me. Nevertheless Thank you very much for the explanation. Altogether it already helped. Thanks

Wolfgang

 

To view this discussion on the web visit https://groups.google.com/d/msgid/votca/11968a7e-fb3e-443d-8af5-a2773e241335%40googlegroups.com.

[Christoph Junghans]

On Mon, Apr 20, 2020 at 2:40 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

Am Freitag, 17. April 2020 15:38:05 UTC+2 schrieb Christoph Junghans:

On Thu, Apr 16, 2020 at 9:27 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

Am Donnerstag, 16. April 2020 16:38:40 UTC+2 schrieb Christoph Junghans:

On Thu, Apr 16, 2020 at 1:37 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

Am Mittwoch, 15. April 2020 14:55:59 UTC+2 schrieb Christoph Junghans:

On Wed, Apr 15, 2020 at 6:36 AM Wolfgang Verestek <wolfgang...@gmail.com> wrote:

There is indeed a slight difference. but as stated before, i think qualitatively they are matching.

Second thing: I increased the cutoff to be more than half the box (9 -> 15 A). This results in the behavior that we have seen before. Also the VMD

Ok, now I see, well the box size is 18.6 A, a cutoff of more than 9.3 A isn't really physically meaningful and csg_stat should basically warn of that.

ok, thanks. But could give me a hint why such a cutoff is physically not meaningful? I understand that such a small system does have bad statistics etc. but the particle is not self-interacting (although the molecule is, but it's also doing that with cutoff of 0.5* box length). Isn't that exactly what periodic boundaries should cover? I mean, extreme case here, but...?

Periodic boundaries follow minimum image convention, that means one only counts minimum of all distances in all periodic images.

Imagine a 1D box of length L and put one particle at 0 and another at L/2. Their distance will be L/2, but if you move it further away from 0, it will come closer to the periodic image of the 1st particle sitting at L and hence making the distance shorter again. In 3D there is another factor of sqrt(3), but I think that is the reason why VMD had 0s in the rdf for bigger distances.

Christoph

Thanks for the explanation. I was not aware that every particle is considered just once. 

I might be wrong, but from my understanding two interactions in the periodic 1D case would be possible. E.g. for two particles "x" and "o" with periodic boundary "|": o would have one interactions with x for d<L/2 and a second one for 0.5L<d<L, the first at 2 units distance in positive/right direction and the second with at 7 units distance in negative/left direction. So if I understand you correct, only one image of the particle with the minimum distance is considered and all the other periodic images are neglected?

Yes, for the RDF only the first image is considered.

For force interactions it depends, Lennard-Jones usually only uses the first image, but coulomb interactions, as they decay slower, sum over all images (see Ewald summation).

Christoph

That does not sound very consistent to me. Nevertheless Thank you very much for the explanation. Altogether it already helped. Thanks

Actually some codes, e.g. gromacs, have a long range summation for fast decaying Lennard-Jones interactions as well, see the "Lennard-Jones PME" section in the gromacs manual, but it is not very common.

Christoph

To unsubscribe from this group and stop receiving emails from it, send an email to votca+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/votca/d32a304f-e281-4dae-92ec-428661f2a024%40googlegroups.com.