- genevb's home page
- Posts
- 2024
- 2023
- 2022
- September (1)
- 2021
- 2020
- 2019
- 2018
- 2017
- December (1)
- October (3)
- September (1)
- August (1)
- July (2)
- June (2)
- April (2)
- March (2)
- February (1)
- 2016
- November (2)
- September (1)
- August (2)
- July (1)
- June (2)
- May (2)
- April (1)
- March (5)
- February (2)
- January (1)
- 2015
- December (1)
- October (1)
- September (2)
- June (1)
- May (2)
- April (2)
- March (3)
- February (1)
- January (3)
- 2014
- 2013
- 2012
- 2011
- January (3)
- 2010
- February (4)
- 2009
- 2008
- 2005
- October (1)
- My blog
- Post new blog entry
- All blogs
New offline database table: beamOrbitInfo
Updated on Fri, 2016-06-03 13:59. Originally created by genevb on 2016-06-03 13:27.
New offline database table: beamOrbitInfo
Database: RunLog_onl
JUSTIFICATION:
Offline calibrations frequently make use of beam information from the collider. Much of this information is already available in the RunLog_onl/beamInfo table in the offline database, such as beam species, energy, and intensity. That table is already well-aligned with an online database table for migration to offline.
Now, offline calibrations have expanded their needs for information about the beams. Specifically at the time of this writing:
REQUIREMENTS:
Data fields:
All desired fields are available for migration from the online database mq_collector_Conditions_cdev (accessible currently at mq02.starp:3606, for example). Here is a mapping of the desired offline table fields with the online table fields that use the CDEV structure field names (as documented in starPortalClient.ddl):
Entry frequency:
While the online table is populated every 150 seconds from CDEV, that is overkill for the offline database. The more appropriate entry frequency is once per run, as is already done with the beamInfo table. There is the possibility that migrating the data from the online table to offline might miss a change in status between offline entries (such as multiple beam position steps during a run, occurring now with the offset beams used to reduce luminosity without reducing intensity), but this is not considered critical at this time.
Database: RunLog_onl
JUSTIFICATION:
Offline calibrations frequently make use of beam information from the collider. Much of this information is already available in the RunLog_onl/beamInfo table in the offline database, such as beam species, energy, and intensity. That table is already well-aligned with an online database table for migration to offline.
Now, offline calibrations have expanded their needs for information about the beams. Specifically at the time of this writing:
- TPC SpaceCharge & GridLeak calibration: at high luminosities, a more accurate metric of the collision rates is needed than encoded in the RICH coincidence scalers. The formulas are known and calculable, but require knowing the number of colliding RHIC beam bunches at STAR.
- BeamLine calibration: a better understanding of systematic beam position shifts is gained by correlating results determined by STAR with data from the collider's beam position monitors.
REQUIREMENTS:
Data fields:
All desired fields are available for migration from the online database mq_collector_Conditions_cdev (accessible currently at mq02.starp:3606, for example). Here is a mapping of the desired offline table fields with the online table fields that use the CDEV structure field names (as documented in starPortalClient.ddl):
offline table field | online table / CDEV field |
---|---|
blue_beamPos5_horizontal blue_beamPos5_vertical yellow_beamPos5_horizontal yellow_beamPos5_vertical blue_beamPos6_horizontal blue_beamPos6_vertical yellow_beamPos6_horizontal yellow_beamPos6_vertical blue_filledBuckets yellow_filledBuckets |
rbpm.b-g5-bhx.avgOrbPositionM rbpm.b-g5-bvx.avgOrbPositionM rbpm.y-g5-bhx.avgOrbPositionM rbpm.y-g5-bvx.avgOrbPositionM rbpm.b-g6-bhx.avgOrbPositionM rbpm.b-g6-bvx.avgOrbPositionM rbpm.y-g6-bhx.avgOrbPositionM rbpm.y-g6-bvx.avgOrbPositionM buckets.blue.filledBucketsS buckets.yellow.filledBucketsS |
Entry frequency:
While the online table is populated every 150 seconds from CDEV, that is overkill for the offline database. The more appropriate entry frequency is once per run, as is already done with the beamInfo table. There is the possibility that migrating the data from the online table to offline might miss a change in status between offline entries (such as multiple beam position steps during a run, occurring now with the offset beams used to reduce luminosity without reducing intensity), but this is not considered critical at this time.
»
- genevb's blog
- Login or register to post comments