Simulation Software for Algorithms Working Group - Jonathan McDowell The group has been tasked with planning the software outlined in SATCON1 recommendations R1 to R3 (reproduced at the end of this doc). Our charge is: - Implementation plan - Resource plan - Schedule To focus discussion I have attempted to transform the SATCON1 recommendations into a specific set of high level software requirements as I see them, with provisional (and hopefully catchy) names for convenience of reference. I would characterize each of these as a fairly major software effort if they are to be robust enough to support the community. R1 TrailFix - Inputs: a) Image parameters (FOV, pixel size, flux cal) b) Trail search parameters (width ranges, S/N etc?) Outputs: 1) Identify trails - candidate trail list 2) Model trails (including photometry errors): candidate trail list with parameters 3) Subtract trails- trail-subtracted images 4) Mask trails - masked images R2 PassPredict Inputs: a) Ephemeris database (real or simulated) b) Observatory parameters: Lat, Lon, Ht c) Observation parameters (RA, Dec, date/time, t_exp, FOV) d) Satellite physical and optical properties (BDRF etc) including software model to predict brightness Outputs: 1) Transit list: Satellite ID, time, probability, trail parameters+uncertainties Trail params include satellite magnitude, trail surface brightness, trail width, Too uncertain to give trail location on image? R3.1 EphemSimulate Inputs: a) Constellation shell parameters b) Observation date Outputs 1) Simulated ephemeris database R3.2 ImageSimulate Inputs: a) Observation parameters, same as fed to Pass Predict b) Base image (e.g. from archive for desired telescope) c) List of additional sources to simulate with PSF and/or thumbnail image Output: 1) Simulated image (no trails, but with added test sources). Note: this tool may not be needed - maybe you can just use existing images - but it'll be good to add faint sources with known (because simulated) properties to properly assess detection thresholds. R3.3 TrailSimulate Inputs: a) Transit list from R2 PassPredict run on output from R3.1 EphemSimulate b) Observation parameters, same as fed to Pass Predict c) Simulated image without trails Must be consistent with b) d) Model (code) for generating trails including CCD and optical side effects Outputs: 1) Simulated image with trails 2) Fraction of image pixels affected (including by side effects) R3.4 TrailReduce Inputs: a) Simulated image without trails, output from ImageSimulate b) Simulated image with trails, output from R3.2 TrailSimulate c) Data reduction parameters, TBD Outputs: Point source detection list with source parameters for both images Extended source detection list with source parameters for both images Detection efficiency and photometric accuracy for both lists Sensitivity limit for both lists Derived output: percentage degradation in source detection efficiency vs brightness percentage degradation in detection threshold. R3.5 Simulation Assessment Not a software application per se. We are also tasked with aggregating the simulation results generated by R3.1 to R3.4 and interpreting them, summarizing them for the community. (well, at least for SATCON2, we have to figure out how this will be done, rather than actually do it) 1) Define a set of simulations to cover the relevant parameter spaces and provide sufficient data for an assessment. 2) Actually run the simulations. 3) Generate summary trend plots and tables (versus time of year, obs location, etc; for different types of observation/science, telescope, for different constellation scenarios...) 4) Provide recommendations on desired limits on trails (and maybe back out corresponding limits on various types of satellite, or is that beyond scope?) Cross-Group Coordination: ------------------------- We will need to work fairly closely with the OBSERVATIONS group on the issue of 'publicly accessible satellite positional information', which is a key input for some of the above software. The POLICY group may also be relevant to ensure national policies support the availability of the needed inputs. We should have conversations with the COMMUNITY ENGAGEMENT group about what stakeholders, if any, will need to access the software beyond the professional and hobbyist observer community, and what implications that has for the interfaces. Other Issues (to be explored but not necessarily decided) ------------ - python code, web interfaces, or other? - open source, licences - architecture to permit alternative user-written plugins for e.g. satellite models Appendix: the Recommendations (for reference) Recommendation 1 Support development of a software application available to the general astronomy community to identify, model, subtract, and mask satellite trails in images on the basis of user-supplied parameters. Recommendation 2 Support development of a software application for observation planning available to the general astronomy community that predicts the time and projection of satellite transits through an image, given celestial position, time of night, exposure length, and field of view, based on the public database of ephemerides. Current simulation work provides a strong basis for the development of such an application. Recommendation 3 Support selected detailed simulations of the effects on data analysis systematics and data reduction signal-to-noise impacts of masked trails on scientific programs affected by satellite constellations. Aggregation of results should identify any lower thresholds for the brightness or rate of occurrence of satellite trails that would significantly reduce their negative impact on the observations.