G4PhysicsFreeVector Reversed Order vs G4PhysicsOrderedFreeVector


I’ve recently updating the version of G4 I’m using (in conjunction with the Opticks framework) from 10.7 to 11 and I’m having a peculiar issue.

After upgrading I noticed that the optical photons that were being created (Cerenkov radiation) had stopped propagating.

Upon some investigation I found that they were now being absorbed (inline void G4OpBoundaryProcess::DoAbsorption()) and thus killed. This absorption was being triggered by a change in the reflectivity (G4VParticleChange* G4OpBoundaryProcess::PostStepDoIt(const G4Track& aTrack, const G4Step& aStep)) the change in the reflectivity was drastic (a drop from 0.88 to 0.14) which explains the absorpion.

Further tracking of the issue led to the reason why the reflectivity so drastically reduced. Where the reflectivity is retrieved (G4double G4PhysicsVector::Value(G4double theEnergy, std::size_t& lastIdx)) the set maximum and minimum of the binVector (photonmomentum in this case) which are edgeMax and edgeMin respectively have been reversed, thus edgeMax<edgeMin, thus all checks fall into the lowest bin returning the lowest reflectivity.

I’ve found that edgeMin and edgeMax are set when the G4PhysicsFreeVector is created (G4PhysicsFreeVector::G4PhysicsFreeVector(const std::vector& energies,const std::vector& values,G4bool spline)). From this I learned that the reason that edgeMin and edgeMax are wrong is that it is assumed the vector from which they are set is ordered in increasing value.

All the vectors in question seem to be of type G4MaterialPropertyVector which itself is of type G4PhysicsFreeVector in G4 11 (G4PhysicsOrderedFreeVector in G4 10.7). I’ve done some testing and although data is read into these vectors in identical order regardless of G4 version, when read back out (using GetProperty()) in G4 11 they come out in reverse order which ultimately causes all other issues.

Now, I’m relatively new to G4 so maybe Im doing something dumb, I know that G4PhysicsOrderFreeVector was removed in G4 11 and replace with G4PhysicsFreeVector but I cant see why this change alone would alter the order of the elements in the vectors. Furthermore if this was an actual bug (rather than something dumb Im missing) I would expect it to have broken a lot more than just my code.

So has anyone had a similar issue? or does anyone know exactly the dumb mistake I’ve made? I’m guessing a simple one line correction but so far i’ve not found it




Your analysis is correct. G4PhysicsVector assumes that the energy values are in increasing order. We will add a check in G4MaterialPropertyVector to enforce this.

But surely that wouldn’t have inverted the order of vectors between version of G4? I have confirmed this, the min and max are correctly determined in G4 10.7 but not G4 11


according to Geant4 rules it is possible to change interfaces for a new major release, so when we switch from 10.X to 11.0 interfaces may be changed.

Concerning to use of G4PhysicsFreeVector: we cannot perform proper interpolation if energy points are in chaotic order. To prevent this, it is need during initialization to use following method of free vector:

vector-> InsertValues(const G4double energy, const G4double val);

In this case, edgeMin, edgeMax should be correct.

Alternative method PutValues(…) assumes increased energy in each next point.