Choose timezone
Your profile timezone:
Powered by Indico
v3.3.2
Zoom connection: https://bnl.zoomgov.com/j/1612787551?pwd=VzBZYVpsMGM3TnpMRHl2K1puOFd5Zz09
Meeting ID: 161 278 7551
Passcode: 707179
One tap mobile
+16692545252,,1612787551#,,,,*707179# US (San Jose)
+16468287666,,1612787551#,,,,*707179# US (New York)
ZOOM RecordingPasscode: iJh8tD$N |
Minutes for GD/I Meeting on Thursday, October 13, 2022
Talk by Renuka Rajput-Ghoshal
-Move from aluminum to copper cladding because of vendor issue, but no significant change in magnet specs and hadron interaction length for the magnet.
-New solenoid magnet specs shown, including conductor specs as well as other relevant solenoidal specs.
-New simulations of magnet shown and discussed from MARCO.
-Confident can reach 2T without a problem with this magnet, in a safe way at ~4K.
- Discussion of instrumentation and cryogenics for magnet. Preliminary version of instrumentation so expect changes here as design develops.
- Material budget of solenoid is required to be less than 1 interaction length, which MARCO confirms.
- Discussion of procurement status for various parts of magnet (e.g. solenoid, conductor, power supply, etc.).
-Expect 90% design contract with CEA Saclay to be placed Nov 1, 2022.
- analysis work for design is ~60% complete. Review next week.
Jin Huang - Do we have copper cladding in simulation in material description?
— Renuka, Elke, Wouter - Field map implemented, material budget shared with sim team
Jin Huang - What is envisioned for switching the field direction?
— Renuka - can do it, but magnet has large inductance. Don’t want to go immediately from +2T to -2T. Power supply has built in reversal switch that can be controlled remotely
John Lajoie - Thermal margin for 1.7T quoted as 2.5K?
— Renuka - This is dependent on field and temperature both. Bigger the margin, safer for the magnet. But also don’t want to have it so large that the magnet isn’t being used effectively. Lower the margin the lower is the chance for magnet quenching.
Talk by Rey Cruz Torres on background embedding progress
- Have single photon events in hepmc files from a virtual cylinder within the beam pipe.
- Have full radiation events given some integration time window.
- Need to store these in a universal container and propagate them through Geant simulation.
- some issue with how dd4hep reads in vertices from the synchrotron photons.
- Discussing with Sylvester and Wouter to file a ticket with dd4hep or HEPMC.
- In the meantime, alternative solution being explored. But is not ideal and would prefer the first solution that suffers from this bug.
Sylvester Joosten - Putting fake photon to status 2, hepmc doesn’t like unstable photons. Maybe try putting it to status 21.
Jin Huang - What is the current cutoff for photon generation? How many photons are we going to throw into the simulation for every event?
— Rey - if I remember correctly it is 5 keV. How many photons to throw in the event, I am not sure. Can continue sampling from the distribution to get new events. If we move to the new alternative method, we will have to pass the same photon event multiple times through Geant and sample from different pools, which is not ideal as it is higher computational load.
Jin Huang - could be difficult CPU wise in simulation if we have to simulate all of these photons. Depends on the time window also.
— Rey - A single event with 100ns integration window results in ~250 photons but this translates to fewer hits.
Oskar Hartbrich - We are talking about keV scale. Other experiments do things like gold plating beam pipes to help this. Do we have this in the simulation?
— Rey - yes, we have a 5 um gold coating in the beam pipe in the simulation.
Oskar - Another question. Beam gas gives different backgrounds. Is anyone looking into this?
— Rey - Yes, but not me. Idea is to combine the effort.
Elke - I gave a talk a while ago about all background we are simulating. Presented simulations for beam gas (pronto and electron), and synchrotron. https://indico.bnl.gov/event/16414/
Talk by Joe Osborn on outstanding simulation geometry issues
- Discussed outstanding issues
- Some discussion about how there is poor transfer of information between the detector menagerie and the simulation geometry. Needs to be improved, but not sure how right now. One improvement would be to output menagerie information in computer readable format, e.g. CSV file.
Issue #1 - Overlaps with tracking support for pfRICH and Imaging ECal
- Overlaps probably due to outdated tracking support geometry. Needs updating
- For now, implement simplest solutions before full optimization of tracking support structures and services:
- pfRICH overlap - Reduce pfRICH volume to fix overlap and add in cylinder in vacated space to approximate material correctly for calorimeters.
- Imaging ECal overlap - Shift cable turn such that it is not overlapping with the ECal or dRICH, and update the material thickness. Will result in more material, but optimization can continue over time.
Issue #2 - Move inner MPGD layer from 51 cm to 55 cm in radius
- Menagerie only provides limits for subsystems to work within. In the particular case of the tracking volume, it only specifies the envelope for the integrated silicon tracker + inner MPGD. This stays within volumes defined by menagerie, so should be good to include in simulation.
Issue #3 - dRICH Aerogel discrepancy between simulation and menagerie
- No issue foreseen expanding outer aerogel radius from 95cm to 110 cm.
Issue #4 - ECal insert discrepancy in z position between menagerie and simulation
- Need to check z positions of various surrounding subsystems and confirm they are within envelopes defined by menagerie.
Friederike Bock - Look at support structures of forward ECal.
Elke Aschenauer - Check also outer HCal length is consistent with menagerie.
Issue #5 - Solenoid offset in z to match field map
- Move by 10 cm to match field map implementation. Do not move calorimeters, only magnet needs to move.