The main problem appears to be a bad flat field with a large variance set.  However, we'll need to tune params.  I am running with

config.interp.modelPsf.defaultFwhm = 3
config.cosmicray.nCrPixelMax = 5000000 

(the second line isn't new)

We don't have flats for SuNSS data.

The problem was that you did make flats for CALIB-price, and they had a variance plane set.

They were there from a previous experiment. This is an example of why I think it's important everyone is careful about what calibs they use.

I agree that people have to be careful, but I think that that having an an official certified CALIB that we can all use is the way to do that. I was not happy to be told, "use CALIB-price" but it's the current workflow.
We can revisit how we do this in a month when the new calibration production tooling is in place.

Pushed CR params tuned for SuNSS

This may break the simulator when merged to master, and we need to think about how to do this. price

The weekly unfortunately did break following the change to the obs_pfs repo. This has been investigated and it turns out to be a problem in fibre identification, where fiber 480 is identified in both visits 35 and 37, and means that the fiberIds for these visits were not actually disjoint prior to being combined. Fiber 480 should not appear in visit 35 in accordance to the pfsConfig for that visit, and inspecting the corresponding calExp, is clearly a misidentification.

This has now been investigated and fixed by price in the PIPE2D-725 ticket branch of drp_stella https://github.com/Subaru-PFS/drp_stella/commit/b39b96e2520f9c4d9beaab1810e44d58b1e897b5 .

The weekly build now completes successfully.

Does this mean that you're allowing the slit offsets to float in the weekly?

The detectorMap was good enough in this instance. The problem is more to do with finding the traces following a cosmic ray hit. Perhaps price can elaborate better.

That's the point.  If you tell the code to believe the traces, does it work?  There are options for more general solutions, but we should never need to run them on real data.

The problem was not related to the detectorMap. We could change the code to use the detectorMap centers in constructing the profile, which would make that more robust in the steady state, but constructFiberTrace runs before reduceArc, so we can't always assume we have a perfect detectorMap.

I'm confused.  If we use the detectorMap how can we mis-identify fibres?

And while I understand the bootstrap problem, in the vast majority of cases we will have a good DetectorMap, the only exception being when we first bring a new detector online (or go from DCB to SuNSS or the PFI), and that's when we need to override trusting the DetectorMap.

Currently, the detectorMap is only used for seeding the positions, and trace centroids are coming from the image.

And it could be that we were running with blind find.

Let's see if turning off blind find solves the problem, it should.  Even blind find shouldn't be running fibre-by-fibre, but that's probably not worth fixing as using it is going to be very unusual.  I have no problem in tweaking the centres, but identifying fibres is something that the detectorMap can do reliably.

As mentioned during the internal Princeton group discussion on 2021-03-15: disabling the blind find does result in the weekly passing successfully.

As proposed and agreed during that discussion: I will commit the configuration changes in obs_pfs made by RHL and myself, and Paul's changes to drp_stella to make finding fibers more robust when blind find is enabled.

Merged changes in obs_pfs and {drp_stella}} to master (commits a7647e3 and 34406d3 respectively).