KIM ID VC_881176209980_004-and-MO_380272712420_000-vr
KIM ID (with timestamp) VC_881176209980_004-and-MO_380272712420_000-1613513350-vr
KIM Item Type Verification Result
Verification Check ThreadSafety__VC_881176209980_004
Model MEAM_LAMMPS_WangOhLee_2020_CuMo__MO_380272712420_000
Whetstone Benchmark

Measured in Millions of Whetstone Instructions Per Second (MWIPS)
CPU Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
The amount of time the CPU was busy executing code in user space.

Measured in seconds
Usertime × Whetstone Benchmark
Usertime muliplied by the Whetstone Benchmark. This number can be used (approximately) to compare the performance of different models independently of the architecture on which the test was run.

Measured in Millions of Whetstone Instructions (MWI)
Grade P
Category mandatory
Name vc-thread-safe
Description This verification check examines whether a model called in parallel by multiple threads gives the same results as when called sequentially. A number `num_configs` (preset in the code) of configurations is generated, each containing a different number of atoms based on a randomly distorted, periodic, face-centered cubic (fcc) structure containing a random distribution of all atoms supported by the model. Configurations used for testing are provided as auxiliary files. The energy and forces for each configuration are computed in sequence. Then the calculations are repeated using Python multithreading with `num_configs` threads and the Global Interpreter Lock (GIL) released to ensure true parallelism. Each thread possesses its own copy of memory related to the calculation. The threaded calculations are repeated `num_cycles` times (preset in the code) with the configurations randomly distributed to the threads to create many varying opportunities for collisions. To pass the test, the total energy and the forces on all atoms for a given configuration obtained in all cycles must be be identical to those obtained in the sequential calculation. Failure of this verification check implies that the model is inappropriately storing information in persistent (static) memory during or between calls. Passing this verification check provides some assurance the the model is thread-safe, but it is NOT a guarantee due to the inherent randomness of race conditions in unsafe code. To be certain, the model code would need to be studied and analyzed carefully.