Question about what's causing the slight loss of small Main Belt Asteroids in v2.0 simulation baseline

In terms of the v2.0 simulations, there is a drop by about ~5-6% for the small main belt asteroids when comparing to the retro footprint to the baseline 2.0 It’s not clear 100% clear to us in the SSSC why this is happening.

Question for the Rubin Scheduler team: Is this potentially because of decreasing visits in the galactic plane where likely the detection efficiency will be less because of the stellar crowding? What do you think is the cause?


Hi Meg,

To answer this properly, I think the best thing to do is to take the observations that come out of the retro_baseline, and remove the observations within the galactic plane region that gets fewer visits in the new simulation, then re-run discovery statistics.
Alternatively, (and maybe better long-run), take the observations and apply a different m5 cut as a function of galactic latitude. I just am not quite sure what that would be, but I guess a first pass version is just removing all of the visits within +/-15deg (which is pretty close to the dust extinction limits).

The steps to this aren’t that complicated:

  • get the main belt asteroid observations from retro_baseline_v2.0_10yrs
  • read them into python and use a rubin_sim utility to calculate l/b (or something other than rubin_sim, we just have a conversion routine)
  • remove observations with ra/dec < 15 degrees
  • write new observations files
  • run metrics on the new observations

Hopefully I’ll find a bit of time to actually run through that later this week.


It helps to include the baseline_retrofoot simulation as well. If I’m looking at the right metrics, baseline_retrofoot is the worst performing one. Note that baseline and baseline_retrofoot have rolling turned on, while retro_baseline has no rolling. So I think this means the new footprint is better for MBA’s, but rolling hurts them a bit.

Ah, good catch!
And this has made me realize that “no_roll” didn’t manage to make it into the list of rolling families in the families lists (probably because I was looking for “rolling” which matches all the others, but not that one?). So I will fix that and we can also look at the results for the no_roll run compared to baseline or the other rolling simulations.

Thanks @ljones and @yoachim for your help . We suspect this is not a rolling effect. There did not look like MBAs were changing significantly in most rolling scenarios until you get to the extreme cases… Definitely worth checking the no roll case when it is available.