Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Change RNG seed generation scheme. #1174

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

ye-luo
Copy link
Contributor

@ye-luo ye-luo commented Nov 27, 2018

step 1, get initial seed by time std::chrono
step 2, generate seeds for RNGs used by MC. Each rank needs omp_get_max_threads()+1 seeds. jump ahead rank()*(omp_get_max_threads()+1) with discard(). Very fast 0.14 sec for 10^8.
step 3, seed the per-rank RNG.
step 4, seed the per-thread RNG.

After dive in the code a bit, I feel a lot of cleaning is needed.
Mostly RandomGenerator_t needs to be simplified. All the information about MPI and threads should be removed.

@ghost ghost assigned ye-luo Nov 27, 2018
@ghost ghost added the in progress label Nov 27, 2018
@prckent
Copy link
Contributor

prckent commented Nov 27, 2018

  1. Agree that lots of cleaning is needed.
  2. I would prefer that we don't touch this shortly before a release and only touch it once. There are many infamous incidents of initialization being done incorrectly.
  3. We should move to a scheme that guarantees independent random numbers i.e. different seeds per thread. There is a formally correct way to do this that I outlined earlier today.

@prckent
Copy link
Contributor

prckent commented Nov 27, 2018

See #1176

@ye-luo ye-luo changed the title Change RNG seed generation scheme. [WIP] Change RNG seed generation scheme. Nov 27, 2018
@jtkrogel
Copy link
Contributor

What is the typical resolution of "high_resolution_clock" in std::chrono?

Would really like the probability of repeated clock based seeds to be near zero (e.g. no repeats as in #1068, but guaranteed for an even larger set of runs).

@PDoakORNL
Copy link
Contributor

why not use a hardware random source? I think openssl offers easy access to hardware random bytes on any platform we use? Take the seed from there, you can still record it but you shouldn't have to worry about collisions.

@prckent
Copy link
Contributor

prckent commented Jun 3, 2020

I have some better ideas on how to handle this now. A good topic for v4 but we need the batched code first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants