LIGGGHTS particle insertion: Why is seed prime number?

Hi Walter,

from a technical point of view you are correct. The reason why we implement this restriction is that the PRNG showed some undesirable patterns if low numbers were used in large industrial cases. With the current restriction we can ensure that this no longer happens.

Best,
Arno

Hi Arno,
I would like to know why there is no automatic prime number generator in liggghts. All old input skripts are broken and one needs to insert primes which needs to be different everywhere a seed is used.
For my usage I created a primes.inc with 100 equal style variables with spreadsheed and include this into my main script. After that one can use ${prime1} to ${prime100} inside the script.
I'm aware that different primes gives different input psd -which in some cases is usefull, but most of the times not. Maybe one can add something like "...seed AUTO.." in one of the next releases.
Thx,
Christian.

If that was the case, then you probably were just lucky to fix (or probably just hide) your special problem by using a large prime number, as mathematically there is no reason for the seed to be prime. If the quality of the PRNG would depend on the seed the algorithm is more or less useless. So what should be done is a) check if the implementation of the PRNG is correct, b) if used for parallel execution check if the algorithm allows for it c) if (!a) fix it; if (a && !b) implement a different PRNG;
For example, the Park Miller PRNG (initialized in LIGGGHTS with seed+proc number) may introduce cross-correlations in parallel runs, also it still uses 16807 as a multiplier while Park et al. recommended to use 48271 instead ...
(Park&Miller, Marsaglia, Mascagni et al., ...)

Thanks for your valuable input guys. We had thoughts along the same paths but did not really follow up on them yet. I will make an issue in our internal tracker and we'll make something fancy for the next release. Tbh I'm also not really happy with the state of current affairs.

Hi! I'm just getting started using LIGGGHTS, and the requirement of explicit, distinct, prime seeds rankled a little. While I don't claim to be an expert in PRNGs, they have been a hobby-horse of mine for some time. About 15 years ago, I built the PRNG framework for numpy, Python's array-processing package. The pressing need then was to move away from a PRNG with a small 32-bit state and worrying statistical properties to something more state of the art, which was Mersenne Twister at the time. Just recently, we went through the process of adding in more recent-state-of-the-art PRNG algorithms that are smaller, faster, and more suitable for parallel work.

https://docs.scipy.org/doc/numpy/reference/random/index.html

For example, I suspect that SFC64 or its smaller cousin SFC32 would be suitable. The main issue would be that the state is no longer a single 32-bit integer, so the pattern of recording the PRNG state with RanPark::state() would have to be adjusted a little. But that's nothing that a good typedef can't fix. If nothing else, I think it behooves HPC software to use a PRNG with more than 32-bits of state.

Thanks! Please get in touch if you think I can be of service.