Project

General

Profile

Feature #1553

Geometry Comparison

Added by Rogers, Chris almost 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Geometry
Target version:
Start date:
30 September 2014
Due date:
% Done:

100%

Estimated time:
Workflow:
New Issue

Description

I am performing a comparison of the MAUS geometry as implemented using CAD import and Ryan Bayes algorithm with Chris Hunt geometry. Specifically, I am trying to understand what is implemented in each geometry set up, and how much work it would be to reimplement the CAD functionality using text files as in Chris Hunt implementation. Ken Long wants me to turn this around pretty quickly


Files

Step_3pi2_alt_15_1.dat (67.3 KB) Step_3pi2_alt_15_1.dat Rogers, Chris, 30 September 2014 18:12
bayes_geometry_v1.tar.gz (938 KB) bayes_geometry_v1.tar.gz Rogers, Chris, 30 September 2014 18:20
bfield_vs_z.png (6.56 KB) bfield_vs_z.png Rogers, Chris, 02 October 2014 14:33
material_vs_z-1d.png (14.4 KB) material_vs_z-1d.png Rogers, Chris, 02 October 2014 14:33
material_vs_x-z-2d.png (31.5 KB) material_vs_x-z-2d.png Rogers, Chris, 02 October 2014 14:33
material_vs_x-z-2d.root (2.04 MB) material_vs_x-z-2d.root Rogers, Chris, 02 October 2014 14:33
material_vs_z-1d.root (76.2 KB) material_vs_z-1d.root Rogers, Chris, 02 October 2014 14:33
db1dx0_vs_z.png (9.02 KB) db1dx0_vs_z.png Rogers, Chris, 02 October 2014 14:33
bayes_geometry_v2.tar.gz (1.84 MB) bayes_geometry_v2.tar.gz Rogers, Chris, 02 October 2014 17:45
Hunt_StepIV_Geometry.dat (62.7 KB) Hunt_StepIV_Geometry.dat Rogers, Chris, 07 October 2014 09:37
hunt-v1_bfield_vs_z.png (10.3 KB) hunt-v1_bfield_vs_z.png Rogers, Chris, 07 October 2014 11:03
hunt-v1_material_vs_x-z-2d.png (18.5 KB) hunt-v1_material_vs_x-z-2d.png Rogers, Chris, 07 October 2014 11:03
hunt-v1_material_vs_x-z-2d.root (7.63 MB) hunt-v1_material_vs_x-z-2d.root Rogers, Chris, 07 October 2014 11:03
hunt-v1_material_vs_z-1d.png (7.89 KB) hunt-v1_material_vs_z-1d.png Rogers, Chris, 07 October 2014 11:03
hunt-v1_material_vs_z-1d.root (42.8 KB) hunt-v1_material_vs_z-1d.root Rogers, Chris, 07 October 2014 11:03
geometry_validation_volumes_2d.root (70 KB) geometry_validation_volumes_2d.root Rogers, Chris, 17 October 2014 08:25
geometry_validation_volumes_2d.png (66.1 KB) geometry_validation_volumes_2d.png Rogers, Chris, 17 October 2014 08:25
geometry_validation_volumes.json (27.3 KB) geometry_validation_volumes.json Rogers, Chris, 17 October 2014 08:25
geometry_validation_volumes_1d.root (201 KB) geometry_validation_volumes_1d.root Rogers, Chris, 17 October 2014 08:46
geometry_validation_volumes_1d.png (57.4 KB) geometry_validation_volumes_1d.png Rogers, Chris, 17 October 2014 08:46
test_latest_geometry_44.tar.gz (30.1 MB) test_latest_geometry_44.tar.gz Rogers, Chris, 17 October 2014 17:41

Related issues

Related to MAUS - Feature #1567: Volume plot in geometry validationClosedRogers, Chris16 October 2014

Actions
Related to MAUS - Bug #1569: Latest geometry download failsClosedRogers, Chris17 October 2014

