Intro. 2005 May 9MOPS Preliminary Design Review2 Preliminary Design Review The Pan-STARRS Moving...

2005 May 9 MOPS Preliminary Design Review 2

Preliminary Design Review

The Pan-STARRSMoving Object Processing System


PDR Purpose (from the charge):

Ensure that the preliminary design meets the requirements as specified in the PS-1 MOPS SRS

Ensure that the development plan will enable schedules and budgets to be maintained

Ensure that integration and testing procedures have been considered

Ensure that risk mitigation plans have been developed for identified potential risks


Schedule09:00 Intro & Requirements

OverviewRJ

Top-Level MOPS architecture RJ

10:30 Break

10:45 Algorithms RJ & TG

Software Design LD & RJ

12:30 Lunch

1:30 Hardware Design LD & JH

Status & Development Plan RJ

3:30 Break

3:45 Risk Assessment & Conclusion RJ


MOPS Overview

• Identify known objects

• Discover new objects

• Derive observable parameters

• Catalogue objects


MOPS Partners

• Carnegie Mellon University, Robotics Institute AUTON Laboratory (Kubica)

• Jet Propulsion Lab (JPL) (Chesley)• Minor Planet Center (MPC) (Spahr)• Science Applications International

Corporation (SAIC) (Heasley)• University of Helsinki (Kaasalainen)• University of Pisa (Milani)


MOPS Timeline2003 Mar Hire Manager (Robert Jedicke)

