add angle conditioning

• extend Geometry interface with localDirection(G4FastTrack const& aFastTrack) - to compute the local direction in a right handed coordinate system where the z-axis points into the calorimeter, normal to the calorimeter planes
• add localDir to ModelInterface::prepareInput(...) and ModelInterface::convertOutput(...) to allow for angular conditioning on one or two angles
• implement this in RegularGridBIBAEModel
  • using condition angle as local theta (polar angle) and rotate output of inference model by local azimuth angle phi
• use angular conditioning in Par04VAE
• add property CorrectForAngle to geometry models PolyhedraBarrelGeometry and EndcapGeometry
  • use true for GAN and Par04VAE, false for BIB-AE

changed the description

It actually does change internal state on the first call - via PolehedraBarrelGeometry::phiSector(). Would have to move the call initialize() to the FastShowerModel ...

Neither the phiSector nor the localDirection should depend on anything that is set up in initialize, right?

Additionally, can we put the things that are in initialize into the constructor? That would entirely remove any mutable state from the geometry.

Good point, indeed we can compute the phiSector and localDirection w/o the initialize, as this is only needed for the actual layer positions. Not sure if we can call the initialize in the c'tor as the geometry construction might have not yet been done. Could give it a try, however, as this would clearly simplify things...

changed this line in version 4 of the diff

I am not yet entirely sure if I like the design of singling out the local direction in a separate API and changing other APIs to consume the result of that. Technically we could probably hide that and keep the APIs slightly more general. However, I do see the advantage of not having to compute this over and over again.

I would suggest to keep the interfaces as proposed and revisit later, once we have a more complete picture.

Yep, not super elegant. Did not come up with a better way and preserve the separation of concerns between model and geometry though. Yes, let's keep it for now and see how things evolve w/ other models ...

PS: with the models currently implemented, it looks like the actual parameters needed in the call are (energy, localDirection) only. After all that is what we train our models on. Global position and momentum direction or anything else from G4FastTrack might not be needed. Let's see...

added 2 commits

• 5b476a52 - condition on angle in Par04ExampleVAE
• 44c87dec - add property CorrectForAngles to geometry models

Compare with previous version

changed the description

added 1 commit

• 2bd1548d - initialize the geometry models in the c'tor

Compare with previous version

added 1 commit

• 3b9a9107 - make geometry methods const where applicable

Compare with previous version

approved this merge request

merged

mentioned in commit 8d528355