I may be missing something, but at present I think that the only way to update a DetectorMap is with reduceArc (I may be missing some bootstrap commands).  I think we need to generalise that to allow a combination of arcs and continuum exposures (quartz or moonlight), as especially in the blue we don't have enough lines to define the location of the traces very well.

As I've probably written in a different ticket, with a global distortion model, even featureless spectra probably define the spectral solutions pretty well, in a differential sense.  Obviously we'll use emission lines when we can.

Looking at the SuNSS data I'm seeing strange patterns in the x (but not y) residuals. I'm wondering if these are due to the continuum in some of the exposures coming from moonlight (or, for the diffuse fibres, possibly a bright object in the field). Upon setting reduceExposure.doSubtractContinuum=True to see if this was indeed the problem, I noticed that the sky subtraction wasn't very good for some of the exposures due to the location of the traces being wrong. This could/should be handled by updating the DetectorMap, but as we don't know the cadence on which this will be possible the availability of the low-order tweaks provided by this ticket will significantly improve the sky subtraction.
I do not yet know if the continuum is the source of the problems that I'm seeing.

While you're in the code, is there a reason why FitDifferentialDetectorMapTask.run takes four arguments unpacked from oldDetMap instead of the old DetectorMap itself? And it appears to want a VisitInfo purely for the sake of a random seed (is that right?).

And please add a _DefaultName to FitDifferentialDetectorMapTask and all other PFS tasks that don't have one.

See also PIPE2D-809

I've pushed a quick hack (no proper config etc.) to u/rhl/PIPE2D-796 

rhl I don't see anything in your branch that corresponds to the goal of this ticket. Are you wanting me to incorporate your work? Otherwise, I think you should put it on a separate ticket for review and merge.

Sorry, I take it back. I see something relevant in the commit labelled "Hack hack hack".

Paul asked me to add a note about exactly what I'm looking for in the related tickets PIPE2D-785, PIPE2D-796, and PIPE2D-809.

I'd like to use the global properties of the DetectorMap wherever possible, so whenever we need accurate positions of spectral features (in x and/or y) I'd like to see the workflow being:

1. tweak the DetectorMap if necessary 
2. use the DetectorMap as the truth.

In some cases this may require extra or repeated image processing (e.g. reduceExposure needs to run reduceArc to update the detector map, and possibly part of ConstructFiberProfilesTask too).

That's why I expected PIPE2D-785 to be part of the solution to the other two tickets, although I am not sure that it's worth going back and redoing the work at this point.

Because the DetectorMap is fundamentally about (x, y) the tweak code should be based on (x0, y0, x, y) rather than (x0, lambda0, x, lambda), which I believe to be the current API and one reason I didn't address this ticket myself. If we also include the errors in the positions (dx, dy) we should be able to use the same code to handle arcs (with small dx and small dy) and fibres (with large dy).

Finally ready for review; sorry about the delays.

Quite a few big changes, but changes look OK to me. No specific comments to address.

Merged.