KIM ID VC_881176209980_000-and-MO_173787283511_001-vr
KIM ID (with timestamp) VC_881176209980_000-and-MO_173787283511_001-1517468822-vr
KIM Item Type Verification Result
Verification Check ThreadSafety__VC_881176209980_000
Model Pair_Morse_Shifted_GirifalcoWeizer_MedCutoff_Cu__MO_173787283511_001
Whetstone Benchmark

Measured in Millions of Whetstone Instructions Per Second (MWIPS)
CPU Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz
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 in using Python multithreading with `num_configs` threads, and with 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.