Possible bugs in new walls

[arash.nik...@gmail.com]

I believe that I have encountered several bugs when using the new wall structure of HOOMD-blue, which I have outlined below. I am running HOOMD-blue v1.3.1 CUDA (7.5) on a GTX 690, compiled with GCC v. 4.9.2 and Python 2.7.9.

(1) HOOMD-blue crashes with an error message when I create a system with a spherical confinement and place a particle exactly on the origin of the geometry helper. The exact error message is:

**ERROR**: Particle with unique tag 0 has NaN for its position.
Traceback (most recent call last):
  File "testSphere.py", line 22, in <module>
    run(1e5)
  File "/opt/hoomd-blue-v1.3.1/bin/../lib/hoomd/python-module/hoomd_script/__init__.py", line 270, in run
    globals.system.run(int(tsteps), callback_period, callback, limit_hours, int(limit_multiple));
RuntimeError: Error computing cell list

The error disappears and the simulation runs fine if I slightly offset the particle position, or remove the spherical cavity. I have created a small test script (testSpher.py) for reproducing this error.

(2) HOOMD-blue crashes immediately when I try to create a planar confinement. The exact error message is:

Traceback (most recent call last):
  File "testPlane.py", line 22, in <module>
    run(1e5)
  File "/opt/hoomd-blue-v1.3.1/bin/../lib/hoomd/python-module/hoomd_script/__init__.py", line 236, in run
    globals.integrator.update_forces();
  File "/opt/hoomd-blue-v1.3.1/bin/../lib/hoomd/python-module/hoomd_script/integrate.py", line 167, in update_forces
    f.update_coeffs();
  File "/opt/hoomd-blue-v1.3.1/bin/../lib/hoomd/python-module/hoomd_script/wall.py", line 635, in update_coeffs
    external._external_force.update_coeffs(self);
  File "/opt/hoomd-blue-v1.3.1/bin/../lib/hoomd/python-module/hoomd_script/external.py", line 274, in update_coeffs
    fcoeff = self.process_field_coeff(self.field_coeff);
  File "/opt/hoomd-blue-v1.3.1/bin/../lib/hoomd/python-module/hoomd_script/wall.py", line 618, in process_field_coeff
    return hoomd.make_wall_field_params(coeff, globals.exec_conf);
AttributeError: plane instance has no attribute 'r'

Judging from the error message, it seems that the function process_field_coeff is trying to process the attribute 'r' which does not exist for planar walls. I have created a small test script (testPlane.py) for reproducing this error.

Thank you very much for checking this. Please let me know if you were able to reproduce these errors and whether you need further information.

Best regards,

Arash Nikoubashman

[arash.nik...@gmail.com]

(3) While further testing the new walls, I encountered another problem regarding the energy logging. According to the HOOMD-blue documentation it should be possible to log the wall energy through the keyword 'external_wall_lj_energy'. Unfortunately, HOOMD-blue reports the following warning when I add the keyword to the analyzer:

*Warning*: analyze.log: Log quantity external_wall_lj_energy is not registered, logging a value of 0

I have created a small test script (testOutput.py) for reproducing this error. I have checked the source code of EvaluatorWalls.h on btibucket, and believe that the keyword should be 'external_walls_lj_energy' instead of 'external_wall_lj_energy'. At least, this version does not result in a warning.

Best regards,

Arash Nikoubashman

[James Proctor]

Your problems in 1 have been noted and fixed. I had what I believed was a solution for this case, however it was compiler dependent apparently. The fix should be merged in soon and included in the next release.

The problem in 2 is not actually an issue with the code, though I agree that error is far less than helpful, and I did not receive it on my install. The actual problem with the script however, is that you have incomplete confinement. So your particle is free to approach the wall from the opposite side, at which it will experience a ridiculous force and be thrown out of the simulation box. See the part of the documentation referring to half spaces. This is especially important for planes since they cannot form a complete confinement with just one.

[James Proctor]

I've also included a fix for this, there was an inconsistency between the code and documentation. This will also be fixed soon. However, if you desire a brief fix you can just write _walls_ instead of _wall_ and it will work. One additional thing that has already been fixed is the logging wasn't working properly for contributions from multiple geometries before. This has also been fixed. Thanks for finding these inconsistencies.

[arash.nik...@gmail.com]

Dear James,

