GitLab

Jose Borreguero authored Dec 22, 2020 and Peterson, Peter committed Feb 12, 2021

Signed-off-by: Jose Borreguero <borreguero@gmail.com>

In certain cases Gstar/ra/ra was giving numbers below
1e-15 which in turn lead to minor differences in the
acos value across compilers. The computed B matrix would
have entries such as ~1e-17 that really should be treated
as effectively 0. The outside of effect of those entries
seemed most noticable in the Crystal Field pointcharge
calculations where after apply the B matrix + its inverse
would give slightly different ligand entries on clang vs gcc.
Here anything below 1e-15 is now considered 0 and pi/2 is
returned.

Include what you use. string otherwise forward declared.

Move the calculateAttenuation method from MCInteractionVolume onto the
Track class so it's available for situations where you're not doing a
Monte Carlo simulation eg non-simulated absorption weighted path length
New X-ray absorption correction algorithm may also benefit from this

Also return tracks from MCInteractionVolume::calculateBeforeAfterTrack in
different way so it's easier to mock the Track class in the MCAbsorptionStrategy
unit tests
Also had to use testing::invoke to return the mocked track class because
SetArgPointee didn't seem to work in a polymorphic way

The PaalmanPingsMonteCarloAbsorptionTest.FlatPlateTest was failing
intermittently on Windows. The cause of this was two things:

a) there was a problem in the duplicates check when adding points into a
track in Track::addPoint which meant that sometimes a point wasn't added
even though no duplicate existed already. I think this problem has
perhaps come about because the track uses a boost smallvector which
seems to have some slots pre-initialised
b) there is a vector of V3D points that is populated in
CSGObject::interceptSurface. The sort order of this wasn't well defined
meaning that a) produced different results on subsequent runs of the
same system test. The sort order is driven by the order of some pointers
to Surfaces in the CSGObject::m_surList member
I have fixed the bug in a) and have removed the sort on CSGObject::m_surList

The fix has changed the system test reference file slightly

So Windows stops generating a warning about a possible loss of data that
could not possibly happen.

Whitfield, Ross authored Oct 06, 2020 and Peterson, Peter committed Oct 14, 2020

This will now give the correct values for object that have multiple intercepting surfaces, e.g. hollow cylinder

First, modifies the validity range check so it is inclusive and
if there is no provided starting validity date, a value is picked
nonetheless.

Second, makes it so the mutable run correctly gets the parameters in
LoadILLReflectometry.

This will now give the correct values for object that have multiple intercepting surfaces, e.g. hollow cylinder