From Start to Finish: Python for Space MissionsPaul Barre)1, Ciprian Berghea1, Chris Dieck1, Sco) Evans2, Charles Poole2, & Dan Veille)e1(1) U.S. Naval Observatory, Washington, DC(2) ComputaHonal Physics, Inc.

Abstract

JMAPS Focal Plane Simulator (Jsim)

The so'ware development process for many space observatories iso'en disjoint and ineﬃcient due to the use of mul:ple languages
during the diﬀerent phases of mission development. Code andalgorithms that are o'en developed using an interac:ve, array
language during the pathﬁnding eﬀorts of Phase A are o'en
rewriCen in a non‐interac:ve, compiled language for use in theproduc:on code for Phase C. This approach leads to ineﬃciency inboth development :me and cost and can introduce errors during therewri:ng process. Python is one programming language that can beused as a high‐level, array language and as an eﬃcient, produc:onlanguage. This paper shows how Python will be used during thediﬀerent phases of development of the Joint Milli‐Arcsecond
Pathﬁnder Survey (JMAPS) space mission with an emphasis on codeand algorithm reuse from one phase to the next.

The JMAPS Focal Plane Simulator (Jsim) is a Python applica:onthat is currently being develop to support requirements analysis
associated with the focal plane array. Known characteris:cs of thedetectors are included in order to understand their eﬀect on theastrometric and photometric sensi:vity of the mission. Read andphoton noise, variable point‐spread func:ons, satellite jiCer, andvaria:ons of instrument parameters such as focal length andorienta:on have been tested.

Planning & Scheduling Simulator
The JMAPS observing concept diﬀers from other astrometricsatellites by using a step‐and‐stare observing mode, whereas
Hipparcos and GAIA are scanning missions. The greater ﬂexibility ofthis mode has its costs in that ~10000 images must be scheduled
over an extended period (~1 year). The Planning & Scheduling
Simulator is an eﬀort to iden:fy the best observing methods and toevaluate various planning and scheduling applica:ons (both freeand commercial).

Joint Milli‐Arcsecond Pathﬁnder Survey (JMAPS)
The Joint Milli‐Arcsecond Pathﬁnder Survey (JMAPS) is a micro‐
satellite mission intended to update Hipparcos astrometry. With its
single aperture 19 cm telescope, JMAPS will access not only thebrightest stars observed by Hipparcos, but also extend Hipparcos
level milli‐arcsecond astrometry to 14th magnitude stars. Combining
JMAPS and Hipparcos data will provide proper mo:on informa:onat the level of a few tens of micro‐arcseconds per year for stars
brighter than 11 magnitude in the V band. Using a step‐and‐staremode concept, JMAPS can integrate longer for speciﬁc ﬁelds on thesky, which allows the JMAPS star catalog to :e directly to version 2of the Interna:onal Celes:al Reference Frame (ICRF2) by observing
the brightest quasars in the op:cal. The JMAPS program is in thedesign and development stage, with an expected launch in
mid‐2013.

!"#$%%&#$'

E,.81J)6$#40*/5$:")'!3&$-3$';'$-5&-$$6&-5'."#"'()'*+,,"-.'/0%&-1':.)'!3&$-3$';'$-5&-$$6&-5'."#"'!"#$%&'&B$()*)$;)2)3/5/2*$#40*/5$
C23/0*$+1=/612/$

D,-:29$#*)>-2$
E00/*$@"+FG$-,$EG#?HA$9)'!"#$%%&#$'
3+,,"-.8':>)'!3&$-3$';'$-5&-$$6&-5'."#"'2>)'!34$./%&-5'
6$7/$8#'2")'!34$./%&-5'
6$7/$8#'?")'@>8$6A"B+-'."#"'?3)'@>8$6A"B+-'8#"#/8'+6)22123$7$#.8/9:6123$#40*/5$F)'@>D$3#'."#"'()*)$I/=-01*-,4$:3)'!3&$-3$';'$-5&-$$6&-5'."#"';1001-2$<=/,)>-20$?/2*/,$@;<?A$?>)'*"%&>6"B+-'."#"'?)61K,)>-2$;-21*-,123'#40*/5$<)'=-5$8#'."#"'E)'!+/63$'."#"'C)'@>D$3#';'8+/63$'/0."#$8'?)*)6-3$D/2/,)>-2$#40*/5'2G)'*"#"%+58'()*)$+,-./00123$+1=/612/0$

L#H<$M1K,),4$!"#$%&'&'$()*)$+,-./00123$#40*/5$
JPQ'

RS#$6-"%'!N8#$,8'HI!J@K'!@*OLM*'!4"6$.'L"#"'!$6A&3$8'!3&$-3$'@0$6"B+-8'*$-#$6'HI!J@K'

L"#"'M-"%N8&8'*$-#$6'HI!J@K'!"#$%&'$

Figure 1 ‐ Ground System Data Flow Diagram

Figure 3 – A residual map from a global solu:on simula:on.
Squares show outline of images on the sky and small circles areposi:ons of reference starts.

Global SoluEon Simulator

Code Reuse: From Pathﬁnding To OperaEons

