From email discussion with Rogers and Martyniak, the table will support

for each absorber:
        name (string)
        material (string)
        shape (string)
        comments (string)

We expect 3 absorbers in Cooling Demo

Where:

      absorber name (string) -- e.g. Primary, Secondary, Secondary2, etc
      absorber material (string)-- e.g. LH2, LiH, Plastic
      absorber shape (string) -- e.g. Full, empty, disk, wedge, etc
      comments -- e.g. filling, etc

• For the getter API, we want:
  • get_coolingchannel_absorber_for_run(RUN#)
  • get_coolingchannel_absorber_for_date(date)

• For setting:
  • Need C-API so that Pierrick can set it from RC
  • Keep it within the CoolingChannel service, but implement separate function call
    • so for e.g. from RC, Pierrick would do coolingChannel.set_absorbers(run, abs_struct)
      • where abs_struct would be a structure containing the absorber attributes for each absorber

• Do we need to store information about pressure in the interspace around the absorber?
  • Pierrick -- do you have access to this information from EPICS?
  • Chris -- is this important/needed/useful for analyses?

• Do we need to store information about pressure in the interspace around the absorber?

In normal operation the interspace(s) is supposed to be evacuated. I was assuming a very simple record with e.g. interspace (string) set to "Vacuum", unless the pumps go wrong and beyond some threshold it changes to "Air".

Though on reflection, one could argue that the correct mechanism for warning about this is by including a set of InterspaceVacuumIsGood flags into the Data Quality Flags.

We'd like to finalize this so that Janusz can create the table and APIs for Pierrick to test.

Chris -- can you comment please?

• absorber temperature (for LH2)
• absorber pressure (for LH2)
• interspace status (vac/air)

Note that one will be able to retrieve these from the archiver as well once Pierrick puts them in there.

Chris Rogers confirms that we want the temperature and pressure. This will be meaningful only for LH2, but doesn't matter from the table point of view.

So, the table would like so:

• For a given run number, there will be up to 3 absorbers -- names: Primary/Secondary1/Secondary2. The names must be strict.
• The material name string must be strict
• The primary key would be Run + Name
• An ID (int, auto-increment) may be needed for DB maintenance bureaucracy

Pierrick -- can you check to make sure that you will be able to write the LH2 Temperature & Pressure?

Pierrick confirms that

• we will have a temperature reading of the LH2 bath
• we will have a pressure readback
• we will have a level reading of the LH2 indicating the quadrant the level is at.
  • This will go into the shape field

So, the table implementation can proceed with the definition in update#5