1. Laser Software Status and Comments on Concerns
Italian g-2 Group Meeting
Matthias Smith

2. Laser Software Status Already gave a recent update (see here)
A few updates
Anna’s OoF gain module is in production
IF gain functions are characterized for all Run 1 data (into production soon)
5/11/2019
M. Smith - g-2it Mtg

3. Concerns About Laser System
Note that this is all very recent, so take everything with a grain of salt for now
From Josh’s Talk
Odd Laser Energies
Overall Energy Shift
From s
Scheme for calib constants
Lack of DB presence
5/11/2019
M. Smith - g-2it Mtg

4. Odd Laser Energies Have “Returned”
We still see laser energies which fall well outside the expected distribution.
These error peaks are all higher energy than their corresponding main peaks, but the entire spectrum appears to be shifted to lower energies relative to previous iterations.
5/11/2019
M. Smith - g-2it Mtg

5. Subrun 447 Appears to be Improperly Filled in .fcl File
Calo 24
Run 15923
Some subruns have an invalid (default) gain correction factor stored in the .fcl file, which means that they will not have their energies properly corrected.
Maybe we should set the default/invalid corrections to some nonsense value like 9999 or 0? Would make it much easier to identify/discard.
Only present in test dataset, will be removed for full production.
5/11/2019
M. Smith - g-2it Mtg

6. Comments Not a big problem
As Josh mentions, this will be filtered out for production
5/11/2019
M. Smith - g-2it Mtg

7. Calo 12 and 13 Are Better Behaved
All of the peak shapes appear more gaussian in v9_10 compared to previous versions.
5/11/2019
M. Smith - g-2it Mtg

8. Laser Energies Shifted Compared to Previous Data
v9_07 (9d)
v9_10 (60h)
Could this shift be the result of an improperly applied long term gain correction (multiplying vs. dividing the correction factor)?
Or if the gain correction factor is properly applied, has some other normalization factor changed?
5/11/2019
M. Smith - g-2it Mtg

9. Comments
It seems to me that the out-of-fill correction was not being applied properly before
The multi-peak shape would arise from the day/night cycle in 60h or 9d
Anna’s correction shows the correct behavior
1.6% drift
0.3% drift
Note: I think the long term drift correction is applied here, but I’ve not been able to prove it for myself yet
5/11/2019
M. Smith - g-2it Mtg

10. Energy Shift From v9_07 → v9_10
(These plots normalized by the integral from 2000 to 3000 MeV)
5/11/2019
M. Smith - g-2it Mtg

11. Energy Shift Appears to be Variable, But Ratio is Fairly Constant
5/11/2019
M. Smith - g-2it Mtg

12. Comments I think this is consistent with improper OoF
If the old correction was used to generate the calibration constants, then those could be affected too
5/11/2019
M. Smith - g-2it Mtg

13. Comments on OoF Scheme Anna is really the one to ask here
I’m not sure exactly what is meant, but it could just be referring to the fact that the constants are not in the database
5/11/2019
M. Smith - g-2it Mtg

14. Comments on DB
Laser system is not using the DB for correction constants/parameters
As far as I know, we are still experiencing bad reads from the DB
In this context, it doesn’t make sense to me to focus on developing and using that interface
I am currently developing a scheme for using IFG functions that can be reimplemented in the DB with little effort
Production cannot write to the DB, so Anna has gone the fhicl route for OoF
5/11/2019
M. Smith - g-2it Mtg