The JMAPS astrometric telescope has a ﬁeld of view of
1.56 square degrees, so >26000 images are required tocover the en:re sky once. JMAPS will observe the en:resky at least 72 :mes during the 3 year mission. For precise
astrometry, >500000 reference stars uniformly covering
the sky will be used to calculate the stellar and image
parameters, i.e., the posi:ons, proper mo:ons, andparallaxes of the reference stars and the posi:on,orienta:on, and scale of the images. This involves solving
for about 25 million parameters (~5 million for stars and~20 million for images). One approach to calcula:ng theseparameters is called Global Block Adjustment (GBA). All
parameters are calculated simultaneously by solving alarge sparse linear system. Figure 2 is a an example sparsearray containing ~400 parameters and ~2500 images.

As with all space missions, resource and schedule
constraints place a strong emphasis on produc:vity.
Reusing so'ware is one way to improve produc:vity
during mission design and development. In order toachieve this, a conducive environment for so'waredevelopment must be in place during the earliest
stages of the mission. This is when most so'waredevelopment is being done by scien:sts andengineers, who do not to know, nor care, about
so'ware development methodology. However, muchof the so'ware that they develop during this mission
phase can be reused in the opera:onal system.
Therefore, there is a strong desire to have aprogramming
languageanddevelopment
environment that is easy to use during the designphase and that is also eﬃcient enough for theopera:onal phase.
One aspect of a conducive development
environment is a high level programming language.
This language should provide an easy interface tomul:‐dimensional arrays, so that scien:sts andengineers can easily develop code for their analysis.
This language should also be object‐oriented, so thatthe shared libraries and u:li:es are well deﬁned,
robust, and easy to use. If properly designed, tested,and documented, most of the shared libraries andu:li:es can be reused in the opera:onal code. ThePython programming language meets these criteria.
In addi:on, there is copious evidence it increases
produc:vely by several hundred percent.

There are several methods for solving this type of sparse
system using direct and itera:ve (Krylov) solvers. The
Global SoluEon Simulator is one pathﬁnding eﬀort toinves:gate the best approach to solving this problem.
Figure 3 is a plot of a simula:on showing the varia:on ofthe residual error on number of images and the reference
star posi:ons. During opera:ons, the results of the Global
Solu:on will be used for long‐term (~1 year) planning andweekly scheduling of the satellite.

Figure 2 – Plot showing non‐zero elements (blue) of a global
block adjustment using the algorithm of Stock.

Mission Success and Ground Processing
JMAPS is unusual for a space mission in that the :mely processingof the data has a signiﬁcant eﬀect on the overall success of themission. This is because all images are directly related during theglobal block adjustment (see Global Solu:on Simulator). In order tominimize global systema:c errors, the results of the groundprocessing, speciﬁcally the global solu:on, are incorporated into
the planning and scheduling system on a periodic basis. This
creates a feedback loop among the Planning & Scheduling System,
the Data Management System, and the Data Processing System.
Figure 1 shows the ground system data ﬂow diagram. The core of
the system is the Planning & Scheduling System (PSS) and DataManagement System (DMS). These two systems form a feedbackloop in order to op:mize the long‐term (~1 year) observing plan.
The data ﬂow begins with the PSS, where the weekly schedules arecreated. The schedules are sent to the Mission Opera:ons Centerfor execu:on and also recorded in the DMS. When the science
data is ingested into the DMS, it is checked against the schedule fordiscrepancies, which, if necessary, are included in the next long‐term plan or weekly schedule.

Poster #4

Summary

Object Modeling and Shared CodeThe JMAPS program has made an eﬀort early in the mission todevelop code using Agile programming methodology. An important
aspect of this approach is to begin object modeling as soon as
possible by iden:fying and deﬁning class interfaces that arecommon to the various pathﬁnding projects. Currently, the three
pathﬁnding projects are progressing somewhat independently,
because they have diﬀerent near‐term objec:ves. In the future, thegoal is to begin integra:ng these projects into a larger system inorder to perform more accurate simula:ons of the mission. In
par:cular, there is a close associa:on between the Planning &Scheduling Simulator and the Global Solu:on Simulator. This
integra:on is most easily accomplished if each project is using acommon set of classes. Examples of the common classes that havebeen iden:ﬁed to date are: Catalog (DBCatalog, FileCatalog),
Satellite, Bus, Instrument, Telescope, Detector, and Scan
(MeridianScan, LongitudinalScan, etc.).

For this so'ware development approach to be fully successful
requires buy‐in by scien:sts and engineers early in the program,
since they are partly laying the groundwork for later so'waredevelopment. The concepts of object‐oriented design anddevelopment o'en take :me to grasp fully. In addi:on, classes thathave an intui:ve interface and are fully func:onal, take :me todevelop, test, and document (though the long‐term return usually
outweighs the ini:al investment). This :me may be beCer spent on
more immediate issues.
For the USNO ground segment por:on of the JMAPS program, weobviously believe that the approach to so'ware development
outlined in this poster is preferred, since a large por:on of theso'ware development must be done to support the extensive
simula:ons of the instrument and bus to assure mission success. It
is therefore reasonable to reuse this code in the opera:onal
system to increase produc:vity and minimize risk, since the corecomponents of the opera:onal system must be fully func:onal or
fully integrated into the mission by launch.

ADASS 2009