[Falaise/geometry] organize strip in block GeometryModel

[lemiere]

provide the flat source geometry for the second time. To Be verify

[drbenmorgan]

Thanks @lemiere - just to check, this supersedes #197 ? Let me know and I'll close that.

I've added people to help review/validate, but please add anyone else you want/need!

[cherylepatrick]

Thanks! @pfranchini - do you have time to give this a test? What I think we want to check is that the locations and activities of the individual foils match Andrea's document http://nile.hep.utexas.edu/cgi-bin/DocDB/ut-nemo/private/ShowDocument?docid=4457

The way I would do it is to use flsimulate-configure and check you can find the new vertex generator for the realistic foils, and set the geometry to include realistic foils. Then generate (quite a lot of) really simple events (1 MeV gamma?) from that vertex generator. When I did this before, I made a 2-d plot of the y vs z vertex positions to check I could see the shapes of the pads and foils. Then I used the shapes of those (plot y only) to cut on the vertex positions corresponding to each foil. Then I made more detailed plots of the x, y and z positions to verify the (relative) dimensions match Andrea's doc. Final stage would be to count the number of events from each pad and check it's proportional to the stated amount of Se82 in the pad (volume * enrichment fraction).

Does that make sense? Can anybody think of tests I'm missing?

[pfranchini]

Sure @cherylepatrick I can test that.

[cherylepatrick]

Fab, thank you Paolo! Give me a shout if you need anything.

[pfranchini]

@lemiere, running the simulation I get

[notice:virtual void mctools::g4::manager::_init_detector_construction():1491] Detector construction...
flsimulate : Setup/run of simulation threw exception
[void mctools::g4::region_info::initialize(const datatools::properties&, const geomtools::manager*):219: Unknown material 'snemo::se82_enriched96.92_pva0.0790_density1.971' in the material manager!]

using as profile (generated with flsimulate-configure)

#@format=datatools::configuration::variant
#@format.version=1.0
#@organization=snemo
#@application=falaise

[registry="geometry"]
layout = "Basic"
layout/if_basic/magnetic_field = true
layout/if_basic/magnetic_field/is_active/type = "UniformVertical"
layout/if_basic/magnetic_field/is_active/type/if_uniform_vertical/magnitude = 25 gauss
layout/if_basic/magnetic_field/is_active/type/if_uniform_vertical/direction = "+z"
layout/if_basic/source_layout = "RealisticFlat"
layout/if_basic/source_calibration = false
layout/if_basic/shielding = true
calo_film_thickness = 25 um

[registry="vertexes"]
generator = "real_flat_source_full_foils_se82_bulk"

[registry="primary_events"]
generator = "electron.1MeV"

[registry="simulation"]
physics_mode = "Constructors"
physics_mode/if_constructors/em_model = "standard"
production_cuts = true
oureal_flat_source_full_foils_se82_bulk.profile
#@format=datatools::configuration::variant
#@format.version=1.0
#@organization=snemo
#@application=falaise

[registry="geometry"]
layout = "Basic"
layout/if_basic/magnetic_field = true
layout/if_basic/magnetic_field/is_active/type = "UniformVertical"
layout/if_basic/magnetic_field/is_active/type/if_uniform_vertical/magnitude = 25 gauss
layout/if_basic/magnetic_field/is_active/type/if_uniform_vertical/direction = "+z"
layout/if_basic/source_layout = "RealisticFlat"
layout/if_basic/source_calibration = false
layout/if_basic/shielding = true
calo_film_thickness = 25 um

[registry="vertexes"]
generator = "real_flat_source_full_foils_se82_bulk"

[registry="primary_events"]
generator = "electron.1MeV"

[registry="simulation"]
physics_mode = "Constructors"
physics_mode/if_constructors/em_model = "standard"
production_cuts = true
output_profile = "none"
tput_profile = "none"

generating with

settings : string[2] = \
         "primary_events:generator=gamma.1MeV" \
         "vertexes:generator=real_flat_source_full_foils_se82_bulk"

any help is appreciated! thanks

[fmauger]

Hi

The material plugin main config file "resources/snemo/demonstrator/geometry/GeometryPlugins/MaterialsPlugin.conf" should include the definition files for new Se materials associated to the new geometry of the source pads/strips:

• "'@falaise:materials/Elements_RealSource.conf"
• "@falaise:materials/Materials_RealSource.conf"
  Maybe Yves has forgotten to add them in the PR.
  At least this is a hint...
  cheers

[pfranchini]

thanks @fmauger I try adding this

[fmauger]

