As of April 13, the archive is now using the STScI Single Sign-On (SSO) identity manager.
To check on your account click
For more information about how accounts were transitioned click here.
Guidelines for Contributing High-Level Science Products to the
Mikulski Archive for Space Telescopes
The Mikulski Archive for Space Telescopes (MAST) welcomes the
contribution of high-level science products (HLSP) from the astronomical
community. The purpose of this document is to establish the guidelines
and policies for the contribution of HLSP to MAST. Note that
contributions of HLSP are now a requirement for the HST Treasury
and Legacy programs. The guidelines for archiving non-reduced data from
entire missions is a
If you wish to contribute HLSP or have any questions
concerning these guidelines please send mail to
Images, Spectra, Lists of Identified Spectral Lines, Catalogs, Time-series/Light-curves and Models/Simulations.
Observational data should be from either:
a MAST-supported mission (e.g. HST, FUSE, GALEX, IUE, EUVE etc.), or
ground-based observations closely related to a MAST mission.
Output produced from theoretical models should be:
closely related to the MAST data and
generally not available through another permanent archive.
Associated files with data deliveries: more |
A "README" file that includes file descriptions and documents details of data reduction,
pipeline processing version is required.
Plots relevant to the HLSP and quicklook/preview images in common
display formats such as PostScript, GIF, JPEG, PNG and PDF.
Thoroughly tested and well-documented, specialized, analysis
software relevant to the HLSP, Java applets, and other image
display software. (MAST will archive such software but will not accept responsibility for maintaining it).
The following data products will not be accepted:more |
Literature, including paper preprints and reprints
Analysis products several steps removed from the HLSP (e.g. IDL save-sets, intermediate products)
We described in detail the format and keyword requirements for the major data types/products (i.e.
images, catalogs, spectra, etc.). Please see the lists of required, recommended and optional
FITS keywords for:
hlsp - identifies the file as a community-contributed dataset.
project - An agreed upon name for the HLSP set. This name is also used as directory name and as a database keyword.
mission - Mission/missions acquiring the data. If two missions
used they should be separated by hyphens; models/simulations can be indicated here.
instrument - Instrument (e.g. acs-wfc). When not applicable as for GALEX data, a description
like imaging or spectra should be used. Resolution with units can be specified following a dash
(e.g. 'asc-30mas' indicates ACS instrument with 30 milliarcsecond resolution)
field-name - Field name or target as designated by the team.
Parts, counter numbers and epochs are allowed in this field and should be separated by hyphens.
If using multiple epochs, please use suffix 'ep' followed by a number (e.g. m101-ep1, m101-ep2).
Counters can be used when the same field is observered N times with same observing parameters.
For parts and counters, we
require leading zeros if more than 1 digit is needed (e.g. for 17 exposures of m101, each
file has field-name as follows: m101-01, m101-02 ... m101-09 ... m101-17; similarly, for more than 9
epochs: m101-ep01 ... m101-ep19). Please describe
your usage of field-name parts and counters within the README.
filter - Filter or filters used; or, grating(s) used. If HST this should be the
full filter/grating name (e.g. f606w or ge230m). If more than one filter is used,
separate the filters by hyphens (e.g. f606w-f814w).
version - Version Number, such as v#.# or v#. e.g. v2.4
product - Type of data as designated by the team
(models/simulations can be indicated here). e.g. img, drz, sci, weight, wht, cat,
modelmap, theory, sim, model, map and SED.
extension - Standard file extension. e.g. fits, txt, jpg
Use lower case characters only.
Use underscores ONLY to delineate between major fields (e.g. "goods_hst")
Within fields, dashes can be used as separators (e.g. "nicmos-nic3", "acs-wfc", "m101-01")
Version numbers can be specific to the project. We recommend teams use increased version numbers
to indicate data which are superseded; we will NOT keep older versions of datasets unless the team
explicitly requests this. Note that sometimes version number will denote single-EPOCH data as in GOODS;
this sort of information must be documented well with deliveries.
We recommend data are re-delivered with higher version numbers (better products);
we recommend that the newest deliveries contain both the re-processed data along with the
single-epoch data associated with these products, if applicable.
We recommend that images from different filters that have the same field-name should have matching
sizes and WCS coordinates. All images identified using the same field-name should cover the same
part of the sky. If there are multiple images covering different parts of an object, they should
have different field-names.
Data may be delivered electronically via ftp or on hard media such as external drive, DVD, or
CD, whatever is most convenient for you.
Some additional information may be useful at the time of initial contact:
Name of a Contact Investigator for the program, along with contact
information including email address and telephone number
Program of origin, e.g., HST/Treasury for HST Treasury program
data, or HST/GO for HST Guest Observer data; Contribution from an
ADP, LTSA or AISRP programs.
The program number, if there is any, e.g., HST proposal ID or ADP number
The primary target of the observations, e.g. "Hubble Deep Field" or "NGC1068"
A list of the missions from which the HLSP are derived, e.g., HST, IUE, and GALEX
References of up to three papers closely related to the
contributed HLSP, excluding authors, in standard format, e.g.,
2001, ApJ, 551, 23
It is important that contributors designate a contact person who will be
available to answer technical questions from users regarding details of
the actual observations, the processing techniques, or scientific
quality issues that MAST may not be in a position to answer. From
experience, we expect that such queries will be infrequent.
MAST will point to any websites the project or contributors set up but we will maintain
at least a small web presence on our website.
We work with contributing teams to put in place a suitable web presence.
We have developed
web sites ranging from full search interfaces (e.g.: FUSE Magellanic
Clouds Legacy Project and GALEX Atlas)
to simple pages pointing to the data and the teams website (e.g.:
CLASH, PHAT and UDF).
Some studies have shown that urls published in scientific journals have an average lifetime
of about 18 months. Maintaining the data and web pages at MAST will insure that
the site is active indefinitely.
Even if you are planning your own web site, we will want to archive the
data at MAST where we can provide a long-term home for it. We also
request that your web site points to the data here rather
than to a local copy. That ensures that the same data gets delivered
from both sites and allows us to easily and consistently track use of
the products from the Treasury programs. We can also more easily
integrate these valuable products with our other search interfaces.
If you have any questions regarding data deliveries, please feel free to contact us