(draft) Random Quantities functionality#399
Draft
jplauzie wants to merge 1 commit into
Draft
Conversation
Qrand functionality
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part 3 (and last part) of #393.
This is a function that allows a user to build a Quantity of random noise. The idea is a user could add some random noise/variation to a parameter like a K anisotropy value or something. This was meant to go with the other math functions, but ended up a bit more complex due to needing curand, but I tried to follow the templating of the temperature function. This allows the user to make a Quantity of random values using either a normal distribution with user chosen mean and std dev, or a uniform (I added a generator for uniform noise, copying the existing normal generator) distribution from (0,1). There is also a flag that allows the user to keep this distribution static after it's been initially generated, or to change every time step.
I tried to account for pitfalls like in temperature, but this one probably needs a bit of extra scrutiny. They do have the undo on bad time step functionality like temperature does (but currently, no rescaling based on dt. I don't think that's needed since they're not explicitly based on dt like temp is?),to preserve FSAL for the solvers. But the temperature paper has some warnings about stochastic terms, so there might be other pitfalls I wasn't aware of.
If this gets kept, this still needs a test file. I couldn't really think of anything appropriate and meaningful, to verify it during development I ended up editing the solver itself.
Edit: if you happen to use VSCode, i did have to force it to manually regenerate the CGo flags otherwise it complained about the new generator. Seems to a VSCode/Gopls specific thing