Professional Documents
Culture Documents
A National Mandate:
As illustrated in the figure below, each phase flows naturally into the
one following. Operations and data analysis typical result in new
scientific hypotheses, which requires new missions, new technology,
after which the cycle repeats.
D ata
B' C
D ata
Colle ctio n QLA
Plan A nalyze d
C' D ata
Q uick
B Look
F
M ission
P lan A
C'
D A rchive
S imula tion
O bserver's F
A'
P roposal &
Exper imen t G
F
G
R P
The NVO is chartered to provide the community with the recommended best
practiced for the developments at hand. This spans not only ranges of
technology readiness (perhaps focusing on only the highest TR levels)
but also addressing the needs of the observational and theoretical
astrophysical community.
The Universities Space Research Association (USRA) with its present and
recent programs to operate major NASA facilities such as the
Stratospheric Observatory for Infrared Astronomy (SOFIA), the Research
Institute for Advanced Computer Science (RIACS), the Center for
Excellence in Space Data and Information Sciences (CESDIS), and the
Lunar and Planetary Institute (LPI) understands the issues of the NVO
in detail. Furthermore, USRA foresees the need to involve actively the
national university community in the NVO initiative at an early stage.
Clearly, the dynamic interaction of the research and education that
characterizes the university academic environment will be an essential
component of the successful NVO program. USRA, with its 85 member
institutions, has the expertise necessary to pull the university
community together in support of the NVO program.
Awareness
Publish
Develop Analyze
Scientific
Proposal Data
Interpretation
Make
Observations
Review
Proposal
Flight
Planning
of the SOFIA DCS architecture and operating proto-type shows that the
core system has the capability to support the broader science cycle
The following items comprise the goals of the DCS as presented to the
SOFIA Science Council in December 1998:
In developing the DCS requirements and the DCS core prototype, USRA
finds a clear correspondence to the needs of the NVO. The fact that
the design has reached a level of maturity that enables the
construction of a full prototype for testing by the summer of 2001
provides a synergistic opportunity with NVO.
Using CORBA and XML as its foundations, then, the Data Cycle System
embodies the “continuous improvement” paradigm. As new image reduction
algorithms are developed, as new telescope instruments are created, as
new ways of planning and executing observations are formulated, the DCS
can easily incorporate these improvements. Additionally, these
improvements are additions to, not replacements of, the software
components that make up the system. It is important to maintain the
data and algorithms used in previous practice as a reference when
evaluating potential new methodologies. Continuous improvement and
mechanisms that enable it have been a part of the DCS since its design.
The DCS is a federation of software modules, implemented using CORBA
and communicating via XML. The DCS federation is grouped into five
functional domains. These domains are Data Acquisition, Data Reduction,
Data Storage, User Interaction, and the Task Library. We show in figure
3 the relationship of each domain. We describe the detail of all five
domains in Appendix A. of this paper. The elements within each
functional domain, or subsystem, implement a well-defined set of
interfaces to the rest of the system. In this way, the implementation
details of a given component are not important to other software
components in the system; indeed, those details are not known. This
object-oriented encapsulation of functionality is instrumental in
smoothly connecting software components developed by potentially
different developers at different times together into a cohesive whole
called the Data Cycle System.
The DCS is a flexible, capable, and powerful system that enables the
operation of an astronomical observatory. It is adaptable to future
improvements in instruments, computers, software, and the science needs
of astronomers.
For the NVO white paper development, USRA involved participation from
Eric Becklin (USRA), Sean Casey (USRA), Ian Gatley (RIT), Joel Kastner
(RIT), Jacques L’Heureux (USRA), Bob Krzaczek(RIT), Barry Leiner
(USRA), Mark Morris (UCLA), Harvey Rhody (RIT), and Peter Sharer
(Sterling Software). USRA’s involvement in SOFIA, RIT’s involvement in
the South Pole astronomy program, and UCLA’s participation in the Keck,
etc. combined with the joint experiences of the individuals involved
provide the foundation for URSA to move forward as a strong lead within
NASA’s NVO program.
The NVO will touch on all parts of the process of scientific inquiry
and will be the central system through which all data and processing
resources are accessed. The NVO will necessarily be distributed, to
connect geographically distributed users and geographically distributed
data sources. Indeed, a major challenge is the distributed and
heterogeneous character of the basic environment. Kepner and McMahon
[7] make a case that the NVO address all of the following elements: (1)
Acquisition and storage of raw data; (2) Data reduction; (3)
Acquisition and storage of detected sources and (4) Multi-sensor/multi-
temporal data mining. They note that “the NVO’s core data mining and
archive federation activities are heavily dependent on the underlying
data pipeline software necessary to translate the raw data into
scientifically relevant source detections.”
Furthermore an open architecture is required for any data system
serving the NVO; the community must be able to contribute to the
growing body of data calibration and analysis knowledge, as expressed
in algorithms and/or code, that is available to all NVO users.
References
[1] Guenter Riegler, “The Lifecycle of Space Science Missions,”
Research Division, Office of Space Science, NASA Headquarters,
September 13, 2000. http://www.aas.org/policy/NASALifeCycle.htm
[2] Jeffrey Linsky, “Final Report of the Task Group on Science Data
Management to the Office of Space Science”, October 23, 1996.
http://adc.gsfc.nasa.gov/~gass/linsky/report_available.html
[3]NASA Senior Review Reports:
2000 - http://spacescience.nasa.gov/codesr/results/SenRev00.PDF
1998 - http://spacescience.nasa.gov/codesr/results/SenRev98.PDF
1996 - http://spacescience.nasa.gov/codesr/results/SenRev96.PDF
Glossary:
Appendix A:
The Task Library works closely with the User Interaction subsystem in
supporting the imaging scientist using the DCS. The Task Library
provides the perceived intelligence of the DCS, coordinating the
actions of the various system resources (acquisition, reduction,
storage) in ways that satisfy user’s requests. A task may be simple
(“locate any data matching a specified target”) or complex (“conduct a
specified observation, reduce its data, store all intermediate and
final results, and email the observation’s authors the results of the
experiment when available”). Most importantly, the Task Library is
where past, present, and future “best practices” are embedded within
the DCS and made available to all of its users in a consistent, uniform
manner.
Appendix B:
The principles are listed here, and later in the Report we restate
these principles and our recommendations for successful space science
data management that flow from these principles and the new case
studies that we discuss later in this Report. The Task Group members
unanimously concur that the principles remain entirely valid today, and
they were used to help guide deliberations and recommendations.”
(d) ``Proper documentation should accompany all data sets that have
been validated and are ready for distribution or archival storage.''