84 issue readme omits required phrosty intermediate directory for container run

[laldoroty]

README update only.

[rknop]

This is fine, though we might want to think at some point whether we really want two different directories.

If you look at interactive_podman.sh, it mounts phrosty_intermediate at /scratch and phrosty_temp at /phrosty_temp. This has all the hallmarks of stuff that was written at different times.... Coming at it afresh, the directory names really don't make it obvious what is different between the two, and if I didn't know some of the history I'd conclude that somebody added a thing not rememering that they'd already added something to do the same thing before.

Questions we should ask ourselves:

(1) Do the intermediate files need to go to a different place from temp files? Maybe yes; temp files are intended to be things that phrosty writes and deletes, whereas intermediate files are things that exist for debugging. But, still, we could write them all to the same place, and just delete the ones we want to delete. You could view it all as temporary space, and the option to preserve intermediate files is just syaing "hey, don't delete (some of) your temporary files.

(2) The names phrosty_temp and phrosty_intermediate are fine if we keep them separate, but we probably ought to mount the phrosty_intermedaite directory somewhere other than /scratch inside the container. Of course, it doesn't matter, because it's just a name, but the name /scratch suggests to me temp files.

[wmwv]

I agree that we should make phrosty_temp and phrosty_intermediate the same in the future. I can understand the nuances of differences, but I think it will be simplest for them just to be the same.

The one concern I have is that I don't think we have a good way of handling simultaneous processing of the same data. I think at this point our solution is "don't do that", but someday we'll want a clearly defined way to do this. I mention this because another view of "temp" files is files that our guaranteed to not conflict with anything else running (like pytest makes).

[rknop]

...yeah, we definitely need to worry about that. Orchestration is non-trivial.

We could try to make it so that it's never an issue if we launch the same lightcurve 10 times, but it's probably better to have orchestration to stop that from happening.

But, we will have issues where the same image is used at the same time in two different jobs for two different lightcurves, and we need to be ready to handle that.

Eventually.