Actions
#1

Updated by Rogers, Chris almost 7 years ago

By email:

It will run against the last release and most certainly the trunk. The last release included a few minor adjustments required for the cherenkov. If you have any problems, complain loudly.

The changes that I am working on now primarily effect the field on D2 as a function of the CDB beam line current (there was some problem in the current to field scaling) and the naming of the Downstream tracker solenoid current (which looks a little too much like the decay solenoid current for the xslt stylesheet). For the time being, magnet fields can be altered by hand in “ParentGeometryFile.dat”.

Regards,
Ryan

On Sep 30, 2014, at 12:47 PM, Chris Rogers <chris.rogers@stfc.ac.uk<mailto:chris.rogers@stfc.ac.uk>> wrote:

Will this run against the trunk?

Cheers,
Chris

On 29/09/14 22:44, Ryan Bayes wrote:
Hi Chris,

My latest geometry is available on the Config DB as under geometry ID 40. This includes the CAD stuff (which are all of the static beam line elements, all of the detectors, and diffuser irises). To the best of my knowledge this is in serviceable order in the default configuration, although the load times are a little bit slow as yet.

I am working with Jason to get a Step IV CAD geometry that will work with the GDML parser. I figure it is pointless to continue more testing with that system until the overlap problem is solved.

I am in the process of verifying that the “EPICS integration stuff” works. I am doing this now in preparation for the planned simulations. I know that the default beam I have set up can be used to track particles through the beam line  from D2, but these default fields do not work in the cooling channel. I know this based on my use of Chris Hunt’s scripts with my geometry. To see examples of this you can look at the notes that I made for the last geometry meeting — geometry-20140919.pdf<http://micewww.pp.rl.ac.uk/attachments/2560/geometry-20140919.pdf>. To update the beam line currents easily I need to have the CDB “Beamline” stuff properly integrated. The missing piece is knowing how to access the diffuser state, which was the upshot of my miscommunication with Janusz last week.

Ryan Bayes

School of Physics and Astronomy
Rm 233a, Kelvin Building
University of Glasgow, Glasgow G12 8QQ
Phone: +44(0)141 330 2395
Mobile: +44(0)792 349 0684

Ryan.Bayes@glasgow.ac.uk<mailto:Ryan.Bayes@glasgow.ac.uk><mailto:Ryan.Bayes@glasgow.ac.uk>

On Sep 29, 2014, at 5:22 PM, Chris Rogers <chris.rogers@stfc.ac.uk<mailto:chris.rogers@stfc.ac.uk><mailto:chris.rogers@stfc.ac.uk>> wrote:

Folks,
[redacted] Could I ask - could either of you point me at a reasonably recent geometry that I could run some tracking against? I would like to, for example, compare the MC output from Chris Hunt geometry with the MC output from Ryan Bayes geometry.

My aim is to produce a table that indicates the functionality that we gain/lose by going between the two geometry implementations (that should include, for example, can we simulate the beamline, are we integrated into the EPICS stuff, but also does the beam go through in a sensible way, do beta functions look correct, etc).

Could you please help by letting me know where your "best" geometry is?

Thanks,
Chris
#2

Updated by Rogers, Chris almost 7 years ago

By email from Chris Hunt with attachment Step_3pi2_alt_15_1.dat

Hi Chris

I've attached the latest geometry that was used in the plots for the DOE
review.

The numbering scheme is my cryptic method to keep account of the various
copies. This includes asymmetric coil currents to account for energy
loss in the absorber and the Tracker He windows. There are similar
geometries with the "Bross-Window" or symmetric currents. But this is
the current one.

Jaroslaw and I are due toe improve the matching this week so it the coil
currents may be tweaked slightly in the next few days. I'll send you a
copy when we finish.

Cheers

Chris
#3

Updated by Rogers, Chris almost 7 years ago

Against Ryan's geometry, I ran

