glotzerlab / hoomd-blue Goto Github PK

Original report by Jens Glaser (Bitbucket: jens_glaser, GitHub: jglaser).

In HOOMD 1.0.x pair forces are computed incorrectly on the GPU for some tuning
parameters and system sizes, which (in the best case) results in a crash, but otherwise
affect results in undefined ways. Even though, presumably, only a small fraction of particles is affected (those particle indices which are 'at the end', i.e. do not fill a GPU thread block completely), probably all results that involve either the NeighborList or any standard pair potential need to be double-checked. HPMC is not affected, since it doesn't use the NeighborList or any pair force.

Reproducer script attached. It should lead to a crash after a few 10,000 time steps.
This script requires aniso_int_new, even though the bug is not specific to that branch. I can
try to prepare a stripped down, master-compatible version.

A patch will be uploaded shortly.

Original report by baschult (Bitbucket: baschult, ).

Currently the rigid body documentation is rather sparse. I think it'd be nice to add a rigid body section under concepts (here).

For example, Mayank was making the first steps toward running a simulation and got blocked when he tried to add rigid bodies to a simulation and started by creating a single particle rigid body. This created a body with a zero moment of intertia and resulting in nan for position errors.

This default behavior ought to be changed, but while investigating I noticed that documentation is rather sparse/spread out for rigid bodies.

Original report by Jens Glaser (Bitbucket: jens_glaser, GitHub: jglaser).

It would be nice (e.g. for Gibbs ensemble simulations) to have groups
make their number of members available as a log quantity, e.g. with
log quantities "all_N", or "typeA_N". This requires registering groups with the logger
upon the start of the simulation.

Original report by Jens Glaser (Bitbucket: jens_glaser, GitHub: jglaser).

From the mailing list:

I am wondering if there is something about constrain.sphere that may mess with conservation of momentum in the MTK NVT integrator.  I am running a few test simulations with a few thousand particles and the initial conditions have very nearly zero linear or angular momentum (O(10^-15)).  However, after a few integration steps this jumps to O(10^-3).  I'm not sure if reducing the integration step to 0.001 from 0.005 helps: drift per step is smaller, but the the drift per unit time may not be.

Presumably I could fix this by running update.zero_momentum(), but, since each sphere has a few hundred particles, I packed the simulation box with a few independent spheres that shouldn't talk to each other via global momentum resets.  Also, if linear momentum is not conserved, I can't imagine that the angular momentum would be conserved either.

In case it matters, r_cut is at least as large as the diameter of the sphere.

Sorry about the delay.  I was using a custom potential (1/r^3) and wanted to make sure the same thing happened with a standard one.  Simulations are running in double precision, and mtk=False doesn't seem to help.

The box contains two spheres, one with 2000 particles, the other with 3942.  They are far enough apart to be independent, and the initial configuration of each sphere has nearly zero linear and angular momentum

Original report by Jens Glaser (Bitbucket: jens_glaser, GitHub: jglaser).

these classes still do not use the coeff() class for storing per-type coefficients

I won't update them to provide per-type metadata for now

Original report by me.

For running IMD with force feedback, it is very important to have as high a TPS and as high a VMD frame rate as possible. having to transfer a large number of coordinates can interfere with that. Allowing to use a group with IMD could help a lot.

Original report by me.

Support for compute 1.x is deprecated in HOOMD v1.0. Let's remove all the old legacy codepaths specific to that architecture.

Original report by Steven NA (Bitbucket: yuhangwang, GitHub: yuhangwang).

I tried to compile HOOMD version 1.0.1 using gcc 4.1.2 on CentOS 5.8, but the "make install" did not even progress beyond the first checkpoint. Could you add support for compiling under gcc 4.1.X? Thanks!

Steven

Original report by me.

Using getattr is a bit of a hack. We should use python properties instead to help avoid typos causing problems

Original report by Jens Glaser (Bitbucket: jens_glaser, GitHub: jglaser).

Because the ParticleSelectors use the same way of accessing particle
data as the python data access API (by tag), initialization of groups
for a large MPI job is forbiddingly slow.

The solution to would be to have ParticleSelector only perform local queries, and construct
the global tag table using an MPI_AllGather call.

