Update mpv to include the pdune beams

[nvpm-lab]

Adds a configurable beam mode to the MultiPartVertex generator where particles are placed on the surface of an upstream hemisphere rather than uniformly within the TPC volume specifically designed for PDVD, PDSP, and PDHD.
What changed
BeamMode: when true, start positions are sampled uniformly on a hemisphere of radius BeamRadius centred on BeamEntrance, with the flat face flush with the detector entrance plane
BeamInwardDirection: unit vector pointing into the detector, defines hemisphere orientation (default [0,0,1] for PDVD)
BeamTargetRadius: particles are aimed at a random point within a disk of this radius around BeamEntrance, simulating a finite beam spot. Set to 0 to aim at the exact entrance point

New fcl parameters

BeamMode:            true
BeamEntrance:        [94.8, 142.6, 0.7]  
BeamRadius:          15.0                
BeamTargetRadius:    0.0                
BeamInwardDirection: [0.0, 0.0, 1.0]  

Adding beam mode generator display (BeamMode: true) and standard isotropic display (BeamMode: false) for comparison --> 20 events

[FNALbuild]

A new Pull Request was created by @nvpm-lab for develop.

It involves the following packages:

larsim

@LArSoft/level-2-managers, @LArSoft/level-1-managers can you please review it and eventually sign? Thanks.

cms-bot commands are listed here

[FNALbuild]

The code-checks are being triggered in jenkins.

[FNALbuild]

-code-checks
Pull request failed code-formatting checks. Please ensure that cetmodules has been setup and execute the following command from the top-level directory of your repository:

format-code \
  larsim/EventGenerator/MultiPart/MultiPartVertex_module.cc

Then commit the changes and push them to your PR branch.

[FNALbuild]

Pull request #168 was updated. @LArSoft/level-1-managers, @LArSoft/level-2-managers can you please check and sign again.

[FNALbuild]

The code-checks are being triggered in jenkins.

[FNALbuild]

+code-checks

[lgarren]

trigger build

[FNALbuild]

The tests are being triggered in jenkins.

[FNALbuild]

+LArSoft tests OK on slf7 for c14:prof
for details see
https://lar-ci-history.fnal.gov/LarCI/app/ns:LArSoft/view_builds/index?offset=0&builds=lar_ci/29955&builds=
for details of the parent CI build see
https://lar-ci-history.fnal.gov/LarCI/app/view_builds/index?offset=0&builds=&builds=

[FNALbuild]

-ICARUS tests failed on slf7 for e26:prof
for details see
https://lar-ci-history.fnal.gov/LarCI/app/ns:ICARUS/view_builds/index?offset=0&builds=icarus_ci/14519&builds=
for details of the parent CI build see
https://lar-ci-history.fnal.gov/LarCI/app/view_builds/index?offset=0&builds=lar_ci/29954&builds=

[FNALbuild]

-DUNE tests failed on slf7 for e26:prof
for details see
https://lar-ci-history.fnal.gov/LarCI/app/ns:DUNE/view_builds/index?offset=0&builds=dune_ci/21351&builds=
for details of the parent CI build see
https://lar-ci-history.fnal.gov/LarCI/app/view_builds/index?offset=0&builds=lar_ci/29954&builds=

[FNALbuild]

-SBND tests failed on slf7 for e26:prof
for details see
https://lar-ci-history.fnal.gov/LarCI/app/ns:SBND/view_builds/index?offset=0&builds=sbnd_ci/20683&builds=
for details of the parent CI build see
https://lar-ci-history.fnal.gov/LarCI/app/view_builds/index?offset=0&builds=lar_ci/29954&builds=

[FNALbuild]

-uBooNE tests warning on slf7 for e26:prof
for details see
https://lar-ci-history.fnal.gov/LarCI/app/ns:uBooNE/view_builds/index?offset=0&builds=uboone_ci/13808&builds=
for details of the parent CI build see
https://lar-ci-history.fnal.gov/LarCI/app/view_builds/index?offset=0&builds=lar_ci/29954&builds=

[tomjunk]

BeamInwardDirection: unit vector pointing into the detector, defines hemisphere orientation (default [0,0,1] for PDVD)

