The most basic metric for most solar system populations is the fraction that is “Discovered” by LSST, I believe. To that end: having input populations for metrics related to discovery is important!
Okay, so some background information first:
because of speed limitations for generating observations, I am usually setting the number of orbit in the input population to about 5k
in general, I am assuming that the orbital elements and the H distribution can be roughly separated (this doesn’t have to be perfect, for most comparison purposes) – so these 5k orbits are cloned over a range of H values when evaluating the MAF discovery metrics. I have found pretty good results when evaluating the MAF metrics with a stepsize of between 0.1 and 0.5 magnitudes, so usually use 0.2, and try use a maximum/minimum H value to capture the place where the discovery flattens out at both max/min values. The exact values and range depend on the population.
you can choose colors for your objects, via their SEDs [due to how we started and how the machinery works, SEDs are preferred rather than broad-band colors, but we can make fake SEDs from broad-band colors, no problem]
– These new SEDs have to be referenced in the input orbits, and the data file put in the right place, but then that’s it.
I’m not including light curves at the moment. You may find that including a lightcurve is important for a particular metric, but that’s not currently implemented in general.
– HOWEVER, the apparent magnitude for any object at any observation is calculated via a “Stacker” – such as the ones at https://github.com/lsst/sims_maf/blob/feature/updateMoPlots/python/lsst/sims/maf/stackers/moStackers.py
so you can implement different Stackers to calculate apparent magnitudes in different ways (such as for comets or active asteroids) and then use these new calculated magnitudes. You could add a lightcurve Stacker if needed, then you just use that alternative stacker instead of the standard stacker.
So specific populations: (these are what I would like to use going forward, but if you have other suggestions or better suggestions, let’s have that discussion here)
TNOs: CFEPS L7 model (see http://www.cfeps.net/?page_id=105 and references therein) … subsampled and assigned SEDs (but yes, these SEDs should be updated to be redder)
Scattered Disk Objects: ref Shankman scattered disk model … subsampled and added SEDs
MBAs: Grav S3M model ref … based on a version from PanSTARRS, but pretty close to the version available from https://drtgrav.com/research/76-2/ … then subsampled and assigned C and S type SEDs.
Jovian Trojans: Grav S3M model ref – same reference as above, but this is no longer available on the same webpage. We have a version based on the PanSTARRS model.
Added soon: Minimoons: Granvik & Fedorets (I will have to find the appropriate reference)
Some of us in the SSSC have been working on putting populations in this repo. I think if anyone has something to add it would be good to add it to this repo.
Thanks Mikael - was going to check with you about that.
Meg … the repo is a good idea. For use with the simulations though, I would like to make sure I’m using reproducible colors - which means adding the SEDs into the populations.
Would it be okay to modify the repo so that there are “as contributed” populations and also “as used” groups? This would, for example, standardize the SEDs and subsampling of the population**.
** subsampling the typically-used population size is helpful and in some cases necessary, but not necessarily helpful for everything – and having the full population available in case we get some kind of speedup in sims_movingObjects OR are simulating catalogs for some other reason and want a non-cloned population is useful.
Oh and please let me be sure to clarify something! Because these population models will be publicly available, it is implied that they should be re-distributable.
It may make sense to add a separate directory in the repo for each contributed population, so that it can continue being associated with the appropriate license files (it’s very good to add a license file so that people can be clear that they are allowed to use and redistribute your contributed populations – adding version numbers also makes it easier for people to identify which version of the population it is, if you ever feel the need to update).
Ok, I’ll work on adding the appropriate stuff to the repo for the populations which I’ve gathered so far.
I think then there needs to be a few repos. For just orbits and ones people are okay being public (there is an MIT license in the repo) then it should go there. If there needs a private repo feel free to make one or ask me too.
I don’t know what this means:
Would it be okay to modify the repo so that there are “as contributed” populations and also “as used” groups? This would, for example, standardize the SEDs and subsampling of the population**.
I’m sure I’m not the only one struggling with understanding these parts of the LSST moving sim package. Maybe you can clarify.
There are about 801999 objects in Mikael’s NEO model. This full model would be the ‘as contributed’ / full / raw input population. I cannot run 800K objects through sims_movingObjects and calculate metrics on them for regular evaluation of simulations - plus, after about 5K objects cloned over H values, you get statistically the same answer for much of the metrics we’re using. Also, these objects do not have colors/SEDs assigned.
So I’ve subsampled the population to about 5k orbits, assigned SEDs and this is the set that I would use for metric calculations (running through sims_movingObjects to create observations for each run and then running through MAF to calculate metrics over a range of H values for each orbit). This is the ‘as used’ (for metric purposes) population.
Why keep around the original population at all?
It serves as a useful reference to where the subsample came from.
If I wanted to generate a different subsample, I can.
If Siegfried wants to generate a complete catalog of observations (for use for MOPS linking tests, for example), he can.