Original report by Matthew Spellings (Bitbucket: mspells, GitHub: klarh).

On aniso_int_new at least, accessing particle data by tag seems to be an operation which is O(N) in system size with most time spent in ParticleData::getNthTag() and the std::advance method. I guess std::set must need to walk over the whole tree to advance the iterator.

With this bug, setting the types of ~300k particles took 50 minutes on a flux node. Attached is a performance plot (time it takes to set the type of each particle in the system as a function of system size) and a script to generate that plot.

Original report by me.

pair.cgcmm loses performance due to the computation of the virial tensor.

Suggested fix: Write EvaluatorPairCGCMM and use the PotentialPair mechanism and remove the separate CGCMM classes.

Original report by me.

HOOMD's current limit_hours is a poor way to manage wall clock times. We need a simpler more comprehensive solution. One that allows job scripts to set environment variables to control the whole job run time from the start of the script execution.

Original report by Paul Dodd (Bitbucket: the_real_pdodd, GitHub: PaulDodd).

Harmonic bond force is being evaluated to zero during the simulation. This tends to be triggered by successive run() calls on the python side.

Current observations:
0. All integrators and forces are being set (correctly) at the beginning of each run call.

1. The parameters for the potential bond are being set (correctly) at the beginning of the run call.
2. The bond parameters get set to zero at some point after one of the run calls in the GPU kernel but are non-zero outside the kernel.
3. Grabbing the array handle in readwrite mode fixes this issue.
4. Does not occur when building hoomd in debug mode.
5. Does not occur when running with cuda-memcheck.
6. Does not occur when cuda error checking is enabled.

Original report by me.

Need to have nlist commands error out in a more reasonable way when they are called before a pair force is defined.

Original report by me.

True dynamic group updates are challenging, but we could enable common use cases for dynamic groups more easily. For example, applying a thermostat to a slab. To do so, we need to enable integrators to have their group modified. Then we need an example script using the python callback to demonstrate the functionality.

Original report by Åsmund Ervik (Bitbucket: asmunder, GitHub: asmunder).

With the latest "maint" version, hoomd reporting v1.0.1-1-ga9c84ec, I get the following error when trying to specify a bond angle using angle.harmonic. Using angle.table and implementing a harmonic potential myself works just fine.

Edit: bitbucket eats all the whitespace, see the attached file for the error message.

Original report by me.

test/hoomd_script/test_replicate.py is one script that easily produces the problem:

$ python-runner/hoomd /home/joaander/devel/hoomd/test/hoomd_script/test_replicate.py
HOOMD-blue v1.0.3-11-gc6ced02 CUDA SINGLE MPI SSE SSE2 SSE3 SSE4_1 SSE4_2 AVX
Compiled: 04/06/2015
Copyright 2009-2014 The Regents of the University of Michigan.
....
notice(2): -- Neighborlist exclusion statistics -- :
notice(2): Particles with 1 exclusions             : 1760
notice(2): Particles with 2 exclusions             : 13760
notice(2): Neighbors excluded by diameter (slj)    : no
notice(2): Neighbors excluded when in the same body: no
** starting run **
**ERROR**: Particle 0 has NaN for its position.

Many other unit tests trigger the same: NaN for particle positions.

Using git-bisect, I identified that the commit that created the bug is: 2525e28 - pull request #27.

We'll need to get this fixed before a 1.0.4 bugfix release. collins has a Fermi GPU for testing, it is --gpu=2.

Could you look at this Jens? That commit is your fix to nlists on Fermi, and I don't fully follow what it did. You will be more familiar with the changes to spot any potential errors.

Original report by Åsmund Ervik (Bitbucket: asmunder, GitHub: asmunder).

When creating a linear interpolating variant (variant.linear_interp) and specifying the optional argument zero=1e3 (or some number), I get an error. See attached traceback (formatting here is ugly). It seems Python uses a float while C++ wants an unsigned int.

This is with the "maint" branch checked out a few weeks ago, HOOMD reporting version v1.0.1-1-ga9c84ec

Original report by me.

It would be helpful to include the cuda runtime version in the startup message.

