/ Generator Public

Closed
opened this issue Jan 7, 2020 · 3 comments
Closed

opened this issue Jan 7, 2020 · 3 comments
Assignees

### tlatorre-uchicago commented Jan 7, 2020

A small issue I came across when using the gevgen_atmo script is that by default it sets the radii for the flux generation surfaces to be be 1 here:

Line 478 in 9bc50de

. However if the actual geometry is much bigger than 1 then this will incorrectly sample the interaction vertices.

### candreop commented Jan 7, 2020

 gevgen_atmo will need a small addition, providing command line options to specify the radii - thanks for bringing this up. Will be fixed asap

self-assigned this Jan 7, 2020

### tlatorre-uchicago commented Jan 14, 2020

 I might be able to work on this if you could provide me with a small amount of help. Do you know if it's possible to directly get the overall bounding box for the specified geometry? If so, do you think it would be reasonable to use a sphere big enough to encompass the bounding box of the geometry? The other question I had was why there are two radii. I looked into the GAtmoFlux class for a bit but couldn't determine what it is. Is the flux generation surface an ellipsoid?

added a commit that referenced this issue Jan 15, 2020
 Address issue #83 by tlatorre-uchicago: Add command line arguments to… 
 4593a2f 
… allow users to set the distance and radius of the flux ray generation surface

### candreop commented Jan 15, 2020

 Sorry, was away at a workshop. Added 2 new command line arguments in gevgen_atmo (in the master). They are: --flux-ray-generation-surface-distance and --flux-ray-generation-surface-radius. They allow you to set the parameters of the flux ray generation surface. No the surface is not an ellipsoid. For a given zenith \theta and azimuthal angle \phi, flux rays are produced within the area of a circle of radius Rt, which is tangetial to a point P on a sphere of radius Rl, centred at the detector. The point P has polar coordinates \theta and \phi. You specify Rt and Rl. Th eatteched plot might help understanding the setup If you have some coding skills and want to contribute, I would like to invite you to help us with improving the efficiency of gevgen_atmo. It uses a full-blown geometry navigation driver (that we use for more complex simulation cases with accelerator based neutrinos close to the source) but this is an overkill for atmospheric neutrinos since all parts of the detector see the same beam. Some simplifications could make gengen_atmo run much faster.