We have discussed this further and can specify things a bit better.

• sps_visit.exp_type is one of bias, dark, flat, arc, object, test. This is essential information, but is not sufficient to know whether a visit is suitable for any particular purpose. For example, it says nothing about how the lamps are configured.

• sps_sequence.sequence_type does show the purpose behind of a group of exposures, and IIC will set it to known fixed values which can drive reductions. The above values are a good start: masterBiases, masterDarks, ditheredFlats. Data with unrecognized values should be ignored by the calibration and science DRP machinery.

• We will have additional relevant sequence_type}}s. For instance something like {{fieldCalibs, with a flat and one or more arcs to be associated with a particular pfsConfig.

• sps_annotation.data_flag should be checked before using a file, and rows should be be added when bad data are uncovered. I believe that the lack of sps_annotation rows for a given (pfs_visit_id, sps_camera_id) indicates that the file is assumed to be OK.

From this, we need an IIC ticket to create the right sequence_type rows.

And besides this, INSTRM-1026 needs to be made more specific.

This sounds good to me.  Let me just confirm: sps_annotation.data_flag is 0 when the data is bad, correct?  It seems all the entries in the current sps_annotation table has data_flag=0.  If we are going to assume that the lack of entry means that the data is good, we may want to use flag=1 to indicate bad data?  We may even want to change the column name to something like flag_bad_data.

Masayuki Tanaka following discussions with cloomis fmadec and arnaud.lefur: a data_flag of 0 (zero) will indicate good data. Non-zero values indicate bad data.

So all the entries in the current sps_annotation table are good.

We all agree with keeping the current name of data_flag.

OK, I misunderstood the meaning of the flag - in an opDB copy at NAOJ, I see comments like 'just testing SW' and 'FPGA still wrong' in the sps_annotation table, and I naively interpreted the words like 'test' and 'wrong' as 'do not use'.  That is how I misunderstood the flag.  Anyhow, as long as we are clear about the meaning of the flag, we do not need to change anything here.

We call constructPfsBias.py with masterBiases,
constructPfsDark.py with masterDarks,
constructFiberFlat.py with ditheredFlats.

I have questions:

• What are the arguments for bootstrapDetectorMap.py's --flatId and --arcId ?

• What are FLAT_ODD and FLAT_EVEN for constructFiberTrace.py?

• With what should we call reduceArc.py? (Maybe ditheredArcs?)

implemented an currently running at Subaru.