Yves is checking on his side if there is some missing stuff...
yes, that's it. he's pushing... taadaa !

[lemiere]

Fixed ! Let me know

[pfranchini]

Brilliant, it has generated something. Will check the results. Thanks.

[pfranchini]

I do not see the foils 0 and 35 being simulated (only 34 over 36 are)

I guess there is something different for those 2 lateral foils in source_foils.geom since they miss something like stacked.model_0 : string = "source_film.realistic.model".
Maybe I am not fully understanding the structure so I ask you @lemiere to fix it (if needed). Thanks.

[cherylepatrick]

Are 0 & 35 the copper foils? So they wouldn't be in the vertex generator for Se82... I think? (With the old style - source_foil_internal_bulk vs source_foil_bulk, or something - the rite-of-passage common mistake every new analyser makes :) )

[pfranchini]

@cherylepatrick of course they are! I am very glad copper is not radioactive. Sorry haven't checked the table only the drawing...

[pfranchini]

Please find attached a spreadsheet with the validation Foils_simulation.xlsx. Sorry for the horrible way of presenting the numbers.
I have simulate 10^7 gammas with the generator real_flat_source_full_foils_se82_bulk and studied the true vertexes.

• I see the 34 foils of width ~[134-136] mm
• The distance between the foils is of the order of 1 mm
• I see 6 gaps of 17.4 mm for the calibration sources where they should be
• I have sliced in order to see the single pads (if more than one) in each foil, e.g.
  
