|
Request to Deploy ASP v3r1p1
Reasons for Change
Test ProcedureTested in dev on data in /ASP/TestSims2 and on relevant data in prod. Rollback ProcedureRevert to ASP v3r1p0 CCB JiraDetails
Request to deploy L1Proc 1.80
Reason for changeTo move log files from u15 to u52 and to switch to ROOT 5.20. Test ProcedureWe have processed runs in the DEV pipeline with this version of L1Proc. Rollback procedureWe can easily switch back to the previous version of L1Proc. SSC-235@JIRA L1Pipeline: L1Pipeline v1r80
GlastRelease: GlastRelease-15r47p12gr08 I think the only change in this GR wrt the version in use in L1, GR v15r47p12p06 is:
dataMonitoring/AlarmsCfg: AlarmsCfg-05-20-02
calibTkrUtil: v2r9p1
Complete set of tags for L1Proc 1.75 svac/L1Pipeline: L1Pipeline v1r80* calibTkrUtil v2r9p1 dataMonitoring/AlarmsCfg: AlarmsCfg-05-20-02* dataMonitoring/Common: Common-06-01-01 svac/Monitor: Monitor-01-03-03 users/richard/pipelineDatasets: v0r6 ft2Util: v1r2p31 evtClassDefs v0r14 GPLtools: GPLtools-01-15-01-fo04
Request to Deploy ASP v3r1p0
Reasons for Change
Test ProcedureTested in dev on data in /ASP/TestSims2. Rollback ProcedureRevert to ASP v3r0p3 and ST v9r15p4. CCB JiraDetails
Request to update alarm settings in L1Proc 1.79
Reason for changeThe new version (AlarmsCfg-05-20-03, as opposed to AlarmsCfg-05-20-01) includes a modification to accommodate the new LAT configuration in which the TEM diagnostics is enabled by default. Test ProcedureWe have processed monitoring products from real on-orbit data (LPA) locally with this version of AlarmsCfg. Rollback procedureThe package can be rolled back to the previous version by flipping a soft link. Also note that the package is completely independent from any other package running in the pipeline and will not cause a version change of L1Proc. CCB JiraDetails (release notes for dataMonitoring/AlarmCfg for AlarmsCfg-05-20-03)AlarmsCfg-05-20-03 16-Oct-2009 lbaldini Changed limits on the uncompressed/compressed event size)
Request to deploy L1Proc 1.78
Reason for changeWe would like to run for a few days the RHEL3 build of GlastRelease-v15r47p12gr06 (candidate release for the switchover to RHEL4), before moving on to RHEL4. Test ProcedureWe have processed runs in the DEV pipeline with this version of L1Proc. Rollback procedureWe can easily switch back to the previous version of L1Proc. CCB JiraDetailsL1Pipeline: L1Pipeline v1r78 GlastRelease: GlastRelease-15r47p12gr06 - There are a few changes in this GR wrt the version in use in L1, GR v15r47p12 (mostly implemented to get ready for RHEL4): - There are a few changes in the system tests wrt GR v15r47p12. These changes arose from a change in seed handling in GlastSvc to switch from an event to run seed for MC generation. dataMonitoring/AlarmsCfg: AlarmsCfg-05-20-02 svac/TestReport: TestReport-10-01-00 Complete set of tags for L1Proc 1.75Code VersionsGlastRelease (sim/recon): GlastRelease-v15r47p12gr06*ScienceTools (Level 2) : v9r15p3gl2Science Ops (task defs, scripts):Level 1 pipeline code and applications running in L1:svac/L1Pipeline: L1Pipeline v1r78* calibTkrUtil v2r7p3 dataMonitoring/AlarmsCfg: AlarmsCfg-05-20-01* dataMonitoring/Common: Common-06-01-01 svac/Monitor: Monitor-01-03-03 users/richard/pipelineDatasets: v0r6 ft2Util: v1r2p31 evtClassDefs v0r14 GPLtools: fileOps3
Request to update alarm settings in L1Proc 1.77
Reason for changeThe new version (AlarmsCfg-05-20-01, as opposed to AlarmsCfg-05-19-04) includes some limits to take into account the noisy channel 2414, and the unexpected reboot to FSW 2.0.2, after to EPU0 reboot. Test ProcedureWe have processed monitoring products from real on-orbit data (LPA) locally with this version of AlarmsCfg. Rollback procedureThe package can be rolled back to the previous version by flipping a soft link. Also note that the package is completely independent from any other package running in the pipeline and will not cause a version change of L1Proc. CCB JiraDetails (release notes for dataMonitoring/AlarmCfg for AlarmsCfg-05-20-01)AlarmsCfg-05-20-01 02-Oct-2009 bregeon Add temporary alarms because of noisy cal channel 2414
AlarmsCfg-05-20-00 30-Sep-2009 lbaldini Added alarms on the CAL hitmaps.
AlarmsCfg-05-19-05 28-Sep-2009 lbaldini Minor limit change for ACD tile 73.
AlarmsCfg-05-19-04 24-Sep-2009 monzani added two checks to verify
Request to deploy L1Proc 1.77
Reason for changeWe are adding a number of new monitoring tags (mostly, to monitor the distance to the SAA). Test ProcedureWe have processed runs in the DEV pipeline with this version of L1Proc. Rollback procedureWe can easily switch back to the previous version of L1Proc. CCB JiraDetailsL1Pipeline: L1Pipeline v1r77 GPLtools: fileOps3 dataMonitoring/AlarmsCfg: AlarmsCfg-05-19-05 dataMonitoring/FastMonCfg: FastMonCfg-02-00-01 dataMonitoring/Common: Common-06-01-01 dataMonitoring/FastMon: FastMon-05-01-00 svac/Monitor: Monitor-01-03-03 dataMonitoring/DigiReconCalMeritCfg: DigiReconCalMeritCfg-01-04-03 svac/TestReport: TestReport-10-01-00 Complete set of tags for L1Proc 1.75Code VersionsGlastRelease (sim/recon): v15r47p12ScienceTools (Level 2) : v9r15p3gl2Science Ops (task defs, scripts):Level 1 pipeline code and applications running in L1:svac/L1Pipeline: L1Pipeline v1r77* calibTkrUtil v2r7p3 dataMonitoring/AlarmsCfg: AlarmsCfg-05-19-05* dataMonitoring/Common: Common-06-01-01* svac/Monitor: Monitor-01-03-03* users/richard/pipelineDatasets: v0r6 ft2Util: v1r2p31 evtClassDefs v0r14 GPLtools: fileOps3*
Request to update alarm settings in L1Proc 1.76
Reason for changeThe new version (AlarmsCfg-05-19-04, as opposed to AlarmsCfg-05-18-04) includes some limit changes to accommodate the fact that in the B2-1-0 version of the flight software all the events are compressed. Test ProcedureWe have processed monitoring products from real on-orbit data (LPA) locally with this version of AlarmsCfg. Rollback procedureThe package can be rolled back to the previous version by flipping a soft link. Also note that the package is completely independent from any other package running in the pipeline and will not cause a version change of L1Proc. CCB JiraDetails (release notes for dataMonitoring/AlarmCfg for AlarmsCfg-05-19-04)AlarmsCfg-05-19-04 24-Sep-2009 monzani added two checks to verify
AlarmsCfg-05-19-02 22-Sep-2009 lbaldini Minor change to protect against a bug in the alarm handler
AlarmsCfg-05-19-01 22-Sep-2009 lbaldini Minor change in one digi trend alarm.
AlarmsCfg-05-19-00 21-Sep-2009 lbaldini Digi trend limits updated for flight software B2-1-0
Request to Deploy ASP v3r0p3
Reasons for Change
Test ProcedureTested in dev on data in /ASP/TestSims2 and on relevant L1Proc datasets in prod Rollback ProcedureRevert to ASP v2r12p1 and ST v9r11. CCB JiraDetails
Request to deploy L1Proc 1.75
Reason for changeThis is the L1 that we will use for the public data release. Because of an issue - still not understood - with CalCfpEnergy and Root 5.20 in Glast Release, we have decided to stick with Root 5.18 for the moment. This means that we had to take Science Tools v9r15p3 - which we need and which is compiled against Root 5.20 because of important bug fixes to TMinuit2 - and compile it against Root 5.18.00c-gl1. This has become ST v9r15p3gl2. The reason Science Tools and Glast Release are connected in such a way for L1 is because of ft2Util that links against both ST and GR (it reads in digi and merit files and writes out FT2 files). We have gone through the dependencies to make sure that nothing L1 uses from ST uses TMinuit2 (i.e. would need the bug fixes in Root 5.20) so ST v9r15p3gl2 should be safe to use for L1. Test ProcedureWe have processed run 271088335 in the DEV pipeline with this version of L1Proc and compared it to the original L1 processing. The files are: root://glast-test-rdr.slac.stanford.edu//glast/Data/Flight/Level1/LPA/dev/1.75/ft1/gll_ph_r0271088335_v003.fit We have validated the data in the following ways: - CalCfpEnergy, beyond the Root 5.20 issue, also seems to produce slightly different results depending on the computer architecture. The SLAC batch farm contains several different ones, in particular rhel3 and rhel4-64, in addition to Intel and AMD. A run is always split into hundreds of pieces that randomly run on all of these different machines. This makes an event-by-event comparison more difficult. It also occasionally changes the number of events in the FT1 file. In this case the number of events in the FT1 file decreased from 36685 to 36682 from the original processing to the new one. - I have verified for the test run that all FT1 columns except for ENERGY are identical between the two processings. For the ENERGY column, I see 49 events with a difference. All but two are tiny, <<1%. While two changes are at the 10% and 20% level. Neither of the two were Diffuse photons. This is consistent with changes previously seen with different computer architectures. - Note that the CalCfpEnergy issue that has just been discovered is not understood at all and all comparisons should be seen in that light. It's clear that all data processed with the current GR (v15r47p12) - which we are not updating in the L1 release - suffers from this feature. And it's not clear when it was first introduced. Also note that this CalCfpEnergy issue seems to predominantly affect background events. When there is a change for Diffuse photons it's at the level of 10^-6 relative energy variation. This probably indicates that the problem is related to unstable/sensitive fits and background events. But that is just a guess. - We have verified that FT1 EVENT_CLASS in the new processing is identical to FT1 CTBCLASSLEVEL in the original processing. - We have verified through spot checks that the new FT1 Diffuse response columns are the same as the ones in Benoit's 11 months sample. Columns DIFRSP0 and DIFRSP1 in our FT1 files are the same as DIFRSP0 and DIFRSP2 in Benoit's file (there are tiny numerical differences between DIFRSP1 and DIFRPS2 - presumably round off errors). For this comparison we needed an older run and used run 263204954. The reprocessed FT1 file is here: root://glast-test-rdr.slac.stanford.edu//glast/Data/Flight/Level1/LPA/dev/1.75/ft1/gll_ph_r0263204954_v001.fit. Benoit's file was /nfs/farm/g/glast/u33/lott/11month_dataset/ft1_may_rock43.fits. - We have verified that the following columns are identical in the two FT2 files: START,STOP,LAT_GEO,LON_GEO,RAD_GEO,RA_ZENITH,DEC_ZENITH,B_MCILWAIN,L_MCILWAIN, GEOMAG_LAT,RA_SCZ,DEC_SCZ,RA_SCX,DEC_SCX,LAT_MODE,LIVETIME,QSJ_1,QSJ_2,QSJ_3,QSJ_4. The SC_POSITION column has to be expanded and is not covered by the diff script. I made a few spot checks. No changes. - We have verified that the following new FT2 columns are present:: RA_NPOLE, DEC_NPOLE, ROCK_ANGLE, LAT_CONFIG, DATA_QUAL - We have done spot checks to verify the consistency between LS1 and the original Merit ntuple. Rollback procedureWe could switch back to the previous version of L1Proc. In that case we would have to turn off exporting files to the FSSC and switch to a mode where we do continous reprocessing for the FSSC files. Note that the current L1 pipeline uses the same Glast Release as this new one. CCB JiraDetailsL1Pipeline v1r75: scienceTools: v9r15p3gl2 evtClassDef: v0r14p00 ft2Util: v1r2p31 Complete set of tags for L1Proc 1.75Code VersionsGlastRelease (sim/recon): v15r47p12ScienceTools (Level 2) : v9r15p3gl2*Science Ops (task defs, scripts):Level 1 pipeline code and applications running in L1:svac/L1Pipeline: v1r75* calibTkrUtil v2r7p3 dataMonitoring/AlarmsCfg: v5r17p4 dataMonitoring/Common: v6r0p0 svac/Monitor: v1r2p37 users/richard/pipelineDatasets: v0r6 ft2Util: v1r2p31* evtClassDefs v0r14* GPLtools: fileOps1
Request to deploy ASPDataViewer web application version 3.4
Reason for changeThe database tables have been modified to allow users to associate:
The changes to the tables AND the web applications are backward compatible and transparent to the user. Test ProcedureThis version has been tested on the DEV server. Rollback procedureVersion 3.3 could be reinstalled CCB Jira
Request to update alarm settings in L1Proc 1.73 (round 7)
Reason for changeThe new version (v5r18p3, as opposed to v5r18p2) includes some minor limit changes to protect a few alarms when the statistics is not enough. Test ProcedureWe have processed monitoring products from real on-orbit data (LPA) locally with this version of AlarmsCfg. Rollback procedureThe package can be rolled back to the previous version by flipping a soft link. Also note that the package is completely independent from any other package running in the pipeline and will not cause a version change of L1Proc. CCB JiraDetails (release notes for dataMonitoring/AlarmCfg for v5r18p3)v5r18p3
Request to update alarm settings in L1Proc 1.73 (round 6)
Reason for changeThe new version (v5r18p2, as opposed to v5r17p4) includes some minor limit changes to protect a few alarms when the statistics is not enough. Test ProcedureWe have processed monitoring products from real on-orbit data (LPA) locally with this version of AlarmsCfg. Rollback procedureThe package can be rolled back to the previous version by flipping a soft link. Also note that the package is completely independent from any other package running in the pipeline and will not cause a version change of L1Proc. CCB JiraDetails (release notes for dataMonitoring/AlarmCfg for v5r18p2)v5r18p2
v5r18p1
v5r18p0
Request to deploy L1Proc 1.74
Reason for changeThis new GR, v15r47p12, contains an improved error message in case of event errors and also removes an incorrect warning, repeated 160 times per event, in case we have data with TEM diagnostics. Most importantly, it fixes a bug with the ldfReader which prevented the TEM diagnostic from being interpreted correctly. We anticipate that taking data with the TEM diagnostics will be the new default running mode when the new FSW B2-1-0 is uploaded and activated. There is no change to any functionality in this GlastRelease. We have also added a few new monitoring quantities related to event sizes at Eric Siskind's request, plus a new variable that monitors the distance from the SAA. Finally, we are getting rid of the chunk-based host list (it didn't obviously help but produced a lot of trouble when some configuration changes were applied to LFS). Test ProcedureWe have processed data runs in the DEV pipeline with this version of L1Proc. Rollback procedureWe can switch back to the previous version of L1Proc. CCB JiraDetailsL1Pipeline v1r74: GlastRelease v15r47p12: - There are no changes in the system tests wrt GR v15r47p7. svac/TestReport: v9r2 dataMonitoring/DigiReconCalMeritCfg: v1r4p1 dataMonitoring/FastMonCfg: v2r0p0
Complete set of tags for L1Proc 1.74Code VersionsGlastRelease (sim/recon): v15r47p12*ScienceTools (Level 2) : v9r8p2Science Ops (task defs, scripts):Level 1 pipeline code and applications running in L1:svac/L1Pipeline: v1r74* calibTkrUtil v2r7p3 dataMonitoring/AlarmsCfg: v5r17p4 dataMonitoring/DigiReconCalMeritCfg: v1r4p1* dataMonitoring/Common: v6r0p0* svac/Monitor: v1r2p37 users/richard/pipelineDatasets: v0r6 ft2Util: v1r2p23 evtClassDefs v0r6 GPLtools: fileOps1
Request to update alarm settings in L1Proc 1.73 (round 5)
Reason for changeThe new version (v5r17p4, as opposed to v5r16p2) introduces a few minor limit changes and protections against low statistics detailed below. Test ProcedureWe have processed monitoring products from real on-orbit data (LPA) locally with this version of AlarmsCfg. Rollback procedureThe package can be rolled back to the previous version by flipping a soft link. Also note that the package is completely independent from any other package running in the pipeline and will not cause a version change of L1Proc. CCB JiraDetails (release notes for dataMonitoring/AlarmCfg for v5r17p4)v5r17p4
v5r17p3
v5r17p2
v5r17p1
v5r17p0
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||