Original report by Jens Glaser (Bitbucket: jens_glaser, GitHub: jglaser).

Having this capability has been requested. It would require investigation
if that can be easily implemented within the refactored rigid body framework,
after that one has been merged.

Original report by Jens Glaser (Bitbucket: jens_glaser, GitHub: jglaser).

HOOMD should support Brownian dynamics (zero inertial term)
as a special case of Langevin dynamics, which is currently implemented as integrate.bdnvt()
/bdnvt_rigid().

Original report by me.

The messages from HOOMDVersion.cc should go through globals.msg somehow to avoid sending any output directly to stdout / stderr when using partitioned jobs.

Original report by me.

The current IntegratorVariables? structure for storing restart data is very limited, prone to bugs, and more complicated than it needs to be.

It needs to be completely replaced with a new structure.

First, to simplify matters, the new structure must not require that the data is always kept up to date. Restart data is assumed to be owned entirely by the class using it, which may keep it in whatever form it deems appropriate. Specifically, the restart data stored in SystemDefinition is not used to communicate restart data across classes, except for the purposes of writing/reading to/from a restart file.

To solve this problem, a signal will be added to SystemDefinition? which classes can subscribe to. The signal will be triggered whenever a restart writer requests it (just prior to writing the restart file). On response to this signal, the classes providing the restart data will fill out their appropriate fields.

Second, the restart data needs to be stored in a more general format. Other classes than Integrators may want to store restart data. For readability in the file, a set of name/value pairs would be nice. I'm also considering the possibility of a tree structure of restart data, although I don't see the use case for this at the moment.

The biggest challenge to solve with restart files is the naming of the data elements and consequent reassignment of the proper data when it is read in. The current code performs this by maintaining an index which it increments each time a new set of restart variables is registered. This means that the same script commands must appear in the same order in the script file for the restart data to be properly assigned back to the right class. While this seems annoying, it actually makes for a very simple restartable job script: using run_upto and limit_hours, one can write a job script that may be resubmitted over and over again and will always pick up where it left off.

Changing this to use string names assigned to the classes from python doesn't change this behavior at all. These names are also auto-incremented. Also, computes, analyzers, and updaters do not know their names in the current code anyways. Allowing the user to set names is not unprecedented (force computes currently allow this for logging purposes), but it would require some changes to the python api and so forth....... With default arguments, this could be made compatible with existing scripts. Custom names would also allow restart jobs that are not necessarily the same structure as the original script. I will ponder the complications in this.

Regardless of how the name is assigned, there will be a single unique string name per Compute/Analyzer/Updater?.

Here are my current thoughts on the implementation. I've got an HDF5 file format backend in mind for writing this data out, however there is no reason that the XML file format could not be updated as well.

1. Restart data is listed as a string->value mapping of RestartDataNode nodes. 1. Each named node is also given the attributes (not optional!) type (class name), and version. The version is so that restart data written by newer versions of the class will not be misread by older versions and so that newer versions may correctly read older versions data (or at least just error out or ignore it). 1. Each named node contains a string->value mapping of RestartDataElement elements. 1. Each class can register its name in the mapping of nodes and either read existing data in, or create elements in the node.

The templated element type is needed so that Scalars, unsigned ints, ints, and whatever else may be saved. However, this does complicate the API a bit - as there will need to be large switch statements when creating the data structure from a file. That, and writing the copy constructor and = operator will be a bit annoying. Need to think of alternatives.

The easiest way to keep the code for writing output simplified is to embed that into the class directly. In that case, a simple walk down the nodes and elements is all that is needed to write things out, with C++ virtual calls handling all the necessary type determination.

Original report by me.

Jens already has a branch + some patches for deterministic hoomd on the GPU. Just need to review and incorporate them.

Original report by M. Eric Irrgang (Bitbucket: m_eric_irrgang, GitHub: eirrgang).

There are constructors allowing implicit casting of vec3 and quat to whatever type is Real, but not so for , so constructing a vec3 from a vec3 produces a compiler error.

