Blog from June, 2006

Diagrams from Nicola illustrating the handling of the Ancillary Data in Gleam.

AdfReader 
 
AncillaryData 

Ancillary Data Recon

Here is a picture of the beamtest coordinate systems.

This is the place where starting collecting ideas on the BeamTest setups and improvements in the MC generation.

 beamtest06

• The geometry of the PS setup actually used is described very well by Stefan here
• Other setups are in progress.
• The requirements come from the following list:

Photon runs
------------
2 cerenkov
1 large plastic (1cm thick) for rate monitoring
2 finger counters (2mm thickness, overlap of 1x1cm) for triggering
1 large plastic (1cm thick) with a 24mm diameter hole centered on the
beam for vetoing background
2 XY silicon layers before the magnet
1 magnet
2 XY silicon layers after the magnet
1 plastic (1cm thick) after the last silicon for triggering

comment: we might deplete the 2nd cerenkov to reduce X0 if we realize
that the photon trigger is efficient

Electron runs
--------------
2 cerenkov
1 large plastic (1cm thick) for rate monitoring
2 finger counters (2mm thickness, overlap of 1x1cm) for triggering
1 large plastic (1cm thick) with a 24mm diameter hole centered on the
beam for vetoing background
1 XY silicon layers before the magnet
1 magnet OFF

comment: we might need a trigger scintillator in coincidence with the
fingers just before the CU

Positron runs
--------------
2 cerenkov
1 large plastic (1cm thick) for rate monitoring
2 finger counters (2mm thickness, overlap of 1x1cm) for triggering
1 large plastic (1cm thick) with a 24mm diameter hole centered on the
beam for vetoing background
1 XY silicon layers before the magnet
1 magnet ON
1 EM CAL (40cm NaI) to veto gammas
1 plastic after the annihilator before the CU to veto electron/positron

Proton runs
--------------
2 cerenkov
1 large plastic (1cm thick) for rate monitoring
2 finger counters (2mm thickness, overlap of 1x1cm) for triggering
1 large plastic (1cm thick) with a 24mm diameter hole centered on the
beam for vetoing background
1 XY silicon layers before the magnet
1 magnet OFF

comment: we might need a trigger scintillator in coincidence with the
fingers just before the CU

general comment: the veto counter (plastic with hole) might be removed
if background is measured to be low enough

Mass Simulations Status

 Tom, Francesco, Stefan, Richard

•  we are following the posted simulations request.
• initial strategy is to bracket the PS and SPS runs in energy and map out the full angle and energy ranges; also to do the positron annihilation and proton disappearance runs. Stefan has written up a description of the setups.
  • then fill in other energies

• merged merit tuples are being provided - which include beamline MC info
• initial BT tuples are being provided. Needs feedback!
• see the MC log for what is what

Status:

• SPS runs completed - BeamTest-0032-0066.
  • tuple files being concatenated
  • a bug swapping transverse coordinate between beamline and CU was found and fixed. We think this is benign for SPS runs due to symmetric beam profile. Fixed for PS runs - important for annihilation runs.

• PS runs setup for positron and electron essentially complete - BeamTest-0067-0104

• • expected to start running today (Tues)

• • more setups to be included in simulation see the MC status page for more information

I have worked on the code for the Geometry of the PS and SPS simulations. In particular I have added the following:
 

PS Runs: 

The geometry for the positron runs is depicted in the following image: 

• Two cherenkov counters
  • Size 5 and 3 m, 0.6 mm Mylar windows at the ends

• • Configurable pressure of the C02 gas (by default 0.1 atm), keyword: /Cern/detector/cherenkovpressure
• Plastic0 and Plastic1 detectors
  • spacing of the two detectors: 2 cm
  • 3mm wide Styrene
  • Size adjustable, typically: 1cm x 1cm keyword: /Cern/detector/triggerywidth and triggerzwidth

• • Position in X adjustable. keyword: /Cern/detector/triggerxpos

• Dump:
  • Position adjustable in x, y, z. keyword /Cern/detector/dumpxpos, dumpypos, dumpzpos

• • Can be moved out of the beam by putting the y-position to a larger value than 100 cm (that is the half-size of the dump in y)
• Annihilator:
  • Position adjustable in x, y, z. keyword: /Cern/detector/annihixpos, annihiypos, annihizpos
  • Can be moved out of the beam by putting the y-position to a larger value than 30 cm (half size of the annihilator in y)
  • Only to be used for the positron runs and the corresponding electron runs