python ${MAUS_ROOT_DIR}/bin/utilities/download_geometry.py --geometry_download_by id --geometry_download_id 40 --geometry_download_directory geometry >& download.log

Note lots of warnings like

I/O warning : failed to load external entity "geometry/geometry/TD-1189-3462_Tufnol_01-08-13_materials.xml" 

Maybe it is okay, let's continue. I wanted first to plot the field map. I did

python make_field_map.py --configuration_file configuration.py

and the script failed with error

MatPlotLib not detected - matplotlib graphing functions will not be available
Welcome to MAUS field map maker example
Building field maps and other initialisation (this can take a while)
Traceback (most recent call last):
  File "make_field_map.py", line 72, in <module>
    main()
  File "make_field_map.py", line 42, in main
    maus_globals.birth(configuration)
RuntimeError: Dimension x in module ParentGeometryFile.dat/Iges_0.dat out of range at MiceModToG4Solid::checkDim

I note that the file Iges_0.dat does indeed not exist anywhere on my hard drive. I attach e.g. log file for the geometry directory. Attachment bayes_geometry_v1.tar.gz contains files detailed in this item.

#4

Updated by Bayes, Ryan almost 7 years ago

There is a clear failure here. I ran Chris's download command and I reproduced his IO warnings. I did not reproduce his more substantial error in running his script, but I think I understand the source of the error.

The IO warnings can be simply removed by using an absolute file location for the geometry directory rather than a local one. This is necessary to allow the geometry to be used from an arbitrary location on your system and evidently the subroutine that adjusts the directories to match the download location fails completely if the directory is local.

The more substantive issue --- referencing the non-existent Iges_0.dat --- is a minor problem in the geometry upload. The ParentGeometryFile is generated from either a file named Step_IV.gdml or FastradModel.gdml. I accidentally left an obsolete file named FastradModel.gdml in the geometry upload which contains these references to Iges_0.dat. I have not observed this problem in my own downloads of this geometry id number for an unknown reason. I have re-uploaded the geometry with the offending file removed. People interested in using this geometry should use geometry download id 41 to avoid this problem completely.

#5

Updated by Rogers, Chris almost 7 years ago

I tried using absolute path like

python ${MAUS_ROOT_DIR}/bin/utilities/download_geometry.py --geometry_download_by id --geometry_download_id 41 --geometry_download_directory /home/cr67/MAUS/work/geometry_comparison/bayes/geometry

and got a failure like

Traceback (most recent call last):
  File "/mnt/fdbd8899-86c5-4e8b-8e68-0f39de13fa76/home/cr67/MAUS/maus_merge/bin/utilities/download_geometry.py", line 80, in <module>
    main()
  File "/mnt/fdbd8899-86c5-4e8b-8e68-0f39de13fa76/home/cr67/MAUS/maus_merge/bin/utilities/download_geometry.py", line 59, in main
    (configuration.geometry_download_id, gdml_cache)
  File "/mnt/fdbd8899-86c5-4e8b-8e68-0f39de13fa76/home/cr67/MAUS/maus_merge/src/common_py/geometry/GDMLtoCDB.py", line 234, in download_geometry_by_id
    raise OSError('Path '+download_path+' does not exist')
OSError: Path /home/cr67/MAUS/work/geometry_comparison/bayes/geometry/gdml does not exist
#6

Updated by Rogers, Chris almost 7 years ago

Ah, last one was my fault, the directory /home/cr67/MAUS/work/geometry_comparison/bayes/geometry/ did not exist... Sorry!

#7

Updated by Rogers, Chris almost 7 years ago

By email from Ryan

Additionally, I found a bug that was propagated to the trunk. In my last sweep of the material definitions, I put “LEAD” into the module translation where I meant to input “Pb". It can be fixed in the by running the command

sed -i “s/LEAD/Pb/g” Iges_*.dat

in your download geometry directory. I have fixed the issue and pointed it out to Durga.
#8

Updated by Rogers, Chris almost 7 years ago