2004 Apr Orbit Determination & Ephemeris Software Trade study (PSDC-500-001

2004 Jul Software Requirements Specifications (PSDC-530-001)

2004 Jul System Concept Definition (SCD)

2004 Aug Software Requirements Review (SRR)

2004 Sep NEO IOD Studies (PSDC-500-002)

2004 Nov Solar System Survey Simulations (PSDC-500-003)

2004 Nov Hire Post-Doc (Tommy Grav)

2004 Dec Hire SW Engineer (Larry Denneau)

2005 Apr Solar System Model (PSDC-500-004)

2005 Apr Algorithm Design Description (PSDC-530-002)

2005 Apr Software Design Description (PSDC-530-003)

2005 May Preliminary Design Review (PDR)


Requirements Overview

• Top Level Requirements

• Selected Derived Requirements(especially modifications from SRR)

• External InterfaceRequirements

• Other important reqs


Top Level Requirements

9.2.1 MOPS shall create and maintain a data collection of detections and object parameters (e.g., orbit elements, absolute magnitudes) for >90% of the PHOs that reach R=24 for 12 consecutive days during the course of PS operations.

(from PSDC-250-002 – PS-4 System Concept Definition)

Above R=24 all the time

for 12 days



9.2.2 MOPS shall create and maintain a data collection (DC) of detections and object parameters (e.g., orbit elements, absolute magnitudes) for >80% (TBR) of the members that reach R=24 for 12 consecutive days within each class of solar system object (Main Belt, Trojan, Centaur, TNO, Comet, etc, except NEO and PHO) during the course of PS operations.




9.2.3 MOPS shall calculate the efficiency and false-positive rates for detection, attributing, linking, orbit identification, etc., for solar system objects as a function of (at minimum) semi-major axis, eccentricity, inclination, absolute magnitude, position with respect to opposition and galactic latitude.




9.2.4 Data products created by MOPS shall be published to the PS Published Science Products Subsystem (PSPS).



Top Level Requirements Highlights

• >90% of the PHOs that reach R=24 for 12 consecutive days

• >80% of the members of each of the other populations (MB,CEN,TNO,etc.) that reach R=24 for 12

• calculate efficiency and false-positive rates

• Data products published to the PSPS.



Selected Derived Requirements

• Supplementary requirements on MOPS and other Pan-STARRS sub-systems in order to meet primary requirements


Terminology Review: Detections, Tracklets, Tracks & Orbits

• Detection– A statistically significant collection of pixels after image

convolution with a shape kernel

• Tracklet– A set of 2 detections that may be observations of the

same object

• Track– A set of 2 tracklets that may be observations of the

same object

• Orbit– A six parameter representation of the heliocentric path of

an object


Terminology Review: Detections, Tracklets, Tracks & Orbits


Terminology Review: SOT, HC, LC, DC,

• Single Occurrence Transient = SOT– A detection that is not at the same position as any other

known stationary object in the past 30 (TBR) days

• High Confidence Detection– A detection that has a high probability of being a real

object (~>5)

• Low Confidence Detection– A detection that has a high probability of being a real

object (~>5)

• Data Collection = DC– A generalized database


Terminology Review: Opposition, Sweet-Spots

Evening Sweet Spot Morning Sweet SpotOpposition


Terminology Review: Observing Cycle

• Observing Cycle = OC– Integer number incrementing 12:00pm HST on

day of full moon

• Synthetic Object– An artificial object with orbital and shape

parameters

• Derived Object– A synthetic or real object and its parameters

derived from observations


Selected Derived Requirements(from PSDC-530-001-03 – MOPS Software Requirements Specification)

3.2.2.1 Daily 15-body ephemeridesThe MOPS shall be capable of determining the astrometric location and apparent magnitude (to a precision equal to or exceeding the astrometric and photometric precision of the PS system) of 108 solar system objects for each day of the survey and provide error estimates on each value.



3.2.3.1 Attribution efficiency

The MOPS shall be >99% efficient at linking

≥ 2 detections within the low confidence (LC) SOT DC of a known moving object on the same night to the known orbit when the estimated error in the location is <15".



3.2.3.3 Intra-lunation linking efficiency

The MOPS shall meet the following minimum efficiency requirements at identifying multiple detections of the same unknown object detected on at least 3 nights within a lunation for different classes of solar system objects:

Object Type Minimum Efficiency

PHO 95%

MB 98%

KBO 99%



3.2.3.5 Orbit identification efficiency

The MOPS shall be >98% efficient at linking intra-lunation short-arc orbits of at least 10 days to other intra-lunation short-arc orbits of at least 10 days for the same object observed in other lunations or apparitions.



3.2.3.7 Low Confidence SOT False DetectionsThe MOPS shall meet the stated efficiency and accuracy requirements (3.2.3.1-3.2.3.6) when the false detection rate for LC SOTs is 2•105/deg2.

3.2.3.8 High Confidence SOT False DetectionsThe MOPS shall meet the stated efficiency and accuracy requirements (3.2.3.1-3.2.3.6) when the false detection rate for HC SOTs is 2•102/deg2.


External Interfaces


Selected External Interface Reqs(from PSDC-530-001-03 – MOPS Software Requirements Specification)


Other Important Requirements

• Supplementary requirements on other Pan-STARRS sub-systems in order that MOPS may meet its primary requirements


Other Important Requirements(from PSDC-530-001-03 – MOPS Software Requirements Specification)

3.10.1.1.2 Efficiency parameterizationThe MOPS requires a measure of the detection efficiency (3.10.1.1.1) in each image for identifying SOTs (asteroids and comets) as a function of their magnitude and rate of motion.



3.10.1.2.1 Nearly stationary moving objectsThe search algorithm for single occurrence detections of moving objects with a stellar stationary PSF (e.g. ASTEROIDS) in PS-1 images shall have a detection efficiency (3.10.1.1.1) of >99% efficient for R24 magnitude detections moving at <1o/day.

3.10.1.2.2 Rapidly moving objectsThe search algorithm for single occurrence detections of moving objects with a stellar stationary PSF (e.g. ASTEROIDS) in PS-1 images shall have a detection efficiency (3.10.1.1.1) of >98% for R24 magnitude detections moving at 1o/day and <5o/day.



3.10.1.3.1 Nearly stationary moving objectsThe search algorithm for single occurrence detections of moving objects with a non-stellar stationary PSF (e.g. COMETS) in PS-1 images shall have a detection efficiency (3.10.1.1.1) of >98% for R24 magnitude detections moving at <1o/day.

13.10.1.3.2 Rapidly moving objectsThe search algorithm for single occurrence detections of moving objects with a non-stellar stationary PSF (e.g. COMETS) in PS-1 images shall have a detection efficiency (3.10.1.1.1) of >95% efficient for R24 magnitude detections moving at 1o/day and <5o/day.



3.10.1.5 Astrometric accuracyAstrometry of moving objects reported to the MOPS shall be no worse than 150% of the accuracy for stationary objects of the same integrated flux.

3.10.1.7 Photometric accuracySolar system object photometry reported to the MOPS shall be no worse than 150% of the accuracy for stationary objects of the same integrated flux.


Unlisted Important Requirement

N.N.N Scanning ModeAll PS survey fields shall be acquired as two pairs of images separated by a TTI±50%.


Top-Level MOPS Architecture

• Designed to meet MOPS requirements

• Designed to determine if MOPS meets requirements


Algorithms - Overview

• Necessary and sufficient algorithms so that MOPS may meet its primary requirements


Algorithms - Overview

• PSDC-500-003 ‘The TAO of MOPS’– Solar System Survey Simulator (SSSS)

• PSDC-500-004 ‘The MOPS Solar System Model’ – Solar System Model (SSM)

• PSDC-530-002 ‘Algorithm Design Description’– MOPS Algorithms (ADD)


Algorithms – SS Survey Simulator

• NOT necessary to MOPS function

• critical for MOPS testing and preliminary design

• critical for preliminary determination of Pan-STARRS solar system surveying strategy to meet primary requirements



• Realistic simulated surveying of opposition and sweet-spot fields

• Define opposition-centric ecliptic field locations and let scheduler schedule images on each night

• ‘simple’ weather model– Random 25% of entire nights are not usable



• TAO (Tools for Automated Observing)http://pan-starrs.ifa.hawaii.edu/project/MOPS/tao.html

• Efficiently schedules observations of fields subject to constraints on:– Number of images of each field (2)– Minimum survey altitude (20o)– Moon avoidance angle (45o)– Exposure time (30s)– Maximum Sun altitude (-15o)– Dome slew rate (5o/s)– telescope slew rate (5o/s)– Telescope settle time (0s)– Readout time (5s)

http://pan-starrs.ifa.hawaii.edu/project/MOPS/tao.html



Opposition660 fields

~4,360 deg2

Evening/Morning sweet-spots84 fields each

~550 deg2 each

TOTAL828 fields

~5,460 deg2

828 fields2 visits/night

3(4) nights/OC 40s/visit

=55(74) hours/OC

=6(8) nights/OC

Ecliptic Longitude w.r.t. Opposition

Ecl

ipti

c La

titu

de



• TAO schedules fields on a single night

• MOPS requires coordinated surveying within a lunation

develop wrapper Perl script to handle ‘weather’ and multi-night requirements


Algorithms – SS Survey Simulator• four separate regions:

– 2 sweet spots– 'high‘ and 'low' opposition region

• all surveying takes place between -8 and +8 days from new moon

• each (moving) field is visited 3 times per lunation• minimum time between re-visits

to the same region is 4 nights• to avoid the crescent moon

– evening sweet spot must be completed by day +4 wrt new moon

– morning sweet spot must start after day -3 wrt new moon



• sweet spots are given higher priority than opposition regions

• high opposition region has higher priority than the low region.

• the two sweet spots may be scheduled on the same night but if a sweet spot is scheduled no opposition region can be covered

• only one of the opposition regions may be covered on any night



• We will test effect of different survey strategies on meeting MOPS requirements:

– RegionsOpp only, SS only and ALL

– TTI15min and 30min

– Altitude surveying constraints (20o, 30o, 42o)

– nights/region (each night is 2 visits) 3 or 4



Evenin

g S

S

Opposi

tion

Morn

ing S

S



53371-57021-multi-ss-o :10 year sweet-spot and opposition survey for 2005-2014 (53371 < MJD < 57021).

53371-57021-multi-o :10 year opposition-only survey for 2005-2014 (53371 < MJD < 57021).

53371-57021-multi-ss :10 year sweet-spot-only survey for 2005-2014 (53371 < MJD < 57021).

53371-57021-multi-ss-o-4-3 :10 year sweet-spot and opposition survey for 2005-2014 (53371 < MJD < 57021) where the region is covered 4 times within each lunation and the minimum time between repeats is three days.

53371-57021-multi-o-4-3 :10 year opposition-only survey for 2005-2014 (53371 < MJD < 57021) where the region is covered 4 times within each lunation and the minimum time between repeats is three days.

53371-57021-multi-ss-4-3 :10 year sweet-spot-only survey for 2005-2014 (53371 < MJD < 57021) where the region is covered 4 times within each lunation and the minimum time between repeats is three days.

10 Year Simulations

http://dev.pan-starrs.ifa.hawaii.edu/project/MOPS/synthetic/surveys/53371-57021-multi-ss-o

http://dev.pan-starrs.ifa.hawaii.edu/project/MOPS/synthetic/surveys/53371-57021-multi-o

http://dev.pan-starrs.ifa.hawaii.edu/project/MOPS/synthetic/surveys/53371-57021-multi-ss

http://dev.pan-starrs.ifa.hawaii.edu/project/MOPS/synthetic/surveys/53371-57021-multi-ss-o-4-3

http://dev.pan-starrs.ifa.hawaii.edu/project/MOPS/synthetic/surveys/53371-57021-multi-o-4-3

http://dev.pan-starrs.ifa.hawaii.edu/project/MOPS/synthetic/surveys/53371-57021-multi-ss-4-3


Algorithms – Solar System Model

• Integral and essential element of MOPS

• Critical for development



• To test MOPS performance we require a realistic model of the solar system’s small bodies

• Test system before data becomes available

• Run SSM through the MOPS in parallel with the real data

• Verify how well we meet requirements



• Measure real-time efficiency of individual components– FindTracklets– LinkTracklets– Orbit Determination– Orbit Identification– Orbit Contamination



• All asteroid and comet types Near Earth Objects (NEO) including IEOs Main Belt Objects (MBO) Trojans (TRO) for all planets Centaurs (CEN) Trans-Neptunian Objects (TNO) Scattered Disk Objects (SDO) Short Period Comets (SPC) Long Period Comets (LPC) Oort Cloud Objects (OCO) Extreme objects (EXO)


Algorithms – Solar System Model• Synthetic model must match real

distribution of all observable objects detectable by Pan-STARRS

orbit and size distribution shape, rotation periods, pole orientations

+ ‘unusual’ orbits

e.g. hyperbolic interstellar, retrograde main belt, distant Earths, …


Algorithms – Solar System Model• Near Earth

Objects (NEO) including IEOs

• ‘Bottke Model’ + Rabinowitz

• 4 dimensional (a,e,i,H)

• From 5 source regions


Algorithms – Solar System Model• Main Belt

Objects (MBO)

• Complete to H~14.5



Objects (MBO)

• Highest statistics population

• Correlations between orbital elements

Difficult to model



Objects (MBO)



Objects (MBO)

• Angular element distributions



Objects (MBO)

• Angular element correlations



Objects (MBO)

• Algorithm:

107 objects



Objects (MBO)


Algorithms – Solar System Model• Trojans

(TRO) for all planets

• NOT bias corrected



• Trojans (TRO) for all planets

• NOT bias corrected


Algorithms – Solar System Model• Trojans (TRO) for all planets

• Semi-major axis, eccentricity, inclination, mean anomaly and longitude of perihelion were randomly generated using the distributions given in table \ref{tab.trojan.fits}.

• The longitude of the node was randomly generated in the range [0o,360o)

• The argument of perihelion was calculated.

• An apparent magnitude was selected using the distribution given in Eq. \ref{eq.trojan.mag.fit} and assumed to be the apparent magnitude at perihelion.

• The absolute magnitude was calculated.

• repeat till 160,000 objects were generated in each trojan cloud.


Algorithms – Solar System Model• Centaurs (CEN)


Algorithms – Solar System Model• Centaurs (CEN)• Bin the normalized (a,e) distribution into (1000,1000) bins.

• Determine the fraction, $f(a,e)$, of the Centaur population in the bin.

• Determine the maximum possible absolute magnitude (Hmax) that an object at this perihelion distance, p=a(1-e), can have and still be above V=24.5.

• Determine the number, N(a,e,Hmax), of Centaurs with H< Hmax in the (a,e) bin.

• For each of the N(a,e,Hmax) Centaurs:– Generate a semi-major axis and eccentricity randomly within the bin.– Generate an inclination according to the model– Generate an absolute magnitude distributed like 100.61H.– Generate the three orbital orientation angular elements randomly in the range

[0,360).


Algorithms – Solar System Model• Trans-Neptunian Objects (TNO)

• we generate a set of orbits that are the results of assumed dynamical processes rather than attempting to model a poorly known population

• model the migration of the outer solar system into a near planar disk of small bodies

• started with ~10,000 objects in a disk from 15-50 AU. • Number density falls like a-2

• slightly excited eccentricities of 0.,0.025,0.05 • i=0o

• outer planets started at a ~ 5.4,8.5,16.2,23.1 AU and run for 108 years. • forced migration of ~ -0.15, 1.0, 3.0, 7.0 AU 5M years

• synthetic objects for our solar system model are time snapshots of the surviving objects corrected for orbital position w.r.t. Neptune.


Algorithms – Solar System Model• Scattered Disk Objects (SDO)• Randomly pick perihelion distance from the bias-corrected distribution in the range [27,45] AU.

• Randomly pick the eccentricity from the bias-corrected distribution in the range [0.2,1.)

• Calculate the semi-major axis and if a>500 AU re-pick q and e.

• Randomly pick the inclination from the bias-corrected distn in the range [0o,90o] AU.

• Randomly generate the three orbital angles in the range [0o,360o]

• Randomly generate the apparent magnitude from the observed distribution

• Calculate the absolute magnitude assuming the object is at perihelion

• Calculate the apparent magnitudes at the current epoch and once per year for the following 10 years. If the apparent magnitude becomes brighter than m=24.5 the object is observable by Pan-STARRS and included in the synthetic population.

• Repeat the procedure until a total of 20,158 objects are generated in the synthetic population


Algorithms – Solar System Model• Scattered Disk Objects (SDO)• Rough bias correction

KNOWN

DEBIASED

FIT

SYNTHETIC


Algorithms – Solar System Model• Short Period Comets (SPC) &

Long Period Comets (LPC)• NOT bias corrected

• Synthetic (q,e,i) created from fit to observed (q,e,i)

• Angles generated randomly• N(>R) ~ e0.04(R-24.5)

• Test if object becomes visible to Pan-STARRS in 10 years

• Repeat till 10,000 objects are generated


Algorithms – Solar System Model• Short Period Comets (SPC)

KNOWN

FIT

SYNTHETIC


Algorithms – Solar System Model• Long Period Comets (LPC)

KNOWN

FIT

SYNTHETIC


Algorithms – Solar System Model• Extreme objects (EXO)

• Grid objects (e.q. evenly spaced objects in an a,e,i grid).

• Oort cloud objects and giant distant planets

• Extended inner earth objects• Retrograde main belt objects• Interstellar interlopers

To be implemented


Algorithms – Solar System Model• Shapes, Rotation periods & poles

• Still TBD but…

We have H for each synthetic objectGenerate albedoDetermine sizeGenerate matching triaxial ellipsoidsGenerate pole directionGenerate rotation period


Algorithms – Solar System Model• Summary:

• To develop AND test MOPS performance we require a realistic model of the solar system’s small bodies

• Test system before data becomes available

• Run SSM through the MOPS in parallel with the real data

• Verify how well we meet requirements


Algorithms – ADD

• Other algorithms necessary for MOPS to meet its requirements


Algorithms - ADD

• Algorithm Design Description (ADD)– Multiple hypothesis testing– kd-trees – Initial Orbit Determination (IOD) – Differential Orbit Determination (OD) – Ephemeris Generation – Shape Modelling – Photometric Models


Algorithms - ADD• Multiple Hypothesis Testing• A combinatoric problem in which

many different possible hypotheses must be tested for consistency with a model– Linking detections (FindTracklets)– Linking tracklets (LinkTracklets)– Field detections (FieldProximity)– Orbit identification (OrbitProximity)


Algorithms - ADD• Multiple Hypothesis Testing


Algorithms - ADD• kd-trees • The kd-tree algorithm may be thought

of as a traditional binary search extended to a k-dimensional space (hence the name). It dramatically reduces the number of computations, and therefore speeds the search time, for an entry in a k-d table meeting specified requirements. The algorithm will be employed at multiple stages within MOPS processing


Algorithms - ADD


Algorithms - FieldProximity•Given: coarse UT 0h

ephemerides for several nights and fields acquired on a single night

•Want: which objects are in which fields, within some slop radius

•Brute force: for each field (up to 1000), interpolate every orbit and calculate which ones intersect the field+slop radius

•KD-Tree: create a RA/DEC/time index for the field locations, and for each orbit, traverse the tree to find nearby fields


Algorithms - FindTracklets•Given: 3000 HC

detections in a field

•Want: pairs/tuples of close detections in time/space

•Brute force: combinatorically find all pairs of “close objects” in time and space among thousands of detections

•KD-Tree: create a RA/DEC/time index of detection locations, and search tree for close detections


Algorithms - LinkTracklets

•Given: many thousands of tracklets from three nights

•Want: all viable combinations of tracklets that are viable tracks (linear or quadratic in sky-plane motion)

•Brute force: combinatorically examine all tuples of tracklets and select viable ones

•KD-Tree: create a RA/DEC/time index of tracklet locations, and search tree according to estimated velocity of tracklets


Algorithms - OrbitProximity•Given: 10 million derived

orbits, hundreds or thousands of proposed orbits

•Want: which proposed orbits are very similar to derived orbits

•Brute force: manually compare orbital elements for each proposed orbit against every derived orbit

•KD-Tree: index the derived orbits in six dimensions, and look up proposed orbits in this index


Algorithms - ADD• kd-trees


Algorithms - ADD• Initial Orbit Determination (IOD)• When no pre-existing orbit exists for a set

of detections an initial orbit may be determined assuming that there are only two gravitationally interacting bodies in the solar system - the Sun and the detected object. The calculation of the 2-body orbit (with six free parameters) from at least 3 angles-only (RA, Dec) detections provides an initial estimate of the osculating orbit elements for the object.


Algorithms - ADD• Initial Orbit Determination (IOD)

Temporarily provided by 3rd party SW- FindOrb- gorbit- knobso

Developing internal IOD based on JPL SW


Algorithms - ADD• Differential Orbit Determination (OD)• Once the IOD exists for a set of

detections it is possible to improve the orbit elements in the sense of minimizing the residual between the actual and predicted positions for the object. The procedure by which the orbit is fit to the detections is known as differentially correcting the orbit.


Algorithms - ADD• Differential Orbit Determination (OD)


Algorithms - ADD• Ephemeris Generation (EPHEM)• Given an orbit (with associated error

estimates on the elements) and time and location of observation it is possible to predict the apparent position of the object on that orbit. The set of predicted observed parameters (perhaps including brightness, position, distance, rate of motion, etc.) is known as an ephemeris.


Algorithms - ADD• Ephemeris Generation (EPHEM)


Algorithms - ADD• OD & EPHEM


Algorithms - ADD• Shape Modelling • A method of describing the shape of

a 3-d convex body based on triangular facets.

• Accurately modelling light curve variations allows MOPS to assess it’s efficiency and ability to meet primary requirements


Algorithms - ADD• Shape Modelling


Algorithms - ADD• Photometric Models

• A method of predicting the brightness of objects– Asteroids– Comets

• Two techniques– Simple (H & G)– Complex (from shape model)



– Simple (H & G)



• Complex (from shape model)

– Shape: Each object will be described as a 3 dimensional polyhedron with any number of triangular facets, and corresponding vertices. Most synthetic objects will be triaxial ellipsoid converted to corresponding convex shapes, but a subset of the largest objects will have more complex and realistic shapes.




– Albedo: each of the facets has an albedo parameter that defines how much of the light coming from the Sun is reflected. Usually all the facets will have the same albedo value.




– Spin state: given as pole direction in ecliptic coordinates and the sidereal period.




– Orbital state: gives the position of the asteroid with respect to the Sun and the observer.



– Complex (from shape model)

n

Eo

E

To E

arth

To Sun

norm

al




ds

LambertLommel-Seelinger




• For the sake of convenient inversion, the phase function multiplies the sum of the single and multiple scattering terms.

• An exponential and linear model is a versatile choice for this purpose.

• a and d are the amplitude and scale length of the opposition effect, and k is the overall slope of the phase curve .




where r and are the object’s distance from the Sun and observer, respectively, and H is an offset magnitude to ensure the object has the proper HM(1,1,0).



– comets


Software Design: Overview

• Software must be designed to allow MOPS to meet its primary requirements

• Must be designed within existing framework, be consistent with IPP and PSPS operations.

• Must be designed within budget constraints



• Databases• Software Subsystems• Incorporation of 3rd party software• Hardware Implementation



• MOPS-wide design decisions• Architectural design components• Detailed design decisions


Software Design: Operational States


Software Design: I/O• INPUT (DIRECT)

– IPP metadata and detections data

• INPUT (INDIRECT)– JPL position and velocities and orbits– MPC detections and orbits– Shapes, poles, spin rates from other sources

• OUTPUT– MOPS will provide running output of its processing so

that instantaneous status and efficiency can be internally monitored

– Push output to the PSPS– Push detections to the MPC, JPL, AstDys


Software Design: Data Collections

• There is no external access to internal MOPS data collections.

• All user access to moving object data will be through the PSPS


Software Design: Atomicity


Software Design: Availability

• The MOPS design will allow for 97% uptime (four hours/week downtime).

• The MOPS pipelines will execute continuously.

• All MOPS internal status changes will be effected via atomic operations.


Software Design: Components

• Two independent pipelines– Detections and Tracklets– Linking and Orbit Determination

• MOPS components are divided into – execution units

• perform discrete blocks of processing and/or calculation

– class modules• encapsulate business logic to represent and

manipulate MOPS fundamental concepts such as fields (metadata), detections, tracklets and derived objects.



• Detection and Tracklet Controller • Linking and Orbit Determination Controller • Orbit Determination

– Initial Orbit Determination – Differential Corrector

• Ephemeris Generator • FieldProximity • FindTracklets • LinkTracklets • OrbitProximity



• MOPS Internal Database • Fields DC • Low Confidence SOT DC • High Confidence SOT DC • Tracklets DC • Derived Objects DC • Synthetic Objects DC • Shape Model • Efficiency Determinator • Graphical User Interface



• Detection and Tracklet Controller(DTCTL)– a program representable as a finite state machine that will

be responsible for controlling the execution of the Detection and Tracklet pipeline.



• MOPS Internal Database(PSMOPS + LCSOT)– consists of definitions, templates, driver software, utility

software, interface software and configuration files related to the operation of the database housing the MOPS data collections.



• MOPS Internal Database(PSMOPS)– The MOPS will maintain its own copy of all data

collections relevant to MOPS operation and will push results to PSPS.



• Fields DC(FIELDSDC)– consists of database table definitions and interface code

to query and manipulate the contents of the MOPS Fields (IPP Metadata) data collection.



• Low Confidence and High Confidence SOT DCs (LCSOTDC and HCSOTDC)– consists of database table definitions and interface code to

query and manipulate the contents of the MOPS Metadata Low-Confidence and High-Confidence data collections.



• Tracklets DC(TRACKLETSDC)– consists of database table definitions and

interface code to query and manipulate the contents of the MOPS Tracklets data collection.



• Derived Objects DC(DODC)– consists of database table definitions and interface code

to query and manipulate the contents of the MOPS Derived Object data collection.



• Synthetic Objects DC(SSMDC)– consists of database table definitions and interface code

to query and manipulate the contents of the MOPS synthetic Solar System Model data collection.



• Shape Model (SHAPE)– consists of source code, libraries and database table definitions

to calculate magnitudes from a shape model definition, calculate shape models from observed magnitudes (light curves), and query and manipulate the Shape Model DC.



• FieldProximity– associate large lists of objects with multiple (RA,

DEC and time) coordinates with a smaller list of fields with (RA, DEC, time) coordinates.



• FindTracklets– will examine an entire set of detections present in a Pan-

STARRS field and return a list of tracklets. A tracklet is a small set (2, 3, or 4 usually) of detections that are close together in RA, DEC and time and are candidates for being the same moving object.



• LinkTracklets– examine a set of tracklets belonging to multiple nights,

usually during a single observing cycle, and return a list of tracks. A track is a set of tracklets that are candidates for describing the motion of a single moving object.



• OrbitProximity– given a list of orbits and their orbital

parameters, return a list of similar orbits from a large list of orbits.



• Ephemeris Generator(EPHEM)– Produce an ephemeris for either a MOPS derived

object or an arbitrary set of six orbital parameters and a magnitude.



• Linking and Orbit Determination Controller(LODCTL)– a program representable as a finite state machine that will

be responsible for controlling the execution of the Linking and Orbit Determination pipeline.



• Orbit Determination(MOPSOD)– employ IOD and differential correction to

produce a six-parameter position and velocity from a set of detections.



• Initial Orbit Determination(IOD)– The IOD module will produce a 2-body approximate orbit

given a set of MOPS detections



• Differential Corrector(DIFFCOR)– determine a minimum-residual orbit for a

given set of detections.



• Efficiency Determinator– Repository for routines and data used to assess

real-time and long term MOPS performance.



• Graphical User Interface(GUI)– consists of all code, static and dynamic web page

definitions and configuration information required to produce the web-based MOPS operator's console.


Software Detailed Design: DTCTL

Responsible for

• verifying the presence of new input data,

• dispatching execution units to perform processing,

• verifying successful return codes from execution units.

Operates at a quantum unit of ‘field’

dtctl-tree.eps



• for MJD calculate coarse (0h UTC) ephemerides for all synthetic and derived objects for MJD - 0.5, MJD and MJD + 0.5



• Execute FieldProximity to associate coarse ephemerides with nearby acquired fields for that night.



• SYNTHETIC OBJECTS: Calculate accurate ephemerides associated with each field, and filter out objects not present due to chip gaps, streak removal, dead pixels, etc. in the field.

• DERIVED OBJECTS: Calculate accurate ephemerides associated with each field and attribute tracklets



• Identify derived objects and non-detections in the field



• Insert synthetic detections



• Extract HC detections



• Execute FindTracklets on each field and store tracklets in Tracklets DC.


Software Detailed Design: LODCTL

• Retrieve all unlinked tracklets for fields to be processed



• Execute LinkTracklets to create proposed tracklet linkages (tracks)



• Perform a two-body then differential orbital determination on all tracks.



• Look for precoveries and non-detections in the previous OC and refine the orbital parameters using new detections



• Execute OrbitProximity to find matches to derived objects.



• For new (unmatched) orbits, assign a MOPS base-62 (A-Z,a-z,0-9) designation, and update the tracklets and derived objects DCs with the new orbits.


Software Design: MOPSOD


Software Design: FieldProximity

• two critical MOPS tasks: – nightly ephemeris generation of

synthetic objects– searching for derived objects in

new input and previously acquired fields.

• uses KD-trees to associate positions of moving objects with fields

• ‘field’ is generalized to any circular region with an arbitrary radius on the celestial sphere.


Software Design: LinkTracklets

• uses KD-trees to locate candidate linkages of tracklets acquired over many nights.

• LinkTracklets links tracklets to form tracks

• Tracks then pruned by linear or quadratic model


Software Design: DC Class Hierarchy


Software Design: Hardware

• Hardware configuration must be designed to allow MOPS to meet its primary requirements

• Must be designed within existing framework and budget



• networked industry-standard GNU/Linux 2.4 single-CPU or multiple-CPU systems capable of TBD MIPS/node.

• Nodes will be networked using TCP/IP over 1000BaseT Ethernet.



• Data Collections

– will reside in an Oracle 10g database instance named PSMOPS.

– Storage for the LCSOTDC, which constitutes 99.9\% of the storage requirement for the MOPS DCs, will reside in a federation of ``fat'' nodes running Pan-STARRS IPP Image Server/Idata software.



• The MOPS Detection and Tracklets Controller (DTCTL), Linking and Orbit Determination Controller (LODCTL), and operator console will reside on three redundant identically-configured Standard class PCs.

hwutilization.eps



• redundant design allows the MOPS to easily dispatch 1000 IPP metadata fields per night, respond to operator input within one second, and achieve 97% uptime

hwutilization.eps



• Database Host will be a Server-class PC running Oracle 10g database software. Attached to this host will be networked storage containing 5TB storage for all MOPS data collections.

hwutilization.eps



• System-wide general storage and database files for all data collections other than the LC SOT DC will reside on a network storage device with 5TB of storage. I/O to and from the storage device will be 1000-BaseT or FibreChannel

hwutilization.eps



• General-purpose MOPS processing (FieldProximity, FindTracklets, LinkTracklets, OrbitProximity) will be performed on an 8-node cluster of Computation-class PCs.

hwutilization.eps



• Ephemerides and Orbit calculation will be performed on 6- and 8-node clusters of Computation-class PCs.

hwutilization.eps



• The LC SOT DC will exist as a federated cluster of ‘fat’ nodes running IPP IData Image Server code which provides a mechanism for redundant copies of LC SOT data to co-exist on multiple nodes.

hwutilization.eps


Software Design: Hardware• Summary

Node Type Required

Standard 3

Computation 22

Server 2

Fat TBD


MOPS Development Plan

• MOPS for PS-1development plan is designed to allow MOPS to meet its primary requirements by late 2006


MOPS Development Plan

• Timeline

• Documentation

• Current Component Status

• Development & Testing plan


MOPS Timeline: Project

TODAY


MOPS Timeline: Simulations

TODAY


MOPS Timeline: PS1• This is not in current project timeline

PS1 First Light


MOPS Status: Documentation• Critical Documentation

Complete & Evolving

PSDC-530-001: Software Requirement Specification PSDC-530-002: Algorithm Design Description PSDC-530-003: Software Design Description

Not started

o Software Version Descriptiono Sub-system Test Plano Sub-system Maintenance Plano Software User Manual


MOPS Status: Documentation• Supplementary Documentation

PSDC-500-001Orbit Determination Ephemeris Software

PSDC-500-003Solar System Survey Simulation

PSDC-500-004Solar System Model


MOPS Status: Publications• None to date

• Planning a series of papers:

MOPS-1: The Pan-STARRS Solar System Model MOPS-2: The Pan-STARRS Solar System Survey Simulation MOPS-3: Linking Pan-STARRS Solar System Detections MOPS-4: Pan-STARRS Detection and Orbit Determination Efficiency

• Then, as Pan-STARRS begins operations, a summary and update of all the above:

MOPS-5: Pan-STARRS Moving Object Processing System Operations


MOPS Status : Components

• Detection and Tracklet Controller (DTCTL)– Under development– May use IPP controller/scheduler



• Linking and Orbit Determination Controller(LODCTL)– Under development– May use IPP controller/scheduler



• MOPS Internal Databases (PSMOPS)– Delivered by SAIC– Operational– Continuing improvements



• Low Confidence SOT DC (LCSOTDC)– Not developed– Unimplemented and developing code– No hardware



• Shape Model (SHAPE)– Not Delivered by SAIC– Developing code



• FieldProximity / FindTracklets / LinkTracklets / OrbitProximity– Delivered by CMU (Kubica)– Operational and undergoing continuing tests– Kubica visiting May 23 – June 3 to improve interface and

operations



• Orbit Determination (MOPSOD)– Under development– Preliminary version is operational



• Initial Orbit Determination (IOD)– Under development by Grav– Currently using ‘mongrel’ 3rd party software:

• FindOrb• Gorbit• knobso



• Differential Corrector (DIFFCOR)– Delivered by JPL– Operational– Currently in initial testing phase



• Ephemeris Generator (EPHEM)– Delivered by JPL– Operational– Currently in initial testing phase



• Efficiency Determinator– Almost non-existent– Need full design, algorithms and operations

specification



• Graphical User Interface (GUI)– Non-existent– Need full design & operations specification


MOPS Status : Component Summary

Component Status

Detection and Tracklet Controller Under development

Linking & Orbit Determination Controller

Under development

Initial Orbit Determination Under developmentCurrently using SW with strange pedigree

Differential Corrector Delivered & Operational

Orbit Determination Under development

Ephemeris Generator Delivered & Operational

FieldProximity Delivered, Operational, Revising

FindTracklets Delivered, Operational, Revising

LinkTracklets Delivered, Operational, Revising

OrbitProximity Delivered & Un-tested



Component Status

MOPS Internal Database Under development

Fields DC Delivered, Operational, Revising

Low Confidence SOT DC Under development

High Confidence SOT DC Delivered, Operational, Revising

Tracklets DC Delivered, Operational, Revising

Derived Objects DC Delivered, Operational, Revising

Synthetic Objects DC Delivered, Operational, Revising

Shape Model Not available

Efficiency Determinator Not developed

Graphical User Interface Not developed


MOPS Test Plan

• MOPS testing is integral to its development through the continuous use of synthetic data

• We will constantly compare MOPS performance to the primary requirements


MOPS Test Plan• We have already tested our preliminary

pipeline through the following steps:

solar system model solar system survey simulation intra-night linking (FindTracklets) inter-night linking (LinkTracklets) Orbit Determination (OD)

• Initial Orbit Determination (IOD)• Differential Correction (DIFFCOR)


MOPS Test Plan• not yet tested:

inter-lunation linking orbit identification

• However

– Preliminary indications of orbit determination accuracy (with 3 nights of pairs of detections) are excellent

– Preliminary indications of inter-lunation ephemeris prediction are excellent


MOPS Test Plan: SimulationsEvening Sweet Spot Morning Sweet Spot

Low Opposition High Opposition


MOPS Test Plan: SimulationsOne Solar System Survey Cycle


MOPS Test Plan: Simulations

Opposition motion



Sweet spot motion


MOPS Test Plan: SimulationsRecovery Estimation Error

(Opposition)


MOPS Test Plan: SimulationsRecovery Estimation Error

(Sweet Spot)



1/3 arcmin2

Recovery Estimation Error(Sweet Spot)



TypePresent

Findable Clean OD Overall30 day AREE

NEO 283 37%100.0%

72.4% 72.4% 70"

MB 1684 55% 99.7% 99.9% 99.6% 2.43"

Trojans 1256 42% 99.8% 97.1% 97.0% 4.03"

Centaurs 92 63%100.0%

100.0%

100.0% 1.08"

TNOs 2494 60%100.0%

54.0% 54.0% 0.81"

SDOs 485 54%100.0%

76.8% 76.8% 0.48"

Comets 35 49%100.0%

100.0%

100.0% 3.79"

NEO (real) 81 58%100.0%

89.4% 89.4% 68.97"

Total 6410 54% 99.9% 76.7% 76.7% 4.5"

Linking and Orbit Determination EfficiencySSM = MB/100 + Everything else

Evening Sweet Spot (OC=61)Multi-Pass, lin_thresh=0.1 quad_thresh=0.1



TypePresent


NEO 345 44% 99.3% 74.7% 74.2% 80.86

MB 1697 59% 99.7% 99.8% 99.5% 0.74

Trojans 4286 44% 99.8% 89.5% 89.3% 0.99

Centaurs 123 50%100.0%

100.0%

100.0% 0.93

TNOs 3025 51% 99.7% 48.6% 48.4% 1.25

SDOs 522 47% 99.6% 75.6% 75.3% 0.49

Comets 22 64%100.0%

85.7% 85.7% 1.42

NEO (real) 98 45% 95.5% 83.3% 79.5% 38.97

Total 10118 49% 99.7% 77.9% 77.6% 3.53

Linking and Orbit Determination EfficiencySSM = MB/100 + Everything else

Morning Sweet Spot (OC=61)Multi-Pass, lin_thresh=0.1 quad_thresh=0.1



TypePresent


NEO 95 33% 87.1%100.0%

87.1% 0.39

MB 182 65% 97.5%100.0%

97.5% 0.25

Trojans 3866 79% 99.9%100.0%

99.9% 0.30

Centaurs 26 81%100.0%

100.0%

100.0% 0.23

TNOs 3 100%100.0%

100.0%

100.0% 0.15

SDOs 155 92%100.0%

100.0%

100.0% 0.12

Comets 11 64% 85.7%100.0%

85.7% 0.25

NEO (real) 8 50% 75.0%100.0%

75.0% 0.38

Total 4346 78% 99.6%100.0%

99.6% 0.29

Linking and Orbit Determination EfficiencySSM = MB/100 + Everything else400 deg2 near opposition (OC=61)

Multi-Pass, lin_thresh=0.1 quad_thresh=0.1


MOPS Test Plan

• Near term improvements

Introduce astrometric noise 1/10th MB model full density MB model other solar system survey modes

30min TTI 4 nights/lunation opposition & sweet-spot only

inter-lunation and inter-opposition linking


MOPS Test Plan

• Final goal:

MEET REQUIREMENTS


Risk Assessment:

WILL MOPS MEET ITS REQUIREMENTS?

WHAT ARE THE RISKS?

WHAT ARE THEIR IMPACTS?

WHAT IS OUR RISK REDUCTION PLAN?


Risk Assessment: Telescope

• Telescope design, location, dome must allow surveying to small solar elongation

Provide telescope engineers solar system survey requirements on altitude-azimuth for simulated surveying at small solar elongation

Risk

Impact

Risk reduction plan

• reduced PHO detection efficiency• increased time to meet PHO requirements


Risk Assessment: Telescope

• Telescope optical system may not allow surveying at low altitudes (mechanically and optically)

Encourage development of Atmospheric Dispersion Compensator (ADC)

Ensure that telescope/optical designers are aware of low altitude surveying requirements

Risk

Impact• reduced PHO detection efficiency in sweet-spots• increased time to meet PHO requirements

Risk reduction plan


Risk Assessment: Camera

• Nothing MOPS-specific

None

Risk

Impact

Risk reduction plan

None


Risk Assessment: OTIS

• All fields in all survey modes must be acquired at least twice per night

• The maximum time separation between two of the images must be less than TTImax

Ensure that these specifications are in the OTIS requirements

Confirm that OTIS simulator surveys in this mode

Risk

Impact

Risk reduction plan

Unable to function


Risk Assessment: OTIS

• Solar system surveying mode must provide at least 3 (perhaps 4) nights of detections separated by a total of no less than 6 and no more than 12 nights (TBR)

• at least one pair of nights must have a separation of between 3 and 5 nights (TBR)

Ensure that these specifications are in the OTIS requirements

Confirm that OTIS simulator surveys in this mode

Risk

Impact

Risk reduction plan

Unable to function


Risk Assessment: IPP

• Must efficiently detect ASTEROIDS• Must determine efficiency w.r.t. flux, motion, etc.• How do we determine if there is a problem?• Is it IPP or MOPS causing reduction in efficiency?

Verify that minimum ASTEROID detection efficiency is an IPP requirement

Ensure that IPP is tested on ASTEROID detections

Ongoing discussion with IPP members

Risk

Impact

Risk reduction plan

Major

Improper determination of MOPS efficiency

Unable to bias-correct data


Risk Assessment: IPP

• Must efficiently detect COMETS• Must determine efficiency w.r.t. flux, motion, etc.• How do we determine if there is a problem?• Is it IPP or MOPS causing reduction in efficiency?

Verify that minimum COMET detection efficiency is an IPP requirement

Ensure that IPP is tested on COMET detections

Ongoing discussion with IPP members

Risk

Impact

Risk reduction plan

Major

Improper determination of MOPS efficiency

Unable to bias-correct data


Risk Assessment: SAIC

• Slow turnaround time on DC development cycle

Working with SAIC to reduce development cycle

Risk

Impact

Risk reduction plan

• Schedule delays• Wasted time waiting for implementation


Risk Assessment: PSPS

• Nothing MOPS-specific

None

Risk

Impact

Risk reduction plan

None


Risk Assessment: MOPS Design

• All MOPS components have prototypes that are being tested on synthetic data BUT– NOT tested at full sky-plane density– NOT tested with astrometric & photometric errors– NOT tested with false detections (noise)

Once pipeline is fully operational we will scale up the synthetic data to incorporate these effects and monitor MOPS efficiency as they are added

Continuing improvement of solar system model, survey simulator and inclusion of ever-more realistic detector performance

Collaboration with Milani developing parallel and very different linking algorithms

Risk

Impact

Risk reduction plan

Increased computing time

Increased computing power

Reduced detection efficiency


Risk Assessment: MOPS Design

• Reliance on 3rd party software(IOD, OD, FindTracklets, LinkTracklets, FieldProximity, OrbitProximity)

Use 3rd party SW with good pedigree (JPL)

Develop test suites for 3rd party SW under realistic but synthetic conditions

Reduce reliance on 3rd party SW (e.g. IOD)

Sign no-revoke contract with consultants

Risk

Impact

Risk reduction plan

• If consultants stop working with us we have no backup, no opportunity for algorithm improvement, no depth


Risk Assessment: MOPS Schedule

• PS-1 should deliver detections suitable for linking by late 2006

• Current schedule has MOPS for PS-1 operational in July 2006• MOPS schedule may be too agressive

If we believe project schedule none necessary

Continuous monitoring of MOPS progress by MOPS manager and PMO

Risk

Impact

Risk reduction plan

Schedule delays


Risk Assessment: MOPS Resources

• Reduced budget for collaboration with consultants

Working with PMO to address the problem

Risk

Impact

Risk reduction plan

Schedule delays

Inefficient algorithms

Reduced detection efficiency



• Too few FTE assigned to MOPS• Too much dependence on single SW engineer• Too much reliance on consultants


Attempt to co-hire SW engineer with LSST

Risk

Impact

Risk reduction plan

• Schedule delays• Unable to ensure that requirements are being met (e.g.

software coding standards, attending other group’s meeting)



• Mini-MOPS hardware system purchase delayed 6 months already

• $50K in current MOPS budget BUT no facility to store the system when purchased


Risk

Impact

Risk reduction plan

Schedule delays

Inefficient use of time


NO Impact!

NOT ENDTHE

MOPS

Intro. 2005 May 9MOPS Preliminary Design Review2 Preliminary Design Review The Pan-STARRS Moving...

Documents

Transcript of Intro. 2005 May 9MOPS Preliminary Design Review2 Preliminary Design Review The Pan-STARRS Moving...