New get posmoves with fvc

[julienguy]

• add new script get_posmoves_with_fvc_data that starts from fvc fits images, process them, and match to posmove db entries using OBSNUM,OBSFRM keyword in the image headers and exposure_id,exposure_iter in the posmove DB. Example

  get_posmoves_with_fvc_data --host beyonce.lbl.gov --port 5432 --password reader --petal-id 1 --fvc-images /global/cfs/cdirs/desi/engineering/focalplane/archive/desisti/data/images/fvc/fvc.0000217*.fits --exposure-ids 2171 --recent-rehome 2171 --fvc-proc-options ' --no-zbfit'

  • add desi_fit_fvc2fp_using_posparams which refits the fvc2fp transform by comparing the positioner calibration parameters OFFSET_X,Y with metrology of positioner holes.
  • add a metrology patch obtained with script update_focal_plane_metrology_patch to adjust the FIF and GIF metrology based on the average coordinate residuals from a sequence of fvc images.
  • update transform,patch and metrology using all of this and the data from the calibration exposure 2171.

At the end of all of this, here is the comparison between the metrology and the values of OFFSET_X,Y after transforming them from the "flat" to the cartesian coordinate system.

[joesilber]

I generally like this, and agree with the need to refit the petal location. I have two questions:

1. One thing I don't understand is why we use the POSPARAMS offset x, y here. Isn't this circular logic? because a bad previous petal location --> bad offset x, y --> bad new petal location. I would think we should be using the CMM metrology data, which is our best independent knowledge.

2. What is the frequency at which desi_fit_fvc2fp_using_posparams will be called in practice? Is it automatically triggered? If manually triggered, what guarantees do we have that it will be done properly forever into the future?

[julienguy]

• "One thing I don't understand is why we use the POSPARAMS offset x, y here."

Offset x, y are the best measure we have of the positioner centers. In the fit, I use the inverse default transformation to compute their default FVC pixel coordinates (essentially undoing the transfo), and I refit the full transformation.

• "What is the frequency at which desi_fit_fvc2fp_using_posparams will be called in practice?"

Only once per hardware configuration in principle. For instance, here we had to redo it after we turned on all of the fiducials on petal 1 and got better coordinate transformation fits. I don't expect to rerun it on petal 1.

[joesilber]

* "One thing I don't understand is why we use the POSPARAMS offset x, y here."

Offset x, y are the best measure we have of the positioner centers. In the fit, I use the inverse default transformation to compute their default FVC pixel coordinates (essentially undoing the transfo), and I refit the full transformation.

• Do you do this for every FVC measurement?
• Are you fitting these to the metrology locations?

The issue I am trying to understand is that the physical location of the petal boundaries matters a great deal to anticollision. We must have accurate position + alignment knowledge of the petal for this to work, so that PTL_X, Y, Z will match correctly with the true boundaries of the petal. This requires that the 6 transformation values are known properly to the online system, in the constants database. And desimeter must work smoothly with these.

C.f.: http://beyonce.lbl.gov:8080/ConstantsDB/app/Elements/show?name=1&version=46566

These values, when applied to whatever desimeter reports as OBS_X, Y (or X_FP, Y_FP as desimeter calls them) must produce PTL_X, Y, Z which are truly in the petal coordinate system.

So the statement "Offset x, y are the best measure we have of the positioner centers" is what I want to understand. The best measure in some global system? Sure. But anticollision also needs the petal coordinates to be correct.

* "What is the frequency at which desi_fit_fvc2fp_using_posparams will be called in practice?"

Only once per hardware configuration in principle. For instance, here we had to redo it after we turned on all of the fiducials on petal 1 and got better coordinate transformation fits. I don't expect to rerun it on petal 1.

What about when someone bumps the camera in 6040? We probably won't know it happened, but now we'd be misaligned, right? I think I'm probably just confused about the sequence here, but I thought we would need to do this any time we want to calibrate OFFSET_X, Y (which could be every single recorded move...)

[julienguy]

• for every FVC image, only a subset of the transformation are fit: shift, rotation, magnification using only the fiducials pixel coordinates and their expected FP coordinates.
• but the higher order distortion terms also have to be fit. they are fit only when needed. and for that we use the fitted positioner centers OFFSET_X,Y (with the proper flat to cartesian transform) and compare them to the position hole metrology.
• a recent change: optionnally, the fiducials coordinates are altered oto make them agree with the positioner holes metrology.
• the transform from petal PTL to focal plane FP is a rigid rotation and translation which parameters are pull from the constants DB and written to disk in the yaml file petal-alignments.yaml using the script load_petal_alignments_from_db. If we ever decide to use desimeter for operations at KPNO, we will need to automate this.

[joesilber]

Ok, thanks. I am approving.

As we discussed, it is important to highlight your point that "If we ever decide to use desimeter for operations at KPNO, we will need to automate" the connection between constants DB and petal-alignments.yaml.

I added a new issue #100 related to this, to keep track of it.