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

Improve Random Number Generation in ScopeSim #298

Open
hugobuddel opened this issue Nov 10, 2023 · 1 comment
Open

Improve Random Number Generation in ScopeSim #298

hugobuddel opened this issue Nov 10, 2023 · 1 comment
Labels
enhancement New feature or request refactor Implementation improvement

Comments

@hugobuddel
Copy link
Collaborator

The Random Number Generation (RNG) is a bit messy in ScopeSim. See for example #295 and #97.

The idea behind this issue is to collect what we need from the RNG.

I'll go first.

  • The default should perhaps be to seed the RNG with something supposedly unique, like the MJDOBS of the simulated observation. This can be done once we can simulate full templates / observing blocks.
  • If that's not possible, the default should be a 'random random number seed' I believe, unlike the current fixed seed.
  • Whatever seed is used, it should be stored in the headers of the FITS file, so it is possible to uniquely recreate the exact same simulation (which also requires other keywords, e.g. for versioning).
  • The RNG should be setup such that each effect 'splits of' its own generator from the main one, instead of reusing the seed. This should be easy to do in Python/numpy/scipy.
  • Perhaps it should be possible to seed only specific effects, and not others. For example the generation of hot/cold pixels should perhaps be the same over many simulations, but the noise should not.
@teutoburg
Copy link
Contributor

teutoburg commented Nov 10, 2023

I'll go next:

I recently noticed that numpy recommends using np.random.Generator for new development. AFAIK, we're using the legacy random functions most everywhere. While I didn't consider it a priority at the time I found out about this, I think if (when) we're already touching the random stuff, it might be worth migrating to the new style, which numpy claim has performance benefits, as well as quality of the "randomness" and handling. Maybe some of the changes we want to implement anyway will become easier to manage with this.

@teutoburg teutoburg added enhancement New feature or request refactor Implementation improvement labels Nov 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request refactor Implementation improvement
Projects
Status: 📋 Backlog
Development

No branches or pull requests

2 participants