https://github.com/Subaru-PFS/ets_fiberalloc/blob/commissioning_demo/commissioning.py  is probably a very good starting point for the coming November run.

Minimum working modification is made (see gen_target_list_from_targetdb()).
https://github.com/Subaru-PFS/ets_target_database/blob/commissioning_2021nov/examples/commissioning_2021nov/commissioning.py

The script still needs to be reviewed and tested.

Martin Reineckepoints out that the pfsDesignId is calculated from the desired positions of the cobras, and that this isn't available until the last stage in the construction of the pfsDesign file (starting with boresight and rotation, adding the guide stars, and then finally the cobra positions). In consequence, he is forced to assign his own "pfsDesignId" rather than allowing the PFS code to calculate it.
This is a result of using pfsDesign files in ways that I didn't consider when writing down the datamodel, but which make total sense. One option would be to not use pfsDesign files in this way, but I think that that's probably not the best solution as we'd need to define a new file format, and it'd still need a unique name. Another is to proceed using an external generation of the pfsDesignId, in which case we need to be sure that they are indeed unique. Alternatively, we could extend the definition of the pfsDesignId to include the (nominal) boresight, rotation, and list of guide star positions.

I favour the last of these proposals (which will require a DAMD ticket). cloomis? price?

That seems clean, and at this point in time safe.

So for the last proposal, would Martin need, in addition to the (nominal) boresight, rotation, list of guidestar positions, to assume default positions for the cobras (presumably the home positions)?

I think we (now) handle NaN correctly, so this should be automatic.

I don't like the idea of building up a pfsDesign file in fits and starts, as I think it's bound to cause confusion. I suggest we add a new file type, say pfsPlan, which will be similar to pfsDesign but without the cobra positions, and have the pfsPlanId hash calculated from the available information.

The implemented PfsDesign/PfsConfig hierarchy already supports building on top of existing classes, so it should be simple to code.

If we go the route of introducing new file types, this makes things a bit more complicated for `ets_shuffle` and `ets_fiberalloc`...

Currently the idea is that

• `ets_shuffle` reads boresight and PA from a "pfsDesign-like" file and outputs the input file, enriched with guide star information.
• `ets_fiberalloc` reads boresight and PA from a "pfsDesign-like" file and outputs the input file, enriched by cobra-target assignment information.

This has the nice property that the order of execution doesn't matter for those two programs, and that they just use PFSdesign files (in various stages of construction) fo input and output. I'd be happy not to lose this kind of simplicity, especially since it is fairly easy to test a PFSDesign for completeness when this is really required.

From Martin Reinecke in the zoom chat during the commissioning telecon (Nov 10/11, 2021):

The most up to date version of the commissioning.py script is at https://github.com/Subaru-PFS/ets_fiberalloc/blob/commissioning_demo_2/commissioning.py

BTW, by setting –use_gurobi as follows, you don't need to put True or False explicitly.

parser.add_argument("--use_gurobi", action="store_true", help="use Gurobi solver instead of PuLP")

Thank you, this is very useful! I will update the code accordingly. (My main language is C++ )

Just a small thing but the current commissioning.py didn't work for me:

Traceback (most recent call last):
  File "commissioning.py", line 393, in <module>
    main()
  File "commissioning.py", line 382, in main
    args = get_arguments()
  File "commissioning.py", line 88, in get_arguments
    parser.add_argument("--use_gurobi", type=bool, action='store_true', help="use Gurobi solver instead of PuLP")
  File "/opt/anaconda3/lib/python3.7/argparse.py", line 1359, in add_argument
    action = action_class(**kwargs)
TypeError: __init__() got an unexpected keyword argument 'type'
}

Please remove `type=bool`.

type=bool is not needed. I don't know how to merge the scripts of yours and mine. What does work best for us? I'm trying to untouch the assignment part so that integration can be easy. But I want to put more parameters such as flues in pfsDesign and will need to write a separate version of generatePfsDesign().

I removed the `type=bool`. Strangely, it even worked for me when the argument was present.

Eventually, I believe that I was able to manage to create a pfsDesign file by updating the Martin's commissioning.py. My code (subaru_fiber_allocation_2021nov.py) and README are found at https://github.com/Subaru-PFS/ets_target_database/tree/commissioning_2021nov/examples/commissioning_2021nov .

I attach the pfsDesign file generated with the example in the README above. If someone can check if it looks okay and suggestion for further tests of the script with various conditions, I'd appreciate.

pfsDesign-0x6a119411f0b96b28.fits

I think I can close it now as the code was developed for the engineering run and tested by a few people, but the fiber configuration was not tested due to the AG and rotator issues.