Make the CLI intuitive

[ijiraq]

The CLI needs to be a little intuitive and clearly self documented. The options below are listed to meet the current requirements.

Implementation can use argparse package. LSST pipelines pass the argparse object around to various methods.

An approach that would allow a batch of objects to processed, where the options are the same for all objects and the objects are processed in parallel?

• may accept options provided via an '@file'
• may provide options as a .ecsv file
• a series of one or more object names to do photometry on.
• must use --help to provide a list of options and features.
• --start-time [-s] for the starting time of when to search [can be in any valid astropy.time.Time format that is automatically parseable.
• --end-time [-e] last date to search, same format rules as --start-time. [--end-time and --day-range are exclusive]
• --day-range [-d] number of days to search forward from start time, can be -ve to specify days in the past
• --max-search-ellipse [-x] maximum size of error ellipse that should be searched (3-sigma value) [User can give units?] (default of ??). [e.g. -x 10.2 arcsec ]
• --min-cutout-size [-m] minimum size of cutout, maximum is error ellipse.
• --ephemeris-service the name of the ephemeris service to use, from a choice list [Horizons, Skybot, .. ?]
• --image-service the name of the image service to use, from a choice list [LSST-Butler, ZTF, ]
• --catalog-service the name of the ephemeris service to use, from a choice list [LSST-TAP, ZTF, ?]
• --photometry-service name of the forced photometry package to use [https://github.com/rubin-dp0/tutorial-notebooks/blob/main/DP02_05_Source_Detection_and_Measurement.ipynb]
• --threshold the limit at which to attempt to do force photometry (SNR , default = 3?)
• --return-cutouts should we return a cutout. (default == FALSE)

[carrholt]

For the --min-cutout-size, is there a reason this is not just a defined cutout size? I'm unsure what the reason is for having a maximum/minimum? And I also feel like the maximum of the error ellipse is too small for well defined orbits.

[carrholt]

I'm unsure of the --max-search-ellipse as well. Why is this a maximum rather than a defined value? And what is the purpose of specifying 3-sigma here? I would imagine the default search ellipse to be the 3-sigma value given by Horizons during the ephemeris query. Maybe that is where the 3-sigma came from, but I don't think that would apply to a user input.

[jrob93]

Hi all, I have played a bit with running python odc.py and the arguments relating to the "ephemeris" service make sense to me: --ephemeris-service, --target, --target-type, --start-time, --end-time, --day-range, --step.

So I approve of these args, I just have some thoughts on the documentation. What are the options for --target-type? I see how horizons_interface.py and miriade_interface.py digest these to be suitable for each service but it would be helpful as a user to have easy access to the accepted options. Likewise, after some digging I see that --step accepts units of "s, m, h, d" - could this be more visible?

[jrob93]

And now some general thoughts on the other args. If I interpret correctly, most args are only relevant for a particular aspect listed in --service-selection. It might be useful to group/label args by the service they relate to. Some other things:

• The docs for --filters says this applies to the image service. Should this instead apply to the catalog service in order to reduce the number of images required to be searched? (I am assuming the catalog service occurs before image).
• I think I see why --min-cutout-size is a minimum. If a source is trailed/extended the user may actually want a larger cutout that contains the whole source. The docs say "max is error ellipse size", does this refer to --max-search-ellipse, i.e. the max only applies if this second arg is passed?
• As for --max-search-ellipse, I don't really understand it. Is this intended to implement a maximum angular distance when considering sources that are offset from the predicted ephemerides? And if it is an ellipse, how is this defined on the command line? Do we need a size, elongation and position angle?

Speaking of offset sources, Marc and Laszlo discussed how these should be handled in the weekly meeting. It sounds like this should be either, measure the flux only at the predicted ephemeris, or, measure flux at the nearest detected source (within --max-search-ellipse)? Also Laszlo mentioned using PSF fits, I presume there are also options for just doing aperture photometry at either of the two positions I just mentioned? Of course the photometry parts have not yet been implemented so this could be preemptive. Maybe all of these different options will be encapsulated by --photometry-service? I.e. boil these options down to flags for the different routines, e.g.: fixed_pos_aper, nearest_source_psf etc?