HWP angle loading improvements

[Katie Harrington]

@mhasself I think this needs to be a small context hook or something but:

We need to work out how we want to get the solutions calculated by make-hwp-solutions into the top level of the AxisManger. I have the skeleton of make-hwp-solutions now running on the site system and I set up the context so the results get loaded into aman.hwp_solution. That sub axismanager includes hwp_angle_ver1 and hwp_angle_ver2. We need a way to pick one and to load that into aman.hwp_angle so it can be used in later code.

I think this is some post load hook that is configured to "take sub field X and move to top.Y" but I haven't thought more than that. I do have other examples (tod processing results) where I would like to take other loaded fields and move them around to new fields, so a solution more general than for hwp angles would be nice.

[Matthew Hasselfield]

Agreed. You can do the following for now; but I totally agree it should be easier to boost out fields without having to add a metadata entry.

metadata:
  ...
  - db: hwp.sqlite
    name: hwp_solution
  - db: hwp.sqlite
    name: hwp_angle&hwp_angle_ver1

[Matthew Hasselfield]

To discuss a bit more, I think there are two approaches:

1. Add general metadata rules for (re-)naming fields. e.g. something like

   - db: hwp.sqlite
     name: hwp_solution
     copy:
     - ['hwp_angle_ver1', 'hwp_angle']
     - ['hwp_flags', 'hwp_flags']]

2. An executable hook, perhaps apply_hwp_model, which knows to read the entries in hwp_solution and hwp_model, and maybe others, in order to compute and store hwp_angle; perhaps applying some complex transformation like removing the fixed hole pattern or the sag offset. This function wouldn't be run automatically on load, but it can be added to all scripts where it should be automatically computed. (This is the approach we're leaning towards for apply_pointing_model.)

I think both of these things need to happen; in the short term I think 1 will get us pretty far.