Thank you very much for addressing these issues so quickly. I have understood your explanation/interpretation of error #2, but I believe that I am encountering a different problem: in my case, the simulation is not even starting, so the particles cannot be catapulted out of the system. It seems that there is a problem with how the coefficients are generated/passed on the python level, since it attempts to pass a value for 'r', although I have not specified it in the script. Are you able to reproduce this error with the release version 1.3.1?

As for error #3, I have not pulled the updated version of the code, but tried to compute the wall energy using 'external_walls_lj_energy'. The simulation starts and runs without problems, but always reports an energy of 0 although the particles clearly touch the surface. I will test again once the latest pull request has been merged into the main branch.

Best regards,

Arash

[James Proctor]

I haven't been able to replicate your issues with #2. What I ran with the modification I specified had no issues in running. As I said, its a very odd issue to get for that specific setup. If you could print the the walls_structure and check that it has been stored in the planes section. As for passing in between the python and C, I'm afraid that's more complicated, but I'll attempt to check what issues could occur there. As for #3, that's the additional error I specified fixing that will be released. I'm surprised that it is exactly 0, however, so I'll look into it more in depth.

[Michael Howard]

You both might also want to check your python versions -- maybe a python2 vs. python3 problem?

[James Proctor]

Very good callMichael. It was a python 2 issue, specifically with that functionality of adding many objects in one line.

Arash, I'll work on fixing it, but for now, please use the more robustly supported methods of adding walls which would be

planeWall = wall.group()

planeWall.add_plane(origin=(0,0,4), normal=(0,0,-1))

# and complete containment

planeWall.add_plane(origin=(0,0,-4), normal=(0,0,1))

That syntax had no issues in python 3, so it will take some investigating. But as you can see if you print the structure using the other method, python stores the plane you entered improperly in the spheres.

So it seems that some type matching is reading a false positive in python 2. I apologize for this oversight, I don't actively develop in python 2, however I should have run a more robust test case.

[James Proctor]

As a quick follow up, the initial suspicion was correct. I was using type matching to classify which category each should be input to. 

Python 3:

>>> type(wall.plane())

<class 'hoomd_script.wall.plane'>

>>> type(wall.sphere())

<class 'hoomd_script.wall.sphere'>

Python 2:

>>> type(wall.plane())

<type 'instance'>

>>> type(wall.sphere())

<type 'instance'>

I will make a note in the documentation that the one line wall.group(...) initialization is not supported for python 2 unless you'd like to contribute another idea/method that works in both.

As I said before however, the other functions were robustly tested and will work in each case. So just create a wall group object and use the class functions to add to it.

You can also modify the list directly and simply append your planes directly into your planeWall.plane list. 

The wall structures only exist to hold information in a form that the c code is ready to receive. So feel free to use them whichever ways works for you.

[Michael Howard]

Glad to hear my guess helped. Do your classes inherit explicitly from object? This usually fixes the problem you reported. Just change the constructors to be like:

class plane(object):

(This is the recommended inheritance for all objects in python2, and should just be superfluous in python3.)

--Mike

[Michael Howard]

(And by constructor, I meant class definition...)

[Joshua Anderson]

Arash,

I tested your scripts (unmodified) against the latest "fix" branch for this bug with a python2 build of hoomd. I replicate the misidentified plane problem, but cannot replicate the logger problem. As Michael points out, a simple inherit from object may fix this problem. I recommend using isinstance() rather than type().

Your testOutput.py script generates a log.dat with non-zero entries in it. There are many 0 entries where the particles are not near the wall, but there are many steps in a row where there is a particle near the wall:

92264   0
92265   0
92266   0
92267   0
92268   0
92269   0
92270   0
92271   0
92272   0
92273   -7.285368611e-06
92274   -4.075474499e-05
92275   -7.441821072e-05
92276   -0.0001082396629
92277   -0.0001422429632

------
Joshua A. Anderson, Ph.D.
Research Area Specialist, Chemical Engineering, University of Michigan
Phone: 734-647-8244
http://www-personal.umich.edu/~joaander/

On Thu, Feb 4, 2016 at 10:53 PM, Michael Howard <howard....@gmail.com> wrote:

(And by constructor, I meant class definition...)

--
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 post to this group, send email to hoomd...@googlegroups.com.
Visit this group at https://groups.google.com/group/hoomd-users.
For more options, visit https://groups.google.com/d/optout.