I modified the verbose stepping code so that it additionally spits out volume name and material name on each step when activated using keep_steps datacard. I attach various files containing field maps and 2D projections of material in the geometry model:

#9

Updated by Rogers, Chris almost 7 years ago

So, comments:

  • The quad field is misaligned from the quad body; squinting at material_vs_x-z-2d.png and db1dx0_vs_z.png the quad body starts at 1.2 m; the quad field map starts at more like 2.2 m
  • I have not yet validated the aperture of the quad; my recollection of the quad pole tip aperture is 172 mm, but this would be on the line x = y whereas I only looked at the line y = 0
Looking at material_vs_z-1d.png and material_vs_x-z-2d.png going down the cooling channel
  • I don't understand the upstream end of the cooling channel - there are two Aluminium windows, is one of these diffuser? there is a lot of hardware at r=100-150 mm, what is this? It looks like there is air inside the Aluminium windows, should that be there? If so, where is the vacuum window?
  • There is no window downstream of the Helium tracker volume
  • Why is there Helium at 16 m?
  • Why is there Aluminium around the AFC? This is a LiH geometry...
  • Why is there air in the AFC
  • I only count 4 stations in the downstream tracker (zoom into the root file)
  • Why is there no window downstream of downstream tracker?
  • I don't see any data between z=20800 and z=21100 - this must be a bug in my scripts.
#10

Updated by Rogers, Chris almost 7 years ago

Attached v2 of the geometry and scripts used to generate the validation plots. Nb: the code that writes out material names is in the trunk latest version as of this morning, scripts won't work without it.

#11

Updated by Bayes, Ryan almost 7 years ago

A point by point reply ---

"The quad field is misaligned from the quad body; squinting at material_vs_x-z-2d.png and db1dx0_vs_z.png the quad body starts at 1.2 m; the quad field map starts at more like 2.2 m"
  • This is an outright mistake. I cannot speak to how this happened, but it can be corrected. The position of the field is the opening position of the field box (which is defined by the object centre - the object length/2 - the length of the fringe field) and not related to the material positions directly (yet, I am thinking of a way to fix that). Review of the CAD shows the centre positions of the quads are at 1867.31 mm for Q1, 3027.31 mm for Q2, 4187.31 mm for Q3, 9499.41 mm for Q4, 10659.41 mm for Q5, and 11819.41 mm for Q6. The upstream most piece of iron associated with the Q1 is at 1344 which gives a half length of 523 mm. Assuming a fringe field length (end length) of 125.72 mm (I am not sure how this is derived, and I think this was assumed from previously existing material files anyway).
"I don't understand the upstream end of the cooling channel - there are two Aluminium windows, is one of these diffuser? there is a lot of hardware at r=100-150 mm, what is this? It looks like there is air inside the Aluminium windows, should that be there? If so, where is the vacuum window?"
  • This is the diffuser. I know (well I have seen) an aluminium window at the downstream end of the diffuser. I am not sure about the second (interior) window. I will investigate, but it looks like it is immediately upstream of the irises.
"There is no window downstream of the Helium tracker volume. Why is there Helium at 16 m?"
  • These are the same problem. The upstream Helium window volume (which includes a vacuum volume right now) is backwards due to an arcane reason that I will not go into. This can be corrected by changing the name of the rotation reference for the upstream helium window to include "rotRef" in the GDML source file.
"Why is there Aluminium around the AFC? This is a LiH geometry..."
  • We (Stephania and I) asked Jason about this when we first noticed that there was an additional source of energy loss upstream of the absorber. He assured us that it was supposed to be there as an "asymmetric vacuum window" in that position independent of the absorber.
