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

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.

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

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

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.

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

• 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.

A point by point reply ---

• 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).

• 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.

• 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.

• 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.

• 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.

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

• 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.

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?

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.

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

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.

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