• • Thickness according to blanket, thickness 12 cm (4 times the annihilator foil), density of the material enhanced by factor 10 to increase annihilation fraction
• Plastic2 veto detector
  • 1 cm wide Styrene, 60cm x 60 cm area

• • Position adjustable in x,y,z. keyword: /Cern/detector/vetoxpos vetoypos, vetozpos
  • Can be moved out of the beam by putting the y-position to a larger value than 30 cm (half size of the veto)
  • Can be used for vetoing the charged particles

Additional changes include:

1. Sampling position now from the plastic0 detector, then extrapolating the event back to the start of the beam line. This point is used for the start of the event.
   From there the event is propagated through the geometry. Doing so enhances the probability of the particles hitting the trigger plastic0 detector (they do 100%
   of the times if we switch off the multiple scattering on the way).
2. By adding the keyword /Cern/detector/positronrun 1 one can write out only the events that triggered plastic0 and plastic1 and did not leave a signal in plastic2.
   These are the events that we eventually are looking for in the positron runs (annihilation events).
3. Added an energy measurement for all the detectors in the beamline to the output. These can be used for cutting on the signals (e.g. requiring no energy measurement
   in the veto plastic2.
4. For the positron annihilation runs, we now decided to use the magnet according to Nicola's suggestion. Otherwise the background from high-energy bremsstrahlungs
   photons would be too high if we use the direct beam.

SPS runs:
 

 
Simpler geometry, we shoot directly into the detector. We have the following components:

• Cherenkov counter:

• • Size 5 and 3 m, 0.6 mm Mylar windows at the ends

• • Configurable pressure of the C02 gas (by default 0.1 atm), keyword: /Cern/detector/cherenkovpressure
• Plastic 0 and Plastic1 detector
  • exactly like in the PS geometry

The current beam test plan is posted here.

Simulations:

• PS, SPS configurations - done - SPS, done PS? (Stefan, Benoit, Luca, Nicola, Francesco)

• wire up BT tuple to pipeline - done (Tom)
• create pipeline task configs - SPS done; PS done (Tom, Francesco, Stefan)
• run tasks - all complete except e+ annihilation and proton disappearance runs. Awaiting configs from Benoit.
• post-pipeline jobs (concatenate merged merit, and BTtuple) - Merit: SPS done; PS in progress.  BTtuple: in development (Tom)

Data Pipeline

• Clone svac tasks - done (Warren)
  • dealing with back fitting TestReports to LATTE from LICOS

• try test run from Pisa - done! (Michael, Warren)

Digi/recon/calibs of Ancillary Data

• New packages to replace AncillaryEvent will be committed to CVS:  AdfEvent, AdEvent, AdUtil,  AdfRecon, AdfReader (Nicola, Michael, Johan)
• Initially ancillary data may not be in LDF format, so a temporary package, AdfReader will contain Gaudi algorithms to ingest the binary data and populate the TDS (Nicola).
• Once the TDS classes are ready, ROOT versions of the classes will be created and RootIo updated to handle the reading and writing. (Heather/Leon)
• When the ancillary data is available within LDF format, LdfConverter and ldfReader will be updated to handle the new contribution(s). (Heather)

 Socket Gleam

• Has not received a high priority yet.
• LATTE can serve LDF data (even data residing in a file) via two applications: oscmanager and RunControl.  The two work together to make LDF available to clients.

• LATTE and the RunControl framework are being studied to see if ldfReader can be modified to connect a socket to RunControl to ingest LDF data.  (Heather)

Visualizing G4 Geometry

• Linux - release version built at SLAC (Francesco) -- debug to be done

• Windows - new version to be built (Francesco and Riccardo)
• Modify beamtest06 requirements

Benoit has revised his list of desired simulation configurations:

"I have attached the configuration file with the different positions required. The first three parameters (pivot, vertical translation) are fixed.

It would be nice to run all configurations for electrons at PS (1,5,10,15 GeV) and SPS (10,20,50,100,200,280 GeV).
That's many runs, but it will typical of what is needed for the experiment. If it appears to be too much, we will reduce the number of energies."

For positrons at 1 GeV, only position 0 at 0 degree is needed.

 [Ed. There are 17 configs x 10 energies  - 170 sets of runs(!)]
 [Ed's Ed. make that 18 configs] 

BeamTransform.vertical_translation = 23; 
BeamTransform.pivot_location = -130;
BeamTransform.pivot_offset = 45;

0 degree, position 0
BeamTransform.horizontal_translation = -201.2; 
BeamTransform.table_rotation = 0;

0 degree, position 1
BeamTransform.horizontal_translation = -340; 
BeamTransform.table_rotation = 0;

5 degrees, position 0
BeamTransform.horizontal_translation = -193.46; 
BeamTransform.table_rotation = 5;

5 degrees, position 1
BeamTransform.horizontal_translation = -331.73; 
BeamTransform.table_rotation = 5;

5 degrees, position 2
BeamTransform.horizontal_translation = -373.4; 
BeamTransform.table_rotation = 5;

20 degrees, position 0
BeamTransform.horizontal_translation = -3.67; 
BeamTransform.table_rotation = 20;

20 degrees, position 1
BeamTransform.horizontal_translation = -163.73; 
BeamTransform.table_rotation = 20;

20 degrees, position 2
BeamTransform.horizontal_translation = -294.2; 
BeamTransform.table_rotation = 20;

20 degrees, position 3
BeamTransform.horizontal_translation = -355.5; 
BeamTransform.table_rotation = 20;

40 degrees, position 0
BeamTransform.horizontal_translation = -12.32; 
BeamTransform.table_rotation = 40;

40 degrees, position 1
BeamTransform.horizontal_translation = -111.95; 
BeamTransform.table_rotation = 40;

40 degrees, position 2
BeamTransform.horizontal_translation = -218.3; 
BeamTransform.table_rotation = 40;

40 degrees, position 3
BeamTransform.horizontal_translation = -299.1; 
BeamTransform.table_rotation =40;

60 degrees, position 0
BeamTransform.horizontal_translation = -24.9; 
BeamTransform.table_rotation = 60;

60 degrees, position 1
BeamTransform.horizontal_translation = -52.09; 
BeamTransform.table_rotation = 60;

60 degrees, position 2
BeamTransform.horizontal_translation = -121.5; 
BeamTransform.table_rotation = 60;

60 degrees, position 3
BeamTransform.horizontal_translation = -212.1; 
BeamTransform.table_rotation =60;

90 degrees, position 0
BeamTransform.horizontal_translation = 0; 
BeamTransform.table_rotation = 90;

Would be nice to have the X and Y incidence point of the beam and beam width for each MC run as part of the table that contains a list of runs

Present: TonyJ, Eduardo, Benoit, Richard, Anders

I have contacted Ric for his thoughts on eLog. He has been gearing up to have a BTeLog, but agrees support for it is minimal at present with other pressures. 

eLog 

 For various reasons, we think the current eLog is not ideal for future offline use, notably it being a perl/cgi app, whereas the offline webbery is JSP now. Also, Eduardo expressed the opinion that it is not that great for offline use.

We will try to make use of the soon-to-come Dataset Catalogue, and so we need metadata for the runs. Anders agreed to identify what items we need and where we can hope to find them. Hopefully it will result in a form the pipeline can parse and then update the catalogue.

Web interface 

Tony would start from the BT99 web interface that Karen wrote and go from there.

Present: Eduardo, Richard, Stefan, Benoit, Leon, Heather, Anders, TonyJ, Tracy, DavidP

 Sims

Stefan will come up with a new beamtest06 version to better simulate the SPS beamline. He will also include the new detectors in the MC output tuple, ensuring they get into the merit tuple merge.

Benoit will revive the list of desired sims. He estimated 50-80 configurations.

Both of these items have an expected 1-day turnaround

Digi/Recon 

 Nicola has created an all-in-one AncillaryEvent package to read, digitize and reconstruct the ancillary detector data. Leon, Heather and Joanne have given feedback on desired updates; Nicola will get on it on Monday. Once he turns this around, Heather will jump in for the RootIo portion. She has sent him a query asking if he needs help to do this.

Calibrations

 Joanne sent a proposal for an xml format for the Si tagger data, and it seems to be close. I've asked Luca et al to provide the rest of the calibs as they come to understand them. Joanne figures it will be an elapsed week to set up the Gleam infrastructure.

Socket Gleam

No real progress here; has not bubbled up to high enough priority yet. 

Beamtest Tuple

The Cal tuple will persist.; Johann will investigate whether it can be resized for 3 vs 16 towers in the arrays. Johann will look into adding the centroid per CAL layer as per Jan's request; it should be available from the clusters. ACD vars are still to be added. Johann has added the requested ancillary items.

We will not copy the ancillary MC info now in merit to BT tuple. We will need summary ancillary data for merit, but there is no experience yet as to what. We will probably want a BTvalsTool for this. Anders and Johann will consult with Tom on how to create this for MC.

Pipeline Config for Data

 After discussions with Anders and Warren, we have decided to clone the svac tasks and modify as needed for BT. Warren is well into the cloning already.

Here is a table of simulations needed, from Benoit.