The new labels idea sounds good to me. We just need to associate a pfsDesignId with a particular arrangement of fibers.

        self.add("blue", next(hexIt), "LAM blue cable", [32, 111, 223, 289, 418, 518, 620])
        self.add("green", next(hexIt), "LAM green cable", [63, 192, 255, 401, 464, 525, 587])
        self.add("orange", next(hexIt), "LAM orange cable", [12, 60, 110, 161, 210, 259, 341])
        self.add("red1", next(hexIt), "LAM red #1 cable", [2])
        self.add("red2", next(hexIt), "LAM red #2 cable", [3])
        self.add("red3", next(hexIt), "LAM red #3 cable", [308])
        self.add("red4", next(hexIt), "LAM red #4 cable", [339])
        self.add("red5", next(hexIt), "LAM red #5 cable", [340])
        self.add("red6", next(hexIt), "LAM red #6 cable", [342])
        self.add("red7", next(hexIt), "LAM red #7 cable", [649])
        self.add("red8", next(hexIt), "LAM red #8 cable", [650])
        self.add("yellow", next(hexIt), "LAM yellow cable", [347, 400, 449, 466, 545, 593, 641])

dcb has 12 genuine bundles.
fmadec how many "new bundle" would be required for dcb2 ?

The red single fiber are identical as green and orange bundle

so yellow and blue bundles have some difference between DC1 and DCB2

see https://sumire.pbworks.com/w/file/fetch/144177297/DCB2_Mapping_Report_20210505.pdf

during the last telecon, you propose to have the same bundle names but  according to switch cable is used the corresponding fiberIds change, right?

so makeDummyCable be could also handle this by adding on option to select which DCB cable is used :

for ex: makeDummyCable "yellow" dcb=dcb2 or smthg like that

we also pointed out that there is a keyword that defines which DCB or source is used so we will know which DCB was used in anycase

Thanks, so two additional bundles.
Right, but I was thinking to handle that at the actor level, the user declare "yellow, blue, red1, red4, red8". which dcb2Actor convert to yellow2, blue2, red1, red4, red8.
So dcb and dcb2 does not generate the same pfsDesignId.

there are 12 genuine dcb bundles, +2 dcb2 bundles out of maximum 16 values with the current design.
But , there are those non-dcb design which are also tracked there

self.add("engineering", next(hexIt), "Engineering", engineering)
self.add("9mtp", next(hexIt), "Right science fibers", [ff for ff in science if ff < 273])
self.add("12mtpS12", next(hexIt), "Left science fibers", [ff for ff in science if ff > 273])
self.add("12mtpS34", next(hexIt), "Left science fibers without some",

It was a nice workaround at that time, but I'm not sure that's the right way.
I don't think "engineering" is actually relevant, since it's alway connected, different fiber...
And about allFiberLamp, we could mimic what was done with SuNSS:

if lightSource == 'sunss':
    designId = 0xdeadbeef

cloomis opinions ?

agree for engineering fiber, we should clarify that

for allfiber we still need to define either 9mtp or 12mtpS12 or 12mtpS34 (we may even change those names since we know now all Slit have 600 fibers except one

Right, and since we cannot declare per-gang lightSource, it would have to be :

sps declareLightSource sm1=afl9mtp
sps declareLightSource sm1=afl12mtp 

I wonder about that (S12, S34), since it's actually a property of cable A not cable B.

euh, right maybe for pfsDesign

but we need a way to define correclty pfsConfig

we need to define which fiber is illuminated so need to define that, but initially it was S12 and S34 because sm 1 and 2 was supposed to have 600 fibers while 3 and 4 597fibers

we know now that FCA4 has 597 fibers (is installed on SM2)