Randomness and Seed Value

[tamirlance]

Is there any documentation about how the SolTrace implements the monte carlo randomness for ray distribution? I was under the impression that if you used the same seed you would get the same ray distribution.

Specifically the problem I am having is that for a single flat surface element in a singe stage I get different ray distributions depending on the optical properties of the that element. Depending on if the transmission is 0 or 1 I get different distributions. I would expect that all else being equal - a single element should get the same distribution regardless of the transmission value (assuming reflectivity is 0 for both). I can see how it would change if you add and remove elements from a stage or otherwise change the geometry of the stage but not for a stage with a single element and nothing else.

I've attached two stinput files which I expect to give the same distribution when using the same seed value.

Seed.zip

[mjwagner2]

Your point about documentation is a good one. This should be better documented. I'm adding a new label for this and will leave this issue open for improvement in this area.

To answer the question, the random number generator (RNG) seed value does ensure reproducibility, but only if the sequence in which the RNG is called is exactly the same between cases. In the situation you described, the RNG is called in the opaque and perfectly absorptive element twice for each ray intersection, as every ray is emitted and then absorbed without fail. The second case with transmission requires at least four calls to the RNG per ray.. once for the sun emission, once for the hit on the surface, once for the angle of transmission through the element, and once for the angle of departure from the element. Because of this, the results won't look exactly the same.

You can check that the RNG is reproducible in each case by selecting the "Virtual stage" option on the geometry page for both cases. If you do that, you should see that both give exactly the same ray data.

[tamirlance]

Thanks for providing all the support on this and other questions. I can see now why the order may be different but i'm unclear as to why the intersection values would change. I would think that the angle of transmission and angle of departure shouldn't impact where on the element the ray intersects it. I tried a case where the absoprtion wasn't zero but a very small number so that all the calls would still happen but I still got different distributions. Is that because only the rays that pass through are impacted?

[mjwagner2]

Right, the issue is that the random number generator will create a fixed sequence. Using Python code as an example:

import random

#Opaque surface
random.seed(5)
print( [random.randint(a=0,b=50) for _ in range(10)] )
>> [39, 16, 47, 22, 50, 44, 47, 41, 33, 1]

#Transparent surface
random.seed(5)
print( [random.randint(a=0,b=50) for _ in range(10)] )
>> [39, 16, 47, 22, 50, 44, 47, 41, 33, 1]

If we ran a ray trace with this in both cases, the first ray in the opaque case would use [39,16], the second would use [47,22], etc... The transparent case would use [39,16,47,22], then [50, 44, 47, 41], etc. Consequently, the second ray will not have the same location in both cases because the random number generator is further along in the same sequence in the second case than the first.

[tamirlance]

That makes total sense now. So there may be a few ways to deal with this:

1. Always make the same number of calls to the RNG even if some of them are not used in the case of absorption.

2. Why doesn't giving the optics some very low transmission value work? Wouldn't then all rays make 4 calls to the RNG? I suspect it's because of the way that Soltrace handles transmission. I think that if you set it to 50%, for example, then 50% of the rays will be absorbed and 50% will be transmitted and only the later half make the additional calls. An alternative would be to treat transmission as a decrease in ray power and have all rays pass through the element. That would require keeping track of power per ray though and may make deeper structural changes to Soltrace. The advantage would mean that you maintain the ray resolution throughout your entire simulation as rays aren't being culled by previous steps (aside from ones that don't intersect anything, etc). The consequence would probably be longer runtimes. But that's always the case when trading off number of rays for runtime and would in a way lead to more accurate results.

3. Could I insert a first stage that encompasses my entire scene so that the initial position of the rays is determined in that stage and then carried through all other stages? Once you are in the second stage you shouldn't need to make 4 calls tot he RNG right? Since position and direction is determined by the first stage?

BTW - the reason we are doing this is because we are trying to get detail intersection data on a large array of PV modules with obstacles that are causing shade. The required number of rays to do that is too large as the natural variation of the RNG is leading to a big distribution of ray intersections across the module even when no obstacle is present. Our method for trying to deal with that was to runt he scene with the obstacle totally transparent and then totally opaque so that we could normalize the distribution and use fewer rays. But that only works if we get consistent ray distribution behavior. It gets even more complicated because there is also self-shade - so we try to normalize for that as well. Looking for way to do this within the existing Soltrace capabilities or else add those features eventually down the road.

Thanks,
Tamir

[tamirlance]

I can confirm that option 3 works. Depending on the implementation it may reduce the effective ray intersections on the second stage. If you just do a big bounding box then many of the rays that enter the first stage will hit empty space on the second stage. I took the approach of creating ghost surfaces that were 1mm away from the real surfaces which effectively preserves the resolution. I also made the first stage virtual without multiple hits per ray. So works for now but the first approach would be cleaner.

Also - the second approach should also work but is more invasive to the underlying code I would imagine.