let me know how/if the syntax of ingestPfsImages.py evolves, I should no longer to need to specify pfsConfigDir right ?

ingestPfsImages.py expects that the pfsConfig file is sitting in the same directory as the images, or it's in the --pfsConfigDir.

Makes sense, can you make it evolve so it expect file in /data/raw/DATE/pfsConfig ?

Why do we want to put the pfsConfig files in a separate directory? They are as important as the raw pixels, so why not put them in the same directory? Then a user interested in the data for one night only has to copy files from a single directory.

Is it that bad to have "/data/raw/$DATE/{a,few,types}/", where the "/data/raw/$DATE"  is the single directory? Granted that the other directories are mostly for engineering purposes – guider frames, etc. – so not of universal interest.

I had been thinking that "/data/raw" is the end of the ICS domain, the DRP root as the beginning of the DRP domain, and the ingest scripts as the only things which need to know about both.

If that is not natural, we can still adapt.

The ingest script doesn't know about date-based directories: it receives a list of image files, and needs to find the associated pfsConfig files. The current options are that these files are in the same directory as the image files or they are in a separate directory. There is currently no facility to build that separate directory name; while I think that's something we could do (and fairly easily, I think), I don't like treating the pfsConfig files substantially differently from the image files. I can see users the morning after their run copying their image files while neglecting the pfsConfig files.

One technical point is that the PFSx-writing processes all run as a distinct "pfs-data" user which is only useable on the fourteen or so DAQ hosts, and those data files (and directories) are not supposed to be group-writeable (hmm to self: the directories are right but the files not). It would be hard (and undesirable) to change that at this point. Long after that decision we added pfsConfig writing for every SPS visit, and we would have to do some splitting and refactoring to allow pfsConfigs to also be written by that "pfs-data" user.

That doesn't mean we can't do it if appropriate.

Sounds like it's easier for me to change things on the DRP side. I'll try to tackle this tomorrow.

I've got an implementation that seems to do the job. Given --pfsConfigDir /path/to, it will look for the pfsConfig file in the following places:

• /path/to/
• /path/to/<dateObs>/pfsConfig/
• Look for pfsDesign file in /path/to and write pfsConfig to /path/to/<dateObs>/pfsConfig/

So I expect you'll use --pfsConfigDir /data/raw.

Changes in pull request look fine. Would prefer a warning if a pfsConfig file is created from a pfsDesign. See comments in PR.

Changed the existing debug logging to warning level.

Merged.