Isn't PDVD angled at 45 degrees wrt the beam? And is there any dip angle to the beam in NP02? There's about a 10 degree dip in NP04 of the beam with respect to vertical. A totally horizontal beam in NP02 would be more difficult to reconstruct than it has to be.

[tomjunk]

BeamMode: when true, start positions are sampled uniformly on a hemisphere of radius BeamRadius centred on BeamEntrance, with the flat face flush with the detector entrance plane
BeamInwardDirection: unit vector pointing into the detector, defines hemisphere orientation (default [0,0,1] for PDVD)
BeamTargetRadius: particles are aimed at a random point within a disk of this radius around BeamEntrance, simulating a finite beam spot. Set to 0 to aim at the exact entrance point

And I'm not sure I understand what the physics process is here. Seems like this is a recipe for generating particles with a broad range of directions. If I look at the old code, it seems isotropic, which doesn't sound plausible for any distribution of particles made when a beam hits material (I would expect more forward-going ones). This modification looks more forward-going, but where is the justification for the angular distribution? Is it meant to match some data?

[nvpm-lab]

BeamMode: when true, start positions are sampled uniformly on a hemisphere of radius BeamRadius centred on BeamEntrance, with the flat face flush with the detector entrance plane
BeamInwardDirection: unit vector pointing into the detector, defines hemisphere orientation (default [0,0,1] for PDVD)
BeamTargetRadius: particles are aimed at a random point within a disk of this radius around BeamEntrance, simulating a finite beam spot. Set to 0 to aim at the exact entrance point

And I'm not sure I understand what the physics process is here. Seems like this is a recipe for generating particles with a broad range of directions. If I look at the old code, it seems isotropic, which doesn't sound plausible for any distribution of particles made when a beam hits material (I would expect more forward-going ones). This modification looks more forward-going, but where is the justification for the angular distribution? Is it meant to match some data?

The isotropic angular distribution was agreed upon after discussion with the SPINE group. While one could model the exact beam angular distribution, the suggestion was to keep an isotropic distribution for both PDVD and PDHD for now, around the beam entrance. The key improvement here is not the angular distribution but the start position; rather than generating vertices at arbitrary points inside the detector volume, particles are constrained to originate near the beam entrance region. This gives SPINE a more physical training set where beam activity is localised to where the beam actually enters the detector, without committing to a specific angular model.

[tomjunk]

It might be good to add a comment or even a message printed out in the constructor to tell users that this generator is to be used only for training AI/ML tools due to its flat(ish) phase-space coverage.

[nvpm-lab]

Ok I will add that.

[nvpm-lab]

************************************************************ MultiPartVertex: INTENDED FOR AI/ML TRAINING USE ONLY This generator samples phase space with broad, approximately uniform distributions (flat in KE/momentum, isotropic in angle, uniform in vertex position) to maximise detector- response coverage for training and validating reconstruction models. It does NOT apply physical cross-section or flux weighting and is NOT suitable for physics analyses requiring a realistic kinematic or rate prior. ************************************************************
Now the generator print this while running

[tomjunk]

Did you make your error messages more descriptive regarding what threw the error? It is awkward for people debugging to grep through the entire code base for a message they do not know the origin of. Especially when messages are constructed from constant strings. This can be made as simple as updating the abort() method to say what module the error is coming from.

[FNALbuild]

Pull request #168 was updated. @LArSoft/level-1-managers, @LArSoft/level-2-managers can you please check and sign again.

[FNALbuild]

The code-checks are being triggered in jenkins.

[FNALbuild]

-code-checks
Pull request failed code-formatting checks. Please ensure that cetmodules has been setup and execute the following command from the top-level directory of your repository:

format-code \
  larsim/EventGenerator/MultiPart/MultiPartVertex_module.cc

Then commit the changes and push them to your PR branch.

[Nivedpm6]

Did you make your error messages more descriptive regarding what threw the error? It is awkward for people debugging to grep through the entire code base for a message they do not know the origin of. Especially when messages are constructed from constant strings. This can be made as simple as updating the abort() method to say what module the error is coming from.

I don't understand.., that was not an error . That is the description you told me to add so that people will know that this is an ML training specific generator..