Closed whaeck closed 3 years ago
kahlerac
commented
3 years ago Well, since you bring it up ... Yes I think advancing the random number generator is a good idea. For example, if someone wants to see the impact of changing from N to N+1 ladders the first N ladders have to remain the same.
whaeck
commented
3 years ago @kahlerac That's also a good idea. We'll probably have to start by allocating a number of random numbers for each energy (e.g. 1000 or 10000 per energy), and each ladder in there. If we set that range high enough, we should be generating the same results for each energy, regardless of changes in number of ladders in previous energies. I prefer not to do this in this pull request though. I'll make a note of it for later.
jchsublet
commented
3 years ago @whaeck @kahlerac I am somehow lost in the mist of it all, could you please point me to the place, a place where I can access your mouture/interpretation of Bob's latest work on Purr? is there a branch for it? on the 2016 code
This resolves issue #178
Whenever nunx is set to anything else but 0 or nunr, purr will now properly calculate the probability tables for the given number of tables spread out over the entire unresolved resonance region, selected from the existing unresolved energy points. The existing MT152 (produced by reconr or unresr - whichever was run last) will be erased and replaced by the corresponding data for the selected unresolved energies. MT153 only contains the generated probability tables.
Test 63 was added to verify this. This test is equivalent to test 35 but with nunx set to 2. Between test 35 and test 63, the first table is numerically the same. The second table in test 63, which corresponds to to the last table in test 35 are not numerically the same - most like due to the random number generator. When test 35 calculates the last ptable, it has already generated 19 tables while test 63 has only generated 1 - thus resulting in a different random number sequence and a difference in the table.
If we wish to ensure that the same table is generated in both cases, we'll have to advance the random number generator by as many numbers as would have been used if all tables were calculated. Any thoughts on this?
As a side note: this PR merges into the develop branch as a staging area before merging into master - to avoid having to introduce a version number while we work through different fixes separately.