Shrink-wrapped boundary not updating

Hi,

I am using Lammps version March 8 2018.

I am trying to do a simulation of a creep test on a small (5,5) carbon nanotube of 680. The carbon nanotube is in the y direction, with the bottom 10 atoms fixed in place with fix setforce, and the top 10 atoms moving with a constant velocity set by fix move linear.

I am noticing that in my simulation the atoms coordinates go outside the box length in the y direction:

ITEM: NUMBER OF ATOMS
10
ITEM: BOX BOUNDS ss ss ss
4.9629332716100066e+002 5.0370667284677961e+002
5.1247402264297568e+002 6.0303507326258386e+002
4.9626722541064396e+002 5.0373277458271593e+002
ITEM: ATOMS id type x y z
671 1 503.607 603.726 500.505
672 1 503.534 603.726 499.121
673 1 501.594 603.726 496.726
674 1 500.256 603.726 496.367
675 1 497.379 603.726 497.472
676 1 496.624 603.726 498.634
677 1 496.786 603.726 501.712
678 1 497.657 603.726 502.788
679 1 500.635 603.726 503.586
680 1 501.928 603.726 503.09

I am using a shrink-wrapped boundary on for all 3 directions. I would like the box bounds to update more often, like every time the neighbor lists are updated, for example. Is there a way to update the box bounds more often?

Thanks,
Kyle Rego

knotscript.txt (1.96 KB)

nanotube.data (42.2 KB)

Hi,

I am using Lammps version March 8 2018.

I am trying to do a simulation of a creep test on a small (5,5) carbon
nanotube of 680. The carbon nanotube is in the y direction, with the
bottom 10 atoms fixed in place with fix setforce, and the top 10 atoms
moving with a constant velocity set by fix move linear.

I am noticing that in my simulation the atoms coordinates go outside the
box length in the y direction:

ITEM: NUMBER OF ATOMS
10
ITEM: BOX BOUNDS ss ss ss
4.9629332716100066e+002 5.0370667284677961e+002
5.1247402264297568e+002 6.0303507326258386e+002
4.9626722541064396e+002 5.0373277458271593e+002
ITEM: ATOMS id type x y z
671 1 503.607 603.726 500.505
672 1 503.534 603.726 499.121
673 1 501.594 603.726 496.726
674 1 500.256 603.726 496.367
675 1 497.379 603.726 497.472
676 1 496.624 603.726 498.634
677 1 496.786 603.726 501.712
678 1 497.657 603.726 502.788
679 1 500.635 603.726 503.586
680 1 501.928 603.726 503.09

I am using a shrink-wrapped boundary on for all 3 directions. I would
like the box bounds to update more often, like every time the neighbor
lists are updated, for example. Is there a way to update the box bounds
more often?

​to update the boundaries more often, you have to update the neighbor lists more often, and thus negatively impact performance.
that said, why do you care about those boundaries? they have no real meaning for the physics of your results. whether you have shrink-wrap or fixed boundaries, any non-period​ic boundary is arbitrary and essentially the size of the box in that direction has to be considered as if it is infinite. the main benefits for shrinkwrap boundaries is to transparently accommodate changes to the extent of a system beyond an estimated initial boundary and to have a more efficient domain decomposition and thus better parallel efficiency.

axel.

Hi Axel,

Thanks for your input - I looked again at the documentation for neigh_modify and saw that I had missed seeing the check keyword that affects when the neighbor lists were rebuilt, changing that to 'no' appears to have fixed my concern. My mistake for overlooking that in the documentation.

The reason why I care about the boundaries is I am using them to calculate the strain for stress-strain curves. I am sort of exploring how to calculate this without using the fix deform because I do not think that is appropriate for what I have in mind next, which is to see how tying a polymer into an overhand knot affects its mechanical properties. I am still thinking about if stress-strain is a good thing to look at for something tied into a knot, which it may very well not be. Anyways, thanks for your response.

Kyle Rego

Hi Axel,

Thanks for your input - I looked again at the documentation for
neigh_modify and saw that I had missed seeing the check keyword that
affects when the neighbor lists were rebuilt, changing that to ‘no’
appears to have fixed my concern. My mistake for overlooking that in the
documentation.

The reason why I care about the boundaries is I am using them to
calculate the strain for stress-strain curves. I am sort of exploring

​please note, that a) this is a rather crude approximation, and b) the min/max extent of a group of atoms can be accurately computed via compute reduce min​/max regardless of whether neighborlists are updated or not.

axel.