"Why is there air in the AFC?"
  • The default material right now is air. No vacuum volume has been defined within the AFC, and no-one has gave me a clear answer about the extent of a vacuum volume outside of the solenoid bore (and even word on that is sketchy). It may be enough to extend the vacuum volume that is used to in conjunction with the helium window, but that cannot cover the entire affected volume. The better solution is to locate the entirety of the cooling channel within a mother volume that is defined to be vacuum, but that will require confirmation of the extent of the vacuum within the diffuser and some meddling with the xslt scripts (I think). Further confirmation about the extent of the vacuum in the cooling channel will be appreciated.
"I only count 4 stations in the downstream tracker (zoom into the root file)"
  • This is confusing --- could it be an aliasing problem? The source and download files have all five planes defined.
"Why is there no window downstream of downstream tracker?"
  • I will need to consult with Jason about this. This should be in the CAD.

I will correct what I am able to at the moment, and test it against the supplied scripts.

#12

Updated by Rogers, Chris almost 7 years ago

I only count 4 stations in the downstream tracker (zoom into the root file)"

This is confusing --- could it be an aliasing problem? The source and download files have all five planes defined.

I think that this approach does not make an aliasing problem - inherently, G4 will stop at any boundaries it sees and each step should get written out and plotted. So at least the 1d graph on-axis I think can't make an aliasing problem. The 2d plot is actually several overlaid TGraphs so maybe one could get drawn on top of the other - but at least I hard coded to draw Air then Galactic then everything else so they can't draw over the top (if I understand ROOT properly).

I wonder if some tracker stations are sticking out of a parent volume - so they get missed from the tracking?

#13

Updated by Bayes, Ryan almost 7 years ago

Rogers, Chris wrote:

I only count 4 stations in the downstream tracker (zoom into the root file)"

This is confusing --- could it be an aliasing problem? The source and download files have all five planes defined.

I think that this approach does not make an aliasing problem - inherently, G4 will stop at any boundaries it sees and each step should get written out and plotted. So at least the 1d graph on-axis I think can't make an aliasing problem. The 2d plot is actually several overlaid TGraphs so maybe one could get drawn on top of the other - but at least I hard coded to draw Air then Galactic then everything else so they can't draw over the top (if I understand ROOT properly).

I wonder if some tracker stations are sticking out of a parent volume - so they get missed from the tracking?

No. The tracker stations were there and not sticking out of a parent volume. The were overwritten by an overlapping volume; the helium window that was added ad hoc because it was only recently known (by me anyway) as a requirement. Removing the helium window allows the missing tracker station to appear. The helium window, as defined in this implementation needs to be corrected.

#14

Updated by Rogers, Chris almost 7 years ago

By email, from Victoria:

Hi Chris,

I'm attaching Chris H's Step IV geometry, but it's *not correct*. There's a few too many things that are off with it to be comfortable with it, so I'm sending it *unedited* to you -- I don't know if it's useful for you to see how things improve/regress with errors in the geometry files?  Anyway, just to state it again, I do *not* believe that this geometry file is 100% correct.

I'm meeting Adam & Chris at Imperial tomorrow (assuming the trains are running to London again) to go over the following:

    - The SS coils don't end up in the right place (they're correct relative to each other within the magnet, but are 135mm off where they should be globally. This is easy to fix, but before we do that.........
    - I'm wondering if the tracker ends up in the right place (if the coils are 135mm out, is the tracker also off? It should stay in the right place relative to the coils.. so this needs confirming with Adam/someone who knows the geometry of the tracker better than I do.
    - There're questions about the correct tracker station parameters (e.g. the "central fibre" value isn't what Chris H. currently has)
    - Focus coils are still incorrectly positioned (that is an easy fix, without any complications I can think of)
    - There's one-too-many flanges on the bore of the AFC (there's only one in reality, but there's two in the geometry I've attached)
    - Focus coils are made of aluminium instead of copper (which is probably closest to reality).  Though odd material choices are all in places where particles shouldn't be seen (or will disappear if they are), I'd still prefer it to be as correct as possible...
    - There's no diffuser or muon beam line (as I said in the meeting)

Overall, there's just a few too many niggles for me to feel comfortable saying it's correct...

