I believe that this is currently not possible. I would be happy to be proven wrong.

The problems is that bootstrapDetectorMap.py requires pfsConfig file describing the 300 illuminated fibers. At the moment this can not be produced given that https://github.com/Subaru-PFS/drp_stella/blob/master/bin.src/makeLamDesign.py#L11-L30 does not recognize that possibility. We discussed this in slack channel - I am attaching a screenshot.

Would you agree with that assesment hassan and price?

That is correct. And I'm concerned that the definition of pfsDesignId we're using currently does not handle very well an expansion in the number of setups.

Might be worth asking how many more setups are possible. Besides swapping to the other gang connector I don't see many.

But I do not know whether there could be more at Subaru: the DCB hardware and software (or something very similar) will be installed there permanently. [So {{makeLamDesign.py}} should probably have been {{makeDcbDesign.py}}, sorry.]

Summary of insights of trying to work on this problem in September/October 2019.

A lot of confusion happened because it was not clear if the data taken at LAM contained both arc and flat data taken in the same setup. This is necessary to reduce the data. Confusion happened because the entries in the logbook (https://people.lam.fr/madec.fabrice/pfs/ait_logbook_SM1.html) were essentially wrong, given that they are using illuminating sphere and ``normal'' setup for this experiment.

Finally, I have been able to identify the list of exposure for which it is possible to conduct this experiment in the r-arm. All of this data is taken on August 1. Biases and darks are available from the data taken on July 25
Arcs (deuterium): 22106..22111
Flats: 22093..22098
Bias: 21077..21091
Darks: 21092..21121

Given the discussion in drp it seems that we are not able to find traces even in the simpler case of simulated data where only odd/even traces are illuminated. We will continue this ticket after the corresponding ticket (PIPE2D-391) is solved.

Looks like most of my problems are due to the CR finder. If you disable that (e.g., doRepair=False), then you might be all right.

Stealing this from ncaplar, so I can make fixes to the code so that this works.

ncaplar's previous efforts: https://gist.github.com/nevencaplar/3da094c5c784f752ffe4ae22c67f24dc

I think this was done in PIPE2D-472.