One or more of these behaviors may be by design (though I'm not sure of the reasoning, possibly to avoid accidental performance degradation with implicit data copies?), but I have created branch vectormath_constructors with a minor patch.

Original report by me.

It may be useful in some circumstances to have more than one neighbor list. For example, nlist1 with rcut 1 for one pair potential and nlist2 with rcut 10 for another. This shouldn't be too hard to enable as NeighborList is a self-contained class. Mainly, the pair potentials need an option added to use their own nlist and the run() initialization needs to be updated to update rcuts of all neighbor lists.

This also probably means the end of the built-in nlist command. User scripts will have to adapt. Might as well remove the built in sort command while we are at it.

I'm not sure if the concept of multiple neighbor lists works well with the MPI branch, however.

Original report by me.

Add standard anisotropic potentials

Original report by me.

This causes rigid body system to have invalid values for velocities, as it will ignore those present in the original input file.

Original report by me.

Some users wish for use-cases where pair potentials are off by default and only turned on when pair coeffs are set. More generally, there needs to be a mechanism by which to disable pair potentials. Setting r_cut=0 is the most sensible option.
Specifically:

• pair.table should accept rmin=rmax=0 to signify that the given pair is to be ignored. The user should be able to set a default rmin and rmax.
• update pair coeffs should look at rcut first. If it is 0, it will not lookup the other coeffs and will simply set 0's.

This will require some modifications to the coeff error check - it will need to allow pairs where r_cut is 0 and no other params are set.
Then a user merely needs to set the default r_cut of 0 to flag all interactions off by default.

Original report by me.

The plan is to remove the wall data structure as it is now and re-implement walls as external potentials. There have been numerous requests for alternate functional forms, and I'd like to see spherical and cylindrical walls.

Original report by Åsmund Ervik (Bitbucket: asmunder, GitHub: asmunder).

I just spent two hours trying to figure out why I could not build with CUDA on cluster I got access to. I finally had to read through CMake_build_options.cmake to find that CUDA was being disabled because it was using the Intel C++ compiler.

Could we please have CMake issue a warning when this happens?

Original report by Matthew Spellings (Bitbucket: mspells, GitHub: klarh).

The system_data accessor for the box quantity does not properly set the number of dimensions; that is, even for 2D simulations, it gives a data.boxdim object with dimensions == 3.

Original report by Jens Glaser (Bitbucket: jens_glaser, GitHub: jglaser).

Currently, we throw an MPI_Abort when an error occurs inside a simulation.
It's (easily) possible to catch that one, say, in a unit test (such as using assertRaises())

Proposed solution due to Frank Wilmore:

When an error occurs, set a flag, but continue until the next collective call.
When the collective is issued, pass an extra status byte along with it (or an extra
collective call). Reduce over status and abort gracefully if required.

Original report by me.

As reported on the hoomd-users mailing list, two component EAM systems produce incorrect results. See the mailing list message for a repro case.

Some investigation has revealed numerous bugs in the way that types names are handled and/or in the way that type pairs are used to index into the lookup tables. For instances, swapping the order of type A and type B in the input file results in different forces being computed on a given particle.

Furthermore, the GPU computation does not return the same results when called multiple times. Cause unknown.

Original report by me.

Snapshots badly need numpy array access.

Original report by me.

HOOMD's GPU prioritization picks K40 over M6000 for some reason.

Original report by me.

It would be nice to have a command similar to LAMMPs fix box/relax.

This implies that we should be able to compute the virial tensor only (excluding the kinetic part of the stress tensor).
ComputeThermo could probably be generalized to this extent.

Probably no need for a more advanced minimization scheme such as FIRE, a simple first-order ODE relaxation should be sufficient.

Original report by me.

The new one is superior

Original report by Jens Glaser (Bitbucket: jens_glaser, GitHub: jglaser).

Due to a missing argument in a C++ method call, group.rigid() did not work properly.

The branch fix_rigid_body_group contains a fix

Original report by me.

Write a documentation concepts page on restartable jobs.

Original report by me.

In the messenger branch, the new Messenger class is passed around through the ExecutionConfiguration. In order to allow the CHECK_CUDA_ERROR() macro to work, and to allow me to do mass search and replace text on error and warning messages, I want every class that needs one a member variable m_exec_conf. Most had exec_conf previously, so I added an additional m_exec_conf.

The dual exec_conf and m_exe_conf is weird - exec_conf was from legacy code. m_exec_conf is the new standard. But I don't want to remove the old one until we have fewer branches open in hoomd so as to avoid annoying merge conflicts.

This ticket serves as a reminder to complete the consolidation after the big outstanding feature branches are merged into master.

Original report by me.

Allow for easier restarting with run_upto by allowing dumps to be phase locked.

Original report by Åsmund Ervik (Bitbucket: asmunder, GitHub: asmunder).

When I try to change the timestep like so:

#!Python
#...
# run with small time step intially
integrate.mode_standard(dt=0.001)
run(1e4)
# increase time step when system has relaxed
integrate.mode_standard(dt=0.002)
run(1e5)

it works fine on a single GPU, but segfaults on multiple GPUs. The segfault happens when the "run(1e5)" starts. Attached is a modified version of the standard lj_liquid_bmark.hoomd that demonstrates this. On a single GPU the attached file runs fine, on two or more GPUs with MPI it segfaults e.g. as shown below. I've seen this on K20s, K40s and K80s on versions 1.0.2 and 1.0.4.

HOOMD-blue v1.0.4 CUDA SINGLE MPI SSE SSE2 SSE3 SSE4_1 SSE4_2 AVX
Compiled: 04/08/2015
(...)
[GPUprecision:11019] *** Process received signal ***
[GPUprecision:11020] *** Process received signal ***
[GPUprecision:11020] Signal: Segmentation fault (11)
[GPUprecision:11020] Signal code: Address not mapped (1)
[GPUprecision:11020] Failing at address: 0x61
[GPUprecision:11019] Signal: Segmentation fault (11)
[GPUprecision:11019] Signal code: Address not mapped (1)
[GPUprecision:11019] Failing at address: 0x61
[GPUprecision:11019] [ 0] /usr/lib/libc.so.6(+0x33b20)[0x2b05bfb72b20]
[GPUprecision:11019] [ 1] [GPUprecision:11020] [ 0] /usr/lib/libc.so.6(+0x33b20)[0x2acfab620b20]
[GPUprecision:11020] [ 1] /usr/bin/../lib/hoomd/python-module/hoomd.so(_ZN10Integrator14determineFlagsEj+0x96)[0x2b05bdd779a6]
[GPUprecision:11019] [ 2] /usr/bin/../lib/hoomd/python-module/hoomd.so(_ZN10Integrator14determineFlagsEj+0x96)[0x2acfa98259a6]
[GPUprecision:11020] [ 2] /usr/bin/../lib/hoomd/python-module/hoomd.so(_ZN5boost6detail8function21function_obj_invoker1INS_3_bi6bind_tISt6bitsetILm32EENS_4_mfi3mf1IS6_10IntegratorjEENS3_5list2INS3_5valueIPS9_EENS_3argILi1EEEEEEES6_jE6invokeERNS1_15function_bufferEj+0x21)[0x2b05bdd7e4d1]
[GPUprecision:11019] [ 3] /usr/bin/../lib/hoomd/python-module/hoomd.so(_ZN5boost6detail8function21function_obj_invoker1INS_3_bi6bind_tISt6bitsetILm32EENS_4_mfi3mf1IS6_10IntegratorjEENS3_5list2INS3_5valueIPS9_EENS_3argILi1EEEEEEES6_jE6invokeERNS1_15function_bufferEj+0x21)[0x2acfa982c4d1]
[GPUprecision:11020] [ 3] /usr/bin/../lib/hoomd/python-module/hoomd.so(_ZN5boost8signals26detail12signal1_implISt6bitsetILm32EEj21comm_flags_bitwise_oriSt4lessIiENS_8functionIFS4_jEEENS8_IFS4_RKNS0_10connectionEjEEENS0_5mutexEEclEj+0x245)[0x2b05bdb0f6e5]
[GPUprecision:11019] [ 4] /usr/bin/../lib/hoomd/python-module/hoomd.so(_ZN5boost8signals26detail12signal1_implISt6bitsetILm32EEj21comm_flags_bitwise_oriSt4lessIiENS_8functionIFS4_jEEENS8_IFS4_RKNS0_10connectionEjEEENS0_5mutexEEclEj+0x245)[0x2acfa95bd6e5]
[GPUprecision:11020] [ 4] /usr/bin/../lib/hoomd/python-module/hoomd.so(_ZN12Communicator11communicateEj+0x1f)[0x2acfa9597e2f]
[GPUprecision:11020] [ 5] /usr/bin/../lib/hoomd/python-module/hoomd.so(_ZN12Communicator11communicateEj+0x1f)[0x2b05bdae9e2f]
[GPUprecision:11019] [ 5] /usr/bin/../lib/hoomd/python-module/hoomd.so(_ZN17IntegratorTwoStep6updateEj+0x176)[0x2acfa987fe86]
[GPUprecision:11020] [ 6] /usr/bin/../lib/hoomd/python-module/hoomd.so(_ZN17IntegratorTwoStep6updateEj+0x176)[0x2b05bddd1e86]
[GPUprecision:11019] [ 6] /usr/bin/../lib/hoomd/python-module/hoomd.so(_ZN6System3runEjjN5boost6python3api6objectEdj+0x838)[0x2acfa9812ad8]
[GPUprecision:11020] [ 7] /usr/bin/../lib/hoomd/python-module/hoomd.so(_ZN6System3runEjjN5boost6python3api6objectEdj+0x838)[0x2b05bdd64ad8]
[GPUprecision:11019] [ 7] /usr/bin/../lib/hoomd/python-module/hoomd.so(_ZN5boost6python7objects23caller_py_function_implINS0_6detail6callerIM6SystemFvjjNS0_3api6objectEdjENS0_21default_call_policiesENS_3mpl7vector7IvRS5_jjS7_djEEEEEclEP7_objectSI_+0x20a)[0x2acfa981573a]
[GPUprecision:11020] [ 8] /usr/lib/libboost_python3.so.1.57.0(_ZNK5boost6python7objects8function4callEP7_objectS4_+0x28d)[0x2acfabbd430d]
[GPUprecision:11020] [ 9] /usr/bin/../lib/hoomd/python-module/hoomd.so(_ZN5boost6python7objects23caller_py_function_implINS0_6detail6callerIM6SystemFvjjNS0_3api6objectEdjENS0_21default_call_policiesENS_3mpl7vector7IvRS5_jjS7_djEEEEEclEP7_objectSI_+0x20a)[0x2b05bdd6773a]
[GPUprecision:11019] [ 8] /usr/lib/libboost_python3.so.1.57.0(+0x2b528)[0x2acfabbd4528]
[GPUprecision:11020] [10] /usr/lib/libboost_python3.so.1.57.0(_ZNK5boost6python7objects8function4callEP7_objectS4_+0x28d)[0x2b05c012630d]
[GPUprecision:11019] [ 9] /usr/lib/libboost_python3.so.1.57.0(_ZN5boost6python21handle_exception_implENS_9function0IvEE+0x73)[0x2acfabbde043]
[GPUprecision:11020] [11] /usr/lib/libboost_python3.so.1.57.0(+0x29d09)[0x2acfabbd2d09]
[GPUprecision:11020] [12] /usr/lib/libboost_python3.so.1.57.0(+0x2b528)[0x2b05c0126528]
[GPUprecision:11019] [10] /usr/lib/libboost_python3.so.1.57.0(_ZN5boost6python21handle_exception_implENS_9function0IvEE+0x73)[0x2b05c0130043]
[GPUprecision:11019] [11] /usr/lib/libpython3.4m.so.1.0(PyObject_Call+0x91)[0x2acfaa374fb1]
[GPUprecision:11020] [13] /usr/lib/libboost_python3.so.1.57.0(+0x29d09)[0x2b05c0124d09]
[GPUprecision:11019] [12] /usr/lib/libpython3.4m.so.1.0(PyObject_Call+0x91)[0x2b05be8c6fb1]
[GPUprecision:11019] [13] /usr/lib/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x274a)[0x2acfaa4256ca]
[GPUprecision:11020] [14] /usr/lib/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x274a)[0x2b05be9776ca]
[GPUprecision:11019] [14] /usr/lib/libpython3.4m.so.1.0(PyEval_EvalCodeEx+0x87f)[0x2acfaa42bbaf]
[GPUprecision:11020] [15] /usr/lib/libpython3.4m.so.1.0(PyEval_EvalCodeEx+0x87f)[0x2b05be97dbaf]
[GPUprecision:11019] [15] /usr/lib/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x6d2f)[0x2acfaa429caf]
[GPUprecision:11020] [16] /usr/lib/libpython3.4m.so.1.0(PyEval_EvalFrameEx+0x6d2f)[0x2b05be97bcaf]
[GPUprecision:11019] [16] /usr/lib/libpython3.4m.so.1.0(PyEval_EvalCodeEx+0x87f)[0x2acfaa42bbaf]
[GPUprecision:11020] [17] /usr/lib/libpython3.4m.so.1.0(PyEval_EvalCodeEx+0x87f)[0x2b05be97dbaf]
[GPUprecision:11019] [17] /usr/lib/libpython3.4m.so.1.0(PyEval_EvalCode+0x1b)[0x2b05be97dc5b]
[GPUprecision:11019] [18] /usr/lib/libpython3.4m.so.1.0(+0x135f34)[0x2b05be999f34]
[GPUprecision:11019] [19] /usr/lib/libpython3.4m.so.1.0(PyRun_FileExFlags+0x95)[0x2b05be99c1b5]
[GPUprecision:11019] [20] /usr/lib/libpython3.4m.so.1.0(PyRun_SimpleFileExFlags+0x113)[0x2b05be99d193]
[GPUprecision:11019] [21] /usr/lib/libpython3.4m.so.1.0(PyEval_EvalCode+0x1b)[0x2acfaa42bc5b]
[GPUprecision:11020] [18] /usr/lib/libpython3.4m.so.1.0(+0x135f34)[0x2acfaa447f34]
[GPUprecision:11020] [19] /usr/lib/libpython3.4m.so.1.0(PyRun_FileExFlags+0x95)[0x2acfaa44a1b5]
[GPUprecision:11020] [20] /usr/lib/libpython3.4m.so.1.0(PyRun_SimpleFileExFlags+0x113)[0x2acfaa44b193]
[GPUprecision:11020] [21] /usr/lib/libpython3.4m.so.1.0(Py_Main+0xd5c)[0x2acfaa4613fc]
[GPUprecision:11020] [22] hoomd(main+0x4f1)[0x40a121]
[GPUprecision:11020] [23] /usr/lib/libc.so.6(__libc_start_main+0xf0)[0x2acfab60d040]
[GPUprecision:11020] [24] hoomd[0x40a4ea]
[GPUprecision:11020] *** End of error message ***
/usr/lib/libpython3.4m.so.1.0(Py_Main+0xd5c)[0x2b05be9b33fc]
[GPUprecision:11019] [22] hoomd(main+0x4f1)[0x40a121]
[GPUprecision:11019] [23] /usr/lib/libc.so.6(__libc_start_main+0xf0)[0x2b05bfb5f040]
[GPUprecision:11019] [24] hoomd[0x40a4ea]
[GPUprecision:11019] *** End of error message ***
--------------------------------------------------------------------------
mpirun noticed that process rank 0 with PID 11019 on node GPUprecision exited on signal 11 (Segmentation fault).
--------------------------------------------------------------------------

Original report by me.

The rigid body code needs refactoring to work with the new anisotropic integrators and to simplify standard use-cases.

Original report by me.

Recent cuda runtimes changed the behavior of the cudaDriverGetVersion API call. It is no longer a reliable way to check if drivers are actually installed. Instead, we also need to check for errors on cudaGetDeviceCount() and report that as a missing driver.

Original report by me.

Original report by me.

init.read_xml creates and deletes .xml files. When the unit tests are run in parallel (ctest -j3), this causes a race condition if at least two alternates of this run are performed in parallel (mpi, gpu, cpu).

Original report by me.

If ParticleData is re-initialized from a snapshot with a different number of types,
pair potentials and all other classes that keep a per-type (pair) data structure need
to re-initialize those data structures.

Alternately, just disallow changing the number of types.

Original report by me.

Allows for easier restarting.