Particle with unique tag ABCD has NaN for its position [recurring error]

117 views
Skip to first unread message

Anna Ashkinazi

unread,
Dec 5, 2023, 5:32:10 PM12/5/23
to hoomd-users
Hi all,

I've been trying to run simulations of a system of bent polymers consisting of 21 beads each. Creating the initial state always seems to go fine, I can see no issues with the GSD file that running the code in setup.py (attached) outputs. When I try to run simulation.py,, however, the output is 'line 123, in <module> simulation.run(1000) <...> RuntimeError: Particle with unique tag 2260 has NaN for its position.' I've tried to run these scripts earlier today with different scaling parameters; it has only produced a readable trajectory.gsd file with spacing parameters 2, 3 and 1.5 in x, y and z respectively, but the box inconveniently comes out looking like an extremely thin, long, narrow parallelepiped. Other combination of spacing parameters produce errors like 'slurmstepd: error: Detected 1 oom-kill event(s) in <...>. Some of your processes may have been killed by the cgroup out-of-memory handler.' and 'segmentation fault (core dumped)'. If anyone could have a look and let me know what I'm doing wrong, I'd be very grateful!
Best,
Anna
simulation.py
setup.py

Anna Ashkinazi

unread,
Dec 5, 2023, 5:41:18 PM12/5/23
to hoomd-users
(P.S.: I'm trying to run a simulation with lc=20, ang=135, nb=21, packing=0.5, betaP=0.8.)

Joshua Anderson

unread,
Dec 6, 2023, 10:09:08 AM12/6/23
to hoomd...@googlegroups.com
Anna,

Thanks for the complete question with script. However, I don't have time right now to try running your script. Here is the first thing I would check: Call simulation.run(0) and then write out the .gsd file. See if any particles are overlapping in that file. I mention this because hoomd will apply rotations to the constituent particles and they may not match the positions in the gsd file created by setup.py.

Regarding the out of memory errors - the Cell neighbor list uses an amount of memory proportional to the box volume. Out of memory errors typically occur when running large, dilute simulation boxes. You can reduce the memory usage of Cell by increasing the value of buffer. Alternately, you can use the Tree neighbor list which uses memory that scales with the number of particles.
------
Joshua A. Anderson, Ph.D.
Research Area Specialist, Chemical Engineering, University of Michigan

-- 
You received this message because you are subscribed to the Google Groups "hoomd-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hoomd-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hoomd-users/8130ec04-7c4a-4347-8c62-f507f0091263n%40googlegroups.com.

Anna Ashkinazi

unread,
Dec 6, 2023, 4:13:21 PM12/6/23
to hoomd-users
Joshua--
Thank you for the response! I've tried calling simulation.run(0) and the .gsd file looks perfectly fine to me, identical to the one produced by setup.py, no particle overlaps. The error seems to occur in the simulation.run(1000) command, which is used to thermalise momenta (the most recent call in the error message is traced back to that line). The particle that has NaN for its position is, at least in this particular run, close to one of the box walls in the snapshot generated, if this is useful information in any way.
Best,
Anna

Joshua Anderson

unread,
Dec 6, 2023, 4:26:07 PM12/6/23
to hoomd...@googlegroups.com
Anna,

The other most common cause of NaN particle positions a large time step size that leads to instability. You could try a smaller dt.

Can you share the specific commands to type on the command line (or provide scripts with hard-coded parameters) so I can attempt to reproduce this later this week?

------
Joshua A. Anderson, Ph.D.
Research Area Specialist, Chemical Engineering, University of Michigan

Anna Ashkinazi

unread,
Dec 7, 2023, 3:46:03 AM12/7/23
to hoomd-users
Joshua--

Trying a smaller dt seems to make the scripts work, thank you! However, bizarrely, altering the dimensions of the box in the setup script doesn't seem to have any visual effect on the trajectory.gsd file -- the box is still as long, thin and narrow as it is with smaller spacingx and spacingy, which hinders visual evaluation of the results. Attaching the submission script (I run the scripts by submitting them as jobs to my university's computational cluster).

Best regards,
Anna
submit.sh

Joshua Anderson

unread,
Dec 7, 2023, 7:04:48 AM12/7/23
to hoomd...@googlegroups.com
Anna,

I'm glad that a smaller dt value worked. With rigid bodies, a smaller dt is often necessary due to the rotational motion of the bodies.

Regarding your question on the box dimensions, I can confirm that your setup.py script ignores the "packing" argument:
❯ python setup.py 20 150 21 0.5 0.8
❯ python -c "import gsd.hoomd; print(gsd.hoomd.open('test.gsd')[0].configuration.box)"
[ 46.03075  20.      155.79239   0.        0.        0.     ]
❯ rm *.gsd
❯ python setup.py 20 150 21 0.1 0.8
❯ python -c "import gsd.hoomd; print(gsd.hoomd.open('test.gsd')[0].configuration.box)"
[ 46.03075  20.      155.79239   0.        0.        0.     ]

Line 179 in your script sets the box dimensions. You need to ensure that you provide the desired values for Lx, Ly, and Lz.
frame.configuration.box = [Lx, Ly, Lz, 0, 0, 0]. Your script computes a `rescale` value based on `packing`, but does not use `rescale`.

Also, looking at your submit script - I would highly recommend using signac, another open source software tool that we develop, to organize your data.
------
Joshua A. Anderson, Ph.D.
Research Area Specialist, Chemical Engineering, University of Michigan

Anna Ashkinazi

unread,
Dec 8, 2023, 9:24:57 AM12/8/23
to hoomd...@googlegroups.com
Joshua — thank you, this should resolve my question (I was manipulating the Li parameters to set the box dimensions, but the ratio x:y:z was still much lower than I need for good resolution). I will try to edit the code and let you know if any of the issues persist. Yes, the rescale value was left over from an earlier version of the code - its main purpose was not to actually set the packing fraction, but rather to calculate it based on the other inputs (even so, it was in the wrong place in the script for that). I will look into signac as well. Thank you again for all the answers!

Best regards,
Anna


Am 7.12.2023 um 12:04 schrieb Joshua Anderson <joaa...@umich.edu>:

Anna,
Reply all
Reply to author
Forward
0 new messages