(I'd love to run a visualisation of it to take a better look, but I did a nice clean Ubuntu update yesterday and need to figure out which exact library I'm now missing for MAUS to compile and behave again. However, that's my own silly fault for wanting the new 'shiny'. It won't hold me up for long... Worst case scenario is I boot into my old install.)

So, to summarise... there's some minor coil positioning changes that need to be done, but some larger considerations regarding the tracker and those coil position changes (since it'll move the fields). There's also some questions about the tracker station geometry that I need Adam to sign off on (who's consulting Geoff right now).  We settled on meeting tomorrow to hammer it all out (and of course you're welcome to join us).

Best,
Victoria
#17

Updated by Rogers, Chris almost 7 years ago

Further to Victoria's comments:

  • Fields:
    • I presume this was meant to be solenoid mode? I was expecting flip mode, but that's okay.
  • The tracker window is implemented as a polycone:
    • This does not "join" to the spectrometer warm bore, rather it is floating in mid air
    • This does not "join" to the tracker Helium volume, there is a few centimetre gap made of vacuum
  • The Hydrogen:
    • There are no windows on the Hydrogen(!)
    • The Hydrogen does not "join" to the AFC warm bore, rather it is floating in mid air
    • Somewhere near the outside edge of Helium there is a weird place were the Hydrogen volume looks very long. Probably this is just a bug in my scripts.
  • There are no flanges
  • Everything outside of the cooling channel is missing - windows, EMR, KL, TOF0-2, Ckov, etc, etc, ..., as well as windows on the cooling channel ends

Nb: where the plot shows white, this just means "no data" i.e. a particle didn't step in this region so it is not recorded.

#18

Updated by Rogers, Chris almost 7 years ago

I moved the geometry validation tool into the trunk lp:maus/merge at r782. Documentation is inline bin/utilities/geometry_validation.py

#19

Updated by Rogers, Chris almost 7 years ago

Following improvements outlined in #1567 I upload geometry validation volume plots. This means users can figure out which volume pertains to which physical thing. Note that I include the png files, but they are basically impossible to read. Please refer to the ROOT files and zoom around; I blame Ryan for including too much detail in the geometry :)

#20

Updated by Rogers, Chris almost 7 years ago

  • File geometry_validation_volumes_1d.png added
  • File geometry_validation_volumes_1d.root added

For some reason the 1d volume plot had wrong axes. Also it seems more convenient to sort by z position of the volume - please see revised plots.

#21

Updated by Rogers, Chris almost 7 years ago

  • File deleted (geometry_validation_volumes_1d.png)
#22

Updated by Rogers, Chris almost 7 years ago

  • File deleted (geometry_validation_volumes_1d.root)
#23

Updated by Rogers, Chris almost 7 years ago

  • File deleted (geometry_validation_volumes_1d.png)
#24

Updated by Rogers, Chris almost 7 years ago

  • File deleted (geometry_validation_volumes_1d.root)
#26

Updated by Rogers, Chris almost 7 years ago

Output plots for geometry id 44 are attached. Nb need to be untarred, sorry about that. I split the plotting job into two due to memory usage constraints of the validation tool - the tracking output file (json) is 4.8 GB for example. As per previous plots, png files are included for convenience but really you have to look at the ROOT files.

I didn't see any big errors this time. I note that the mysterious windows around LiH have bits missing. This is I guess due to the tessellated solid routine in G4 failing for thin volumes (e.g. the tesselation mesh is to granular). Something to investigate, probably low priority. I haven't yet gone through and checked the z positions of everything against e.g. Victoria's handy reference pdfs.

Note the mysterious windows around the LiH. Still an action on Rogers to talk to the engineers about this and understand if they are "real". It'll probably come up at CM40.

#27

Updated by Rogers, Chris almost 7 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

I think this is closed following the geometry workshop we held at Glasgow on Wednesday last week Geom_workshop_151014

Also available in: Atom PDF