Create more structured parameter mapping for alignment workflow

[tomeichlersmith]

The whitespace-separated text files do not have all of the information I would like to derive from a parameter mapping (for example, I'd love to separate axial/stereo without having to do a string-based search).

I'm imagining a JSON file that dumps more information than necessary. I'm thinking each parameter would be a dictionary and then the dictionary could have a few helpful entries

{
  "id" : "<millepede id number>",

  "short_sensor_name" : "<short name consisting of characters representing the sensor e.g. 'TL3A'>",
  "long_sensor_name" : "<long name consisting of words representing the sensor e.g. 'top layer 3 axial'>",
  "ax_st" : "1 for axial, 2 for stereo",
  "half" : "1 for top, 2 for bottom",
  "layer" : "HPS layer number",
  "h_s" : "0 for front, 1 for hole, 2 for slot",
  "f_b" : "1 for front, 2 for back",

  "t_r" : "1 for translation, 2 for rotation",
  "uvw" : "1 for u, 2 for v, 3 for w",
  "move_name" : "<short name for movement e.g. 'tu'>"
}

We could even go further and add more structure to this map to avoid repetition. We could define a "sensor" to be

{
  "short_sensor_name" : "<short name consisting of characters representing the sensor e.g. 'TL3A'>",
  "long_sensor_name" : "<long name consisting of words representing the sensor e.g. 'top layer 3 axial'>",
  "ax_st" : "1 for axial, 2 for stereo",
  "half" : "1 for top, 2 for bottom",
  "layer" : "HPS layer number",
  "h_s" : "0 for front, 1 for hole, 2 for slot",
  "f_b" : "1 for front, 2 for back"
}

And a "movement" to be

{
  "t_r" : "1 for translation, 2 for rotation",
  "uvw" : "1 for u, 2 for v, 3 for w",
  "move_name" : "<short name for movement e.g. 'tu'>"
}

And then each millepede parameter would be

{
  "id" : "<millepede id number>",
  "sensor" : "<short_sensor_name>",
  "movement" : "<move_name>"
}

[JeremyMcCormick]

Hi, @tomeichlersmith.

Even without knowing much of the details on the alignment procedures, I am wondering whether some or most of this information should live in hps-java rather than hps-mc?

It doesn't feel like the right place to me for these kinds of parameters.

[tomeichlersmith]

The reason I would put it here rather that in hps-java is because it would be used by the alignment components here. hps-java handles the parameter name <-> sensor/movement translation by using the calibrations database and a more detailed sensor mapping constructed from the detector description.

Here, we do not have access to the sensor mapping directly so it is easier to just store these files and read them in.

[JeremyMcCormick]

The reason I would put it here rather that in hps-java is because it would be used by the alignment components here. hps-java handles the parameter name <-> sensor/movement translation by using the calibrations database and a more detailed sensor mapping constructed from the detector description.

Here, we do not have access to the sensor mapping directly so it is easier to just store these files and read them in.

If you need heavy access to conditions, calibrations, detector data, etc. then hps-java is the logical place to write that code instead of within hps-mc where you don't have direct access to this information.

Would that be possible and feasible?

I don't know the exact details of what you're doing with this, but it just doesn't look quite right to me to put all this stuff into hps-mc.

[tomeichlersmith]

This is hepful to have outside of hps-java because we need this information for two key alignment tasks:

1. Plotting
2. Choosing which parameters to float

While (1) could feasibly be done within hps-java, I refuse to do so out of principle¹ since the core plotting scripts have already been written in Python.

(2) cannot be done in hps-java. It needs to be done manually by the aligner after looking at plots (or following a predetermined alignment plan). Having the human-readable form of the parameters accessible at this stage makes the choice a lot less error-prone.

Footnotes

1. This is a sassy way to make a very real point. No-one working on alignment wants to spend more time on it than necessary, so re-writing all of our plotting/fitting functions in some other language would incur a lot of extra work that no-one wishes to take on. ↩