• Single foils have height of 2703 mm
• Pads have height of 336 mm
• Simulated activities are compatible within 0.1% with the 82Se fraction of each foil (I haven't checked the activity of each single pad)
• In the spreadsheet you can fin the X and Z coordinate for each pad
• I cannot really tell from Andrea's document which are the composite foils or not (of course those correspond with the Falaise simulation with some funny numbering order)

To summarize, I do not see anything obviously wrong and I will wait @lemiere to check if we are on the same page.

[cherylepatrick]

Great news, thank you @pfranchini ! What's the bit you're missing from Andrea's spreadsheet?

[pfranchini]

What's the bit you're missing from Andrea's spreadsheet?

Actually I should have got this from Yves this morning in chat, all the * ITEP * are single strips if I am not mistaken. Which corresponds to what I get.

[lemiere]

Hi Paolo,

How did you calculate the fraction (line 5 and 6) ? Based on nb of vertexes ?If YES : Can you add uncertainties ?

Is the vertexes bulk distribution OK in pads/strips ?
Can you check also the surface generator ?

It looks OK in YZ view. Did you look after the XZ view ?
On my side, it looks OK. Let's go to compare a channel sensitivity in function of the source foil geometry

[pfranchini]

Thanks Yves.

How did you calculate the fraction (line 5 and 6) ? Based on nb of vertexes ?If YES : Can you add uncertainties ?

Line 6 is, from Andrea's document, the fraction of Se82 in each foil. Line 5 is events_foil_i/generated_events. events_foil_i depends on the binning of the histogram I cut in, so let me think which could be a realistic error for the fraction.

Is the vertexes bulk distribution OK in pads/strips ?

Do you mean real_flat_source_strip_*_pad_*_bulk? I have tried few just to see the position. They are 141 just for the bulk. I can systematically check one by one but might take some more time to setup the machinery to create each MC and count.
Moreover, they are not following an Y order, but the original foil numbering, so for long term usage this might be confusing.

Can you check also the surface generator ?

I'll do.

Did you look after the XZ view ?

On my side, it looks OK. Let's go to compare a channel sensitivity in function of the source foil geometry

I can resume some old background sensitivity analysis done in the past unless someone else has some other code ready and more up-to-date.

[cherylepatrick]

Hi @pfranchini this is fantastic! Do you want to give a quick update in Thursday's analysis meeting to show what you've learned so far? Also, you could try talking to @willquinn for sensitivity code?

[pfranchini]

Sure @cherylepatrick no problem with that.

[cherylepatrick]

Fabulous, I'll pop you on the agenda! Thanks!

[fmauger]

What do you mean by:
"Moreover, they are not following an Y order, but the original foil numbering, so for long term usage this might be confusing." ?

The geom_id should be numbered from 0 to 35 in ascending order (y- -> y+).
The production ID (labelled by Andrea) is NOT the logical positioning in the frame. @ylemiere can you tell us more about that ?

[fmauger]

Ok I've checked that in the following file:
https://github.com/lemiere/Falaise/blob/flat_foil_geometry_version_2021/resources/snemo/demonstrator/geometry
/GeometryModels/source_module/source_blocks.geom

The regular numbering scheme of source strips is broken and replaced by the identifier of the "production" strip number (the model ID). I think this is a wrong approach ( a typical case of confusion between models and instances).
We should restore the original official numbering and labelling scheme from strips 0 to 35:

Example in block #0:

[name="source_strip_block_0.model" type="geomtools::stacked_model"]
...
#@variant_if geometry:layout/if_basic/source_layout/if_realistic_flat|false
stacked.model_0 : string = "snemo_strip_0.model" # Position 0 (Copper)
stacked.model_2 : string = "snemo_strip_31.model" # Position 1 => ok strip model #31 goes in position #1
stacked.model_4 : string = "snemo_strip_4.model" # Position 2 => ok strip model #4 goes in position #2
#@variant_endif
...
stacked.label_0 : string = "strip_0"
stacked.label_1 : string = "strip_gap_0-1"
stacked.label_2 : string = "strip_1" # => Not 31 which is the strip model ID => we need here a simple comprehensive name for human being - we don't care the strip model here
stacked.label_3 : string = "strip_gap_1-2"
stacked.label_4 : string = "strip_2" # => Not 4 which is the strip model ID
mapping.daughter_id.strip_0 : string = "[source_strip_path:strip=0]"
mapping.daughter_id.strip_1 : string = "[source_strip_path:strip=1]" # => Not 31
mapping.daughter_id.strip_2 : string = "[source_strip_path:strip=2]" # => Not 4

and repeat this procedure from blocks #1 to #6:

[lemiere]

About :

They are 141 just for the bulk. I can systematically check one by one but might take some more time to setup the machinery
I propose that you generate 'real_flat_source_full_foils_mass_bulk' then calculate ration per pads/foils and check the bulk distribution uniformity.

View in XY was to start a 3D geometry validation first step. (your pict in mm ? )

@fmauger : About the labeling. Right that's messy... Foils have labels (LAPP_, LAPP_ITEP_11 or ITEP_9) That's the uniq foils label. And 2 years ago, I had to use it.... but I took the foil position as it was more systematic. I kept in mind that source_blocks.geom will have in charge the foils ordering.
So snemo_strip_XX.model is only a name and position is provided by block ID + stacking and XX does not provide foil position...
instead of what it availalble in Andrea's doc. :-(

In Falaise, we have a foil ID accessor which do the job ? without taking care about the model name ?

[fmauger]

yes. we don't care the model name; it could be changed by a more refined strip model without breaking the strip numbering scheme.
"FOIL labels" are only for identifying production batches (internal to the source production group) and thus the strip model identification. This has nothing to do with positioning in the frame (and blocks).

[cherylepatrick]

Hi all, sorry for being slow but I'm trying to understand. So there are some ID numbers to the foils that are in Andrea's document, is that right? And those are the "Model" numbers? But they don't correspond to the position in the detector (position number)?

Also: I vaguely remember there being an issue about the position numberings sometimes being counted from tunnel to mountain end, and sometimes from mountain to tunnel. Is strip position 0 at the mountain end or the tunnel end? (I think mountain is more intuitive as that is where tracker cells column zero and calorimeter blocks column 0 are... yes?)

#@variant_if geometry:layout/if_basic/source_layout/if_realistic_flat|false
stacked.model_0 : string = "snemo_strip_0.model" # Position 0 (Copper)
stacked.model_2 : string = "snemo_strip_31.model" # Position 1 => ok strip model #31 goes in position #1
stacked.model_4 : string = "snemo_strip_4.model" # Position 2 => ok strip model #4 goes in position #2
#@variant_endif

And then here... why is position number 1 called stacked.model_2? Sorry if I'm being slow to follow...

Is it worth including something about this numbering and how to work it in Paolo's talk at the analysis meeting on Thursday? Or is this still a work in progress?

[fmauger]

Hi all, sorry for being slow but I'm trying to understand. So there are some ID numbers to the foils that are in Andrea's document, is that right? And those are the "Model" numbers? But they don't correspond to the position in the detector (position number)?

Also: I vaguely remember there being an issue about the position numberings sometimes being counted from tunnel to mountain end, and sometimes from mountain to tunnel. Is strip position 0 at the mountain end or the tunnel end? (I think mountain is more intuitive as that is where tracker cells column zero and calorimeter blocks column 0 are... yes?)

Yes. from 0 to 35, one maps the Y axis from negative coordinates to positive ones. This is the standard orientation scheme in SN geom.

#@variant_if geometry:layout/if_basic/source_layout/if_realistic_flat|false
stacked.model_0 : string = "snemo_strip_0.model" # Position 0 (Copper)
stacked.model_2 : string = "snemo_strip_31.model" # Position 1 => ok strip model #31 goes in position #1
stacked.model_4 : string = "snemo_strip_4.model" # Position 2 => ok strip model #4 goes in position #2
#@variant_endif

And then here... why is position number 1 called stacked.model_2? Sorry if I'm being slow to follow...

Ha Ha! This is another story. This piece of geometry is built through a "stacked_model" that automatically builds a "stack" (Uhh!) of several objects and automatically computes their relative positioning within a common mother envelope (also automatically computed). The "stacked.model_X" refers to the geometry volume model/logical of the instance/physical volume placed at position X in the stack. This is not related to the strip ID but just a numbering facility for the guy who designed this compound/stacked logical volume. You see here that we are in the first source strip block, where there are 5 physical objects/volumes:
[a copper strip+ a gap + a source strip + a gap + another source strip]
with stack numbers from 0 to 4 . Only the source strips have to be numbered with our strip ID scheme. In block 0, this gives:

stacked.model_0 will be associated to strip #0 (Copper)
stacked.model_2 will be associated to strip #1 (Se)
stacked.model_4 will be associated to strip #2 (Se)

In next block #1, there are 6 source strips and 5 gaps between them (11 physical stacked volumes along the Y-axis), so only stacked objects #0, 2, 4, 6, 8 in this local stack (Se strips) should be mapped as strip IDs (starting at #3 up to #8).
And so on for other blocks...

Is it worth including something about this numbering and how to work it in Paolo's talk at the analysis meeting on Thursday? Or is this still a work in progress?

Not sure. Yves will fix this this afternoon and everything will be fine and comprehensive.

[pfranchini]

What do you mean by:
"Moreover, they are not following an Y order, but the original foil numbering, so for long term usage this might be confusing." ?

Just an example: using the generator real_flat_source_strip_34_se82_bulk which should be somewhere in an extreme of the detector (likely tunnel) I get something here (7th position)

[cherylepatrick]

Thanks for the explanation @fmauger - that makes much more sense to me now!

[lemiere]

Fixed (I hope)
@pfranchini : can you re-run your last test : real_flat_source_strip_34_se82_bulk ?
Thx

[pfranchini]

Thanks @lemiere, this is fine
real_flat_source_strip_34_se82_bulk:

but can you please check real_flat_source_strip_1_se82_bulk which has now only the first pad:

(haven't checked all the other foils)

[pfranchini]

Few problematic vertexes to start with:

[void genvtx::box_model_vg::_init_():337: Cannot compute any source of vertex in vertex generator 'real_flat_source_strip_22_pad_7_bulk' !]
[void genvtx::box_model_vg::_init_():337: Cannot compute any source of vertex in vertex generator 'real_flat_source_strip_21_pad_7_bulk' !]
[void genvtx::box_model_vg::_init_():337: Cannot compute any source of vertex in vertex generator 'real_flat_source_strip_20_pad_7_bulk' !]
[void genvtx::box_model_vg::_init_():337: Cannot compute any source of vertex in vertex generator 'real_flat_source_strip_23_pad_7_bulk' !]
[void genvtx::box_model_vg::_init_():337: Cannot compute any source of vertex in vertex generator 'real_flat_source_strip_25_pad_7_bulk' !]
[void genvtx::box_model_vg::_init_():337: Cannot compute any source of vertex in vertex generator 'real_flat_source_strip_27_pad_7_bulk' !]
[void genvtx::box_model_vg::_init_():337: Cannot compute any source of vertex in vertex generator 'real_flat_source_strip_28_pad_7_bulk' !]
[void genvtx::box_model_vg::_init_():337: Cannot compute any source of vertex in vertex generator 'real_flat_source_strip_24_pad_7_bulk' !]
[void genvtx::box_model_vg::_init_():337: Cannot compute any source of vertex in vertex generator 'real_flat_source_strip_26_pad_7_bulk' !]
[void genvtx::box_model_vg::_init_():337: Cannot compute any source of vertex in vertex generator 'real_flat_source_strip_33_pad_7_bulk' !]
[void genvtx::box_model_vg::_init_():337: Cannot compute any source of vertex in vertex generator 'real_flat_source_strip_31_pad_7_bulk' !]
[void genvtx::box_model_vg::_init_():337: Cannot compute any source of vertex in vertex generator 'real_flat_source_strip_32_pad_7_bulk' !]

[lemiere]

I know what's going wrong.... the VertexGenerator... I will look after it soon.... tomorrow will be tricky...

[cherylepatrick]

Thanks @lemiere, I know this is a bit of a pain and is dragging on. And thanks @pfranchini for finding the issue!

[drbenmorgan]

Would it be possible to add the .csv generation step to the build? If this file is absolutely required to be updated on changes to the .conf file, then this is definitely needed!

The doxygen generation CMake scripting provides an example of this with the add_custom_command+add_custom_target pair that's needed to declare how to run the generator (script in this case) and its outputs (.csv file) and inputs/dependencies (conf files).

It's slightly different in that the .csv file must go into the source directory, but that's fine, just a change in output path.

[fmauger]

For that we need to provide a bash script that calls the Bayeux's script named "bxextract_table_of_objects". The current version of this script in Bayeux 3.4.X should be improved for a best parsing of the vertex definition .conf files.
Basically, from each "[name='xxx' ...] lines, we must extract the "#@config" line with the description, a possible "group=yyy" directive and "variant=zzz" rules (all used to generate tautomaticaly the GUI in flsimulate-configure.
To be continued...

[drbenmorgan]

@fmauger, yep, I guess this script is this change in @lemiere's last commit?:

7b98bea#diff-bcd941f2827541ca2d9ae838b86e9222999c397ceb82b264001fb46068faf6c5

That should be easy enough to wrap in the custom command/target pairing.

Longer term (i.e. not now for this PR!) would Bayeux's variant system/flsimulate-configure (as appropriate) be able to forego the .csv file and read the info directly from the .conf files when run?

[pfranchini]

Thanks @lemiere for fixing that.

• The order is now correct: generators real_flat_source_strip_[1..34]_se82_bulk follow the natural order -Y to +Y (mountain to tunnel). 0 and 35 are the copper strips.
• Activities are very same of what shown before in the spreadsheet Foils_simulation.xlsx. The "Poisson" error is negligible.
• The real_flat_source_strip_[1..34]_surface generators have the correct orders too.
• Views of gammas from real_flat_source_full_foils_se82_surface (front view, side view and top view, respectively)

front view:

side view:

top view:

in the top view we can (correctly) tell which are the single-pad strips and which are composite.

[lemiere]

Pretty cool ! Let's go for a merge !

[pfranchini]

Brilliant @lemiere, fine for me!

[fmauger]

@fmauger, yep, I guess this script is this change in @lemiere's last commit?:

7b98bea#diff-bcd941f2827541ca2d9ae838b86e9222999c397ceb82b264001fb46068faf6c5

That should be easy enough to wrap in the custom command/target pairing.

Longer term (i.e. not now for this PR!) would Bayeux's variant system/flsimulate-configure (as appropriate) be able to forego the .csv file and read the info directly from the .conf files when run?

I understand your point but I have to think more deeply about it for my feeling is that it would break something in the variant concept which is basically a preprocessor on top of standard config files but could also be used as a independant configuration system. The problem here is that we will have to invent some special directives/language/protocol to allow the autogeneration of such csv files from the standard properties and multi_properties files. That would imply a first reading of all available files to pickup the informations needed to elaborate the csv variance list without taking into account some embedded variant directives. But in that case, some of the configuration blocks, systematically loaded, would be absolutely incompatible while using the standard (multi_)properties parser. Think to the CPP preprocessor ! This would be the same if we ask some parser to analyze all onboard #define/#if... directives in many C source files and propose an automated list of options for the CMake option mechanism, for example in the CMakeLists.txt main file of some project. My guess is that is could ba a nightmare to elaborate.
The point is that the variant system (including adequate CSV files) owns the logics and the criteria to load in a consistent way the various configuration files and blocks.
That looks to me some kind of Pandora box, but maybe I'm wrong.
In any case, it is a 2-pass parsing protocol with possible dependency loops/conflicting patterns. I'm not sure it would require less effort to make it comparing with running the currently available cvs build script or even preparing a validated csv file manually for very simple cases...
To be continued...

[drbenmorgan]

Thanks for the info @fmauger, yes that does sound like it would be complex! I think as long as we could have the csv file generated as part of the build, that would address the main concern. That is, only having to edit the conf files, with the csv file being "compiled" for you by the build, so it doesn't have to be manually edited or the script run by hand (though those ways would still be available).

[fmauger]

ok. so we could try to implement a custom command that build the csv from the Bayeux bash script if nothing prevent fully automated procedure. anyway, during a development phase that proposes some mods in the variant system (typically adding more options, possibly conditional) we still need to manually play with the script or even manually check to consistancy of the proposed csv files. at the end we are supposed to converge to the "solution" and to be able to automate it.