Instructions for Loading Conditions

Procedure

There is a bit of bureaucracy that you need to go through if you want to load new or updated conditions. This is necessary because this is a critical operation which, if something goes wrong, could effect all levels of production (calibrations, reconstruction, skimming and analysis) and mistakes are not often immediately obvious. We therefore must be very careful about what gets loaded and will ask you lots of questions, so please be patient with us.

Here is a list of things to do with more explanation below:

Get approval in IR2ProdMtg-hn. Your posting should describe what you want to do, why and what effect it will have. This gives sub-systems experts or others a chance to voice any concerns. You should wait for approval from the computing management before proceeding. Also keep in mind that every time constants are loaded an approval is needed.

Loading constants to IR2

Fill out the conditions loading request form. You need to fill out this web based form to provide the more technical details needed for the loading.

Request to Load constants

This form will automatically post your request to condmgmt-hn (but this might not be working right now so please check and post it yourself if needed...), and someone will contact you for clarification and to schedule the loading operation.

Load the conditions.
!!! Please use only Solaris releases to load constants to a conditions federation (see below). !!!

At the appointed time you will need to coordinate through condmgmt-hn with the production team. Instructions for loading to the MASTER are in:
Loading Constants into MASTER CDB
As mentioned earlier, loading constants to IR2 needs the approval from a run coordinator. The coordinator will also schedule an appropriate time to do the loading (don't forget loading to IR2 might interfere with data taking). The instructions to load to IR2 are:
Loading Constants into IR2 CDB

Validate the effect of the new conditions. You are responsible to make sure that the new conditions you load have the desired effect. In the request form you should have explained the steps to validate the loaded constants, and work out a plan with the production team.

Bootfiles for the conditions federations:

Make sure you know the which CDB the constants have to be loaded and that you use the correct boot file.

Validity Period:

The validity period for new or updated constants is very important. When an application reads information from the conditions DB it always reads the latest information (this will not be the case once the state-id is utilized, but it is the case now). We therefore need to make sure that anything loaded to the CDB only effects data that has not been processed already (or data that is planned to be reprocessed). Therefore production, skimming, and analysis will always see the same conditions when looking into the CDB.

We require, except under unusual circumstances, that you load conditions with a starting validity time >= to the start time of the next run to be processed (which can be obtained from the production team).

The validity period used for testing is not important. You only want to ensure that it covers the range of runs you want to test. It might need to be limited because it would effect other on going tests, but this should be sorted out in IR2prod-hn.

Why use Solaris to write conditions

The Solaris platform must be used to load conditions, not Linux. Writing any Objectivity data using a binary built with gcc 3.x would prevent us from making any sweeps to cond14boot or ir2boot. Why? These federations are often accessed by older releases, that are unaware of gcc3 layout. Writing via binary built with gcc3.x would force data to be stored in the gcc3.x layout, making data look like corrupted to older releases (most pre-16 series).

Last modified: Fri Oct 22 16:30:31 PDT 2004