Add random compositional fields

[alarshi]

This PR addresses part of issue #531 to get random compositional values. Here is the output of this plugin with a continental plate:

This is the result for user specified bounds in the first compositional field: [5, 10]

This is the result from using the default random model.

[github-actions]

Benchmark	Main	Feature	Difference (99.9% CI)
Slab interpolation simple none	1.013 ± 0.004 (s=437)	1.019 ± 0.004 (s=451)	+0.5% .. +0.7%
Slab interpolation curved simple none	1.018 ± 0.004 (s=426)	1.025 ± 0.004 (s=458)	+0.6% .. +0.8%
Spherical slab interpolation simple none	1.173 ± 0.007 (s=369)	1.177 ± 0.007 (s=400)	+0.2% .. +0.5%
Slab interpolation simple curved CMS	1.062 ± 0.004 (s=443)	1.060 ± 0.004 (s=408)	-0.3% .. -0.1%
Spherical slab interpolation simple CMS	1.549 ± 0.010 (s=280)	1.554 ± 0.009 (s=303)	+0.2% .. +0.5%
Spherical fault interpolation simple none	1.179 ± 0.007 (s=402)	1.185 ± 0.007 (s=362)	+0.3% .. +0.6%
Cartesian min max surface	2.297 ± 0.020 (s=204)	2.323 ± 0.020 (s=188)	+0.9% .. +1.4%
Spherical min max surface	7.273 ± 0.058 (s=62)	7.300 ± 0.031 (s=64)	-0.0% .. +0.8%

[MFraters]

Looks great, thanks for making this! I have a few small comments, but otherwise I think it is good to go.

[alarshi]

Thank you for the review! I addressed the comments in the latest commit.
I was also wondering if the test case makes sense or not. Since, this is a random distribution, the output would be different every time we run it or do I not understand this correctly?

[MFraters]

I was also wondering if the test case makes sense or not. Since, this is a random distribution, the output would be different every time we run it or do I not understand this correctly?

The random numbers are depended on the seed. As long as the seed is the same, the same sequence of random numbers will be generated. If you update your test results, the tester should pass.

[alarshi]

Got it! Thanks for the explanation.

[MFraters]

hmm, strange. Did you rebase on the newest master when updating the test results?

[alarshi]

I rebased the branch but the tests are still failing. I don't understand why. :(

[alarshi]

I checked that each run is gives me a different result, which would explain why the test is failing.

[tjhei]

The problem is that gwb-grid now uses multiple threads by default. This means that the points will not be evaluated in the same, deterministic order. I am not even sure that the random engine is thread-safe.
Making tests deterministic is not too difficult, by limiting all (or at least this) test to run with -j 1. If you want it to be deterministic for >1 thread, we would need to duplicate each random engine into a thread-local variable. This would make it deterministic as long as you run with the same number of threads but it would still depend on how many threads you run with. I am not sure if this is good enough...

[MFraters]

ah, that make sense. I was confused, because we currently already use random number generation in the code, but this is for the grains, which is only implemented for the for gwb-dat, which doesn't use threads.

[MFraters]

In any case, we should probably fix the number of threads for the tester.

[MFraters]

hmm, getting a thread rank is not as easy as getting a mpi rank. The thread id seems to be an unpredictable number/hash (I think). We do actually have a unique rank number when creating them, but we would need to pass those id's manually somehow.

Looking at it, the easiest solution may be to add a constructor parameter to the world so that you can pass a thread rank. That rank is then use in some way to set the seed of the world. In gwb-grid, we then just create a separate world for each thread, and in the parallel for loop we call the properties function on the appropriate world for each thread. This would make it deterministic again and would require minimal changes I think.

[MFraters]

@alarshi #667 is merged now, so if you rebase you should be able to fix this problem (at least updating the test results on my systems seems to work now). Also, it looks like you will need to include a header (I think the header?) to make the non-unity build work.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.18%. Comparing base (ac9e4a7) to head (ff7534b).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #651      +/-   ##
==========================================
- Coverage   98.23%   98.18%   -0.05%     
==========================================
  Files         106      107       +1     
  Lines        7302     7341      +39     
==========================================
+ Hits         7173     7208      +35     
- Misses        129      133       +4     

Files	Coverage Δ
...res/continental_plate_models/composition/random.cc	100.00% <100.00%> (ø)

... and 2 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ac9e4a7...ff7534b. Read the comment docs.

[MFraters]

I am not sure why it didn't work for you, but it seems to work for me :s