Return starting model and config file for delay calibration

[tikk3r]

I recently found myself in multiple scenarios where I needed to re-run or tweak the delay calibration on difficult fields. With settings and skymodels now being generated automatically, this is cumbersome at the moment as they are not outputs of the main workflow and as such do not "survive" a successful pipeline run. This PR adds the starting models as outputs of the pipeline as well as the config file that comes from phaseup-concat (the automatic selection does not yet generate config files, I'll leave that for a future PR). This should improve reproducibility in general as well by having easier access to the combination of model and settings that were used.

[lonbar]

Looks good to me. A few minor syntax nits.

[lonbar]

I'm wondering if it makes sense to bundle outputs such as these into a record or perhaps a JSON file. It seems more like metadata; the user is not interested in these output per se. It is definitely a good idea to store them, but bundling it up could perhaps simplify the outputs that we have in the workflows. What do you think?

[tikk3r]

I'm wondering if it makes sense to bundle outputs such as these into a record or perhaps a JSON file. It seems more like metadata; the user is not interested in these output per se. It is definitely a good idea to store them, but bundling it up could perhaps simplify the outputs that we have in the workflows. What do you think?

I'm not sure I fully understand. Do you mean in the sense of the contents of these files in a JSON file?

[lonbar]

@tikk3r perhaps, yes. I am mostly thinking out loud here. We could collect and store all the individual files, but perhaps it's useful to create a data structure that contains all the parameters and their values per parset, perhaps with some information/metadata such as which steps they are used in.

[tikk3r]

@tikk3r perhaps, yes. I am mostly thinking out loud here. We could collect and store all the individual files, but perhaps it's useful to create a data structure that contains all the parameters and their values per parset, perhaps with some information/metadata such as which steps they are used in.

It sounds like an interesting idea. The nice thing about having the files is that they are in the format expected by the software, so we don't have to reconstruct it. Maybe something for another time?

[lonbar]

It sounds like an interesting idea. The nice thing about having the files is that they are in the format expected by the software, so we don't have to reconstruct it. Maybe something for another time?

That's fine. My main concern was that it may not be obvious which file to apply where, but we can leave it as it is for now.