Detections for three observing cycles (oc28 - oc30, 3 lunations)

[pveres]

@rhiannonlynne @mjuric @ivezic @stevechesley

Here are the detections from the baseline (enigma_1189) simulation for three lunations. Perturbing bodies are planets, minor planets are turned off as perturbers. We used full NEO population (Grav), version S3M V0.9.4.3/a.

Constrains:

• masking is on (4 corners of the square FOV are missing to simulate realistic LSST FOV)
• mask is being rotated by position angle for each field
• area of the square is 12.0482965131 square degrees
• fill factor 92% (randomly removed detections in the masked FOV)
• trailing loss is ON (Detection loss - red curve)
• fading is ON
• vignetting is OFF
• all asteroids are considered S-types for color conversion (LSST conversion): g = -0.395 r = 0.255 i = 0.455 z = 0.401 y = 0.406 w = 0.16 u = -1.927

File contains object_name, magnitude, filter_id, ra, dec, S/N, epoch (MJD UTC), trail length as well as field information (ra, dec, limiting. mag, seeing, field_id)

oc28-30.txt

[rhiannonlynne]

Thanks Peter. It looks like oc28 started on night 3038 - do you know why there were no observations in the 87 observations that occured on that same night, before the first one which is recorded? Similarly, it looks like the last observation on oc30 was on night 3127 - do you know why there were no observations in the remaining 951 observations on that same night? It's doesn't seem to be due to a filter change, as the filter of that first/last observation is the same as the observations preceeding/succeding those.

Maybe I'm just not quite understanding how you're defining the start/end of the observing cycle, but it seems like maybe the start/end of the nights are not quite synced up with what I'd expect.

The last observation for oc30 is at 52479.998692 = '2002-07-24 23:58:06.989' (UTC) .. so just before midnight at Greenwich, but not the end of the night for the telescope. I find that the last observation recorded by opsim for that same night to be at 52480.442478 = '2002-07-25 10:37:10.099' (UTC) .. which is morning at the LSST site.

[pveres]

Lynne, you are right, it seems that Pan-STARRS ocnum (observing cycle) definition is causing a trouble here. Let me provide you a new file (starting with night 3038 and ending with night 3127, including).

I may revisit the source code and fix the oc definition. As far as I remember observing cycle is tied to new moon...

Peter

On Thu, Feb 4, 2016 at 11:54 AM, Lynne Jones notifications@github.com wrote:

Thanks Peter. It looks like oc28 started on night 3038 - do you know why there were no observations in the 87 observations that occured on that same night, before the first one which is recorded? Similarly, it looks like the last observation on oc30 was on night 3127 - do you know why there were no observations in the remaining 951 observations on that same night? It's doesn't seem to be due to a filter change, as the filter of that first/last observation is the same as the observations preceeding/succeding those.

Maybe I'm just not quite understanding how you're defining the start/end of the observing cycle, but it seems like maybe the start/end of the nights are not quite synced up with what I'd expect.

The last observation for oc30 is at 52479.998692 = '2002-07-24 23:58:06.989' (UTC) .. so just before midnight at Greenwich, but not the end of the night for the telescope. I find that the last observation recorded by opsim for that same night to be at '2002-07-25 10:37:10.099' = '2002-07-25 10:37:10.099' (UTC) .. which is morning at the LSST site.

— Reply to this email directly or view it on GitHub https://github.com/testMOPS/mops/issues/13#issuecomment-180022211.

Peter Veres Caltech Postdoctoral Scholar

Jet Propulsion Laboratory, NASA Mission Design & Navigation T1721-202 4800 Oak Grove Dr. Pasadena, CA 91109

http://scienceandtechnology.jpl.nasa.gov/people/P_Veres/ phone: 818-354-0919 email: veres@jpl.nasa.gov

[pveres]

Revised detection table (first and last nights are solid).

oc28-30.txt

[rhiannonlynne]

Thanks - looks like there's still a few visits at the start (7) and end (46) of the night without object observations, but maybe those are just too bright or don't happen to have objects.

[pveres]

Possibly - I only ran mysql query with minimum and maximum epochs for a given night that has any detection (so if there was a field in the first night earlier that had no detection, it won't show up in the table - because there is no detection). Also - singletons are not there.

On Thu, Feb 4, 2016 at 12:37 PM, Lynne Jones notifications@github.com wrote:

Thanks - looks like there's still a few visits at the start (7) and end (46) of the night without object observations, but maybe those are just too bright or don't happen to have objects.

— Reply to this email directly or view it on GitHub https://github.com/testMOPS/mops/issues/13#issuecomment-180035995.

Peter Veres Caltech Postdoctoral Scholar

Jet Propulsion Laboratory, NASA Mission Design & Navigation T1721-202 4800 Oak Grove Dr. Pasadena, CA 91109

http://scienceandtechnology.jpl.nasa.gov/people/P_Veres/ phone: 818-354-0919 email: veres@jpl.nasa.gov

[rhiannonlynne]

Ah - the singleton thing might explain a lot. (singleton of the objects -- not the fields, right?)

[pveres]

Singletons = fields. I rejected all fields that are only visited once per night.

[rhiannonlynne]

That seems not optimal to me .. there are objects that cross field boundaries. I'll see if I can figure out how many.

On Thu, Feb 4, 2016 at 12:58 PM pveres notifications@github.com wrote:

Singletons = fields. I rejected all fields that are only visited once per night.

— Reply to this email directly or view it on GitHub https://github.com/testMOPS/mops/issues/13#issuecomment-180045910.

[pveres]

You are right, this could happen. Can you please let me know how many objects? This depends on how much is overlapping, if there is a field attached to a singleton, how many asteroids are close enough to the edge of the FOV and appear in another field for a second time, etc.

areawise, singleton fields occupy 30% of area and 16% of time in these observing cycles if I am not wrong.

Peter

On Thu, Feb 4, 2016 at 1:52 PM, Lynne Jones notifications@github.com wrote:

That seems not optimal to me .. there are objects that cross field boundaries. I'll see if I can figure out how many.

On Thu, Feb 4, 2016 at 12:58 PM pveres notifications@github.com wrote:

Singletons = fields. I rejected all fields that are only visited once per night.

— Reply to this email directly or view it on GitHub https://github.com/testMOPS/mops/issues/13#issuecomment-180045910.

— Reply to this email directly or view it on GitHub https://github.com/testMOPS/mops/issues/13#issuecomment-180067064.

Peter Veres Caltech Postdoctoral Scholar

Jet Propulsion Laboratory, NASA Mission Design & Navigation T1721-202 4800 Oak Grove Dr. Pasadena, CA 91109

http://scienceandtechnology.jpl.nasa.gov/people/P_Veres/ phone: 818-354-0919 email: veres@jpl.nasa.gov

[stevechesley]

My estimate is that no more than 1-2% of NEOs will move out of a field within ~2 hours. And only a fraction of those will be seen in the adjacent field because that field will not always be scheduled. Multiply that by the fraction of time spent on singletons (in good filters) and I think that neglecting singleton fields is a <<1% effect. If you include the overlap regions the effect may be more important.

It could be worth a test to compare the set of NEO tracklets from a single OC with and without the singleton fields in the sim.

On the plus side, neglecting the singleton fields gives a conservative performance estimate. But not by much, I'd bet.

[pveres]

I am actually running MOPS sim to answer this. It should be completed in 2-3 hours. For 3 observing cycles.

Peter

On Thu, Feb 4, 2016 at 2:47 PM, Steve Chesley notifications@github.com wrote:

My estimate is that no more than 1-2% of NEOs will move out of a field within ~2 hours. And only a fraction of those will be seen in the adjacent field because that field will not always be scheduled. Multiply that by the fraction of time spent on singletons (in good filters) and I think that neglecting singleton fields is a <<1% effect. If you include the overlap regions the effect may be more important.

It could be worth a test to compare the set of NEO tracklets from a single OC with and without the singleton fields in the sim.

On the plus side, neglecting the singleton fields gives a conservative performance estimate. But not by much, I'd bet.

— Reply to this email directly or view it on GitHub https://github.com/testMOPS/mops/issues/13#issuecomment-180087641.

Peter Veres Caltech Postdoctoral Scholar

Jet Propulsion Laboratory, NASA Mission Design & Navigation T1721-202 4800 Oak Grove Dr. Pasadena, CA 91109

http://scienceandtechnology.jpl.nasa.gov/people/P_Veres/ phone: 818-354-0919 email: veres@jpl.nasa.gov

[pveres]

Here is the answer:

nights: 3038-3127

without singleton fields: 7516 distinct objects in detections 5416 distinct objects in tracklets

all fields: 7713 distinct objects in detections 5399 distinct objects in tracklets

So, there is about 200 more objects visible in ALL fields (which seems reasonable), however, when you create tracklets, you basically get same numbers (5416 vs. 5399), there is even 17 more objects in fields without singletons having tracklets (which is the opposite way how you would expect this). However, fading was turned on in both simulations, so there is some random element included that throws away and adds detections near the magnitude limit. Steve's assumption seems to be close to what I see.

[rhiannonlynne]

Good to know.

On Mon, Feb 8, 2016 at 12:18 PM pveres notifications@github.com wrote:

Here is the answer:

nights: 3038-3127

without singleton fields: 7516 distinct objects in detections 5416 distinct objects in tracklets

all fields: 7713 distinct objects in detections 5399 distinct objects in tracklets

So, there is about 200 more objects visible in ALL fields (which seems reasonable), however, when you create tracklets, you basically get same numbers (5416 vs. 5399), there is even 17 more objects in fields without singletons having tracklets (which is the opposite way how you would expect this). However, fading was turned on in both simulations, so there is some random element included that throws away and adds detections near the magnitude limit. Steve's assumption seems to be close to what I see.

— Reply to this email directly or view it on GitHub https://github.com/testMOPS/mops/issues/13#issuecomment-181514406.

[rhiannonlynne]

We are running MOPS on this and finding interesting things about our version of MOPS. Just to be sure -- the detections here are without astrometric noise, correct?

[pveres]

Correct, these are without astrometric or photometric noise.

Peter

On Fri, Apr 8, 2016 at 3:42 PM, Lynne Jones notifications@github.com wrote:

We are running MOPS on this and finding interesting things about our version of MOPS. Just to be sure -- the detections here are without astrometric noise, correct?

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/testMOPS/mops/issues/13#issuecomment-207636556

Peter Veres Caltech Postdoctoral Scholar

Jet Propulsion Laboratory, NASA Mission Design & Navigation T1721-202 4800 Oak Grove Dr. Pasadena, CA 91109

http://scienceandtechnology.jpl.nasa.gov/people/P_Veres/ phone: 818-354-0919 email: veres@jpl.nasa.gov