We appreciate all the comments and questions in your survey responses.
If you left an email address we have responded to your concern or questions.
We are always eager to address issues and hear from you.
If you would like to use the archive in a new way and the current services don't provide
you with the tool that you need or you are having a problem with a service or tool we
please contact us through the help desk firstname.lastname@example.org
or by phone (410-338-4547) between 9:00 AM and 5:00 PM Eastern time.
We also provide a Suggestion Box for you to submit requests
Searches and Website navigation
Search by object class (IUE and FUSE style)
This is a perpetual request that we have attempted to address with the ability to upload a list of targets for searching and for the VIZIER/MAST cross correlation search.
This is a difficult task for several reasons. First the astronomical community does not agree on classification for any one target. The IUE and FUSE object classes were assigned by the
original Guest Observer and are therefore somewhat heterogeneous.
In the context of our VO work, we have begun to explore some means to consistently classify the pointed observations for spectral data to provide at least a consistent classification for all spectra.
While there is also some preliminary work starting as part of the Hubble Legacy Archive, this project is not a high priority for the first year of the HLA.
I would like to get the results in a text file (or CSV, Excel, etc.).
Almost all of the MAST Search forms permit you several output options including comma separated value (CSV), Excel and VOTable in addition to the default HTML. In the bottom third of most search pages are several output options. One of these is Output Format.
If there was a way to directly get up on the screen the publications that were written based on a particular archived data set, that would be extremely useful.
We do offer that service for most missions archived at MAST. For HST data, the link between the publication is at the program level, while other missions the link is at the dataset level. We have not yet begun to provide this service for GALEX papers but intend to in the future.
We can only do this when authors have clearly defined the data they used in the papers or who have responded to queries about this when asked, so there are some papers that are not linked.
On the search results page, there is a column called "Ref". This column will display the number of papers that have used this dataset or program. If you click on the number, you will get a page listing the papers with links to the article at the ADS and to another page which will show all MAST data used in that paper. This page is linked from the ADS where you can find it by clicking onthe "D" or the "Online Data" link.
I wish that there weren't so many layers in the web site. Almost every time I go to the site it is to search and download HST data. I think that sometimes the desire for mission equality at MAST has resulted in HST being buried with every other mission.
Website navigation is a topic we have had lots of discussions and thoughts about.
We do understand that the HST archive is the most utilized mission.
We apologize for the inconvenience and will re-think some of these navigation issues in the future.
I find the search forms etc. always are too crowded with too many options and buttons
MAST has a large number of users who wish to do all types of searches with a variety of options.
We have tried to include only the most used search parameters as called out options on the page,
while including the "User-specified fields" to permit you to search on any field that we have in our database.
None of the search parameters are required, so we hope that the perceived complexity can be tolerated by those that do not need it.
HTTP GET in GSC2.3 that takes decimal degrees, although I believe that is soon to be the case. GSC2.3 documentation is cryptic, slow, and well hidden.
A decimal degree query of GSC2 is planned to be implemented this summer (2006).
The documentation is now (we hope) easier to use following the recent update of the webpages.
I am having intermittent problems with your interface to the simbad name resolver. Your interface is stripping out '+' from object names, and may have other idiosyncracies that I have yet to identify.
Thank you for letting us know about this bug. After some investigation we determined that you were talking about the top level cross-mission search and fixed the error. When you have this type of problem, please let us know so we can fix it.
I have a problem with your 'abstract search' feature, at least for FUSE data. It will search the text of abstracts, but not program IDs. If I enter a program ID in the abstract search field, the search fails unless the program ID appears in the text of the abstract (which is usually the abstract of a program in a later Cycle that refers back to the program that was actually of interest to me).
The plan was to only search the actual abstract text from the abstract search box on the left navigation menu and to use the full form at http://archive.stsci.edu/fuse/abstract.html to search for other pieces of information such as proposal id or investigator name. However, we like the idea of being able to use the navigation search for all fields and will modify all the abstract search routines to search all columns when called from the navigation search box. However,
the full form will retain the ability to do more complex searches, that is allowing the user to use a NOT in the subsequent database query.
There were some comments concerning the GALEX data and website. We hope that you will
feel free to contact the archive help desk when something is confusing or giving you a problem.
First some general observations and comments about the GALEX mission and project.
The GALEX project is a survey mission.
Only a small percentage of observed point sources are directly resolvable by NED.
So, except for obvious queries like "M51," we recommend users input practice queries
as well known objects, e.g. that are likely to be included in the Nearby Galaxy Survey,
or as coordinates in their searches on the simple form. This suggestion is made liberally in the FAQs.
Caltech's GALEX processing pipeline does not track which individual objects
were observed before, except for objects that the Science Team tabulates
in its own catalogs. Moreover, even the so-called running Galex obj id
number differs from tile to tile (sky area). Thus, an object appearing in
two overlapping tiles can be referred to by different numbers in each of
them. A formal object name, e.g. GALEX J132953.7+471242, given in the
GALEX Explore pages, is an abstraction created by MAST alone to aid users
on our pages. We have asked the GALEX project, with some prodding to NED to help in
this effort, but they state that they are unable to set up the databases required
to interact with their pipeline and name their sources. Thus, the situation
is likely to remain this way until after the close of the mission. This
is explained in one of our FAQs, and is also discussed in our tooltip
when one mouses over the "IAU name" we provide on the Explore pages.
The GALEX project has provided no users' manual for data handling.
MAST has put an informational table together on the pipeline products
in a "Table 1" linked from several help pages.
This table was compiled
from the ICD, plus additional clarifications provided mainly
by Tim Conrow of the GALEX Project. We have no doubt that this table is
inadequate for many purposes and we welcome any comments or suggestions to make this
The Guest Investigator (GI) data are in a separate category from GR (public
release) data because they are susceptible to failure of certain quality
assurance tests run in the pipeline; GR data pass these tests by
definition. The GI data (whether proprietary or now public) may have
files that are missing. Also, some observations may not have correct aspect
solutions, meaning (in a few cases) the data quality can be seriously
compromised, or which may be garbage. The project was insistent that MAST
not mix public and formerly-GI data because of these problems. (The
GALEX/GI webpage has a red-lined link that addresses this.) All GI data
that is recoverable will be processed as a later GR (public) release.
But this forced MAST to decide how it would handle queries for publicly
available, formerly-GI data in the interim. Since its existence in a GI
DB is transitory, we decided not to develop a separate full service-DB for
these data. This means that some important functionality cannot be
duplicated, for example, the ability to drill down to individual objects
in the available catalogs.
Horrible situation with ftp scripts. Still haven't downloaded all my data!
The type of user you are is not clear from this comment -Guest Investigator (GI) or an public data users.
GIs get their data as a tar file via a specific command sent to them by the
GI help office at Goddard. It comes packaged as one large file. The GI's
request is sent to a MAST data server automatically, but MAST's role in
this is transparent to the user. If a GI has trouble with this, he/she
should contact the Goddard GI help desk.
Goddard will forward any pertinent problems to MAST.
Alternatively interpreted, ftp requests can be made of *public( (GR)*
data by checking a box and customizing the request to include all/many
files in one request. A script that includes the ftp "get" command is made
and can be saved to the user's computer, where it can be executed locally.
We are not aware of difficulties of this system, which admittedly is awkward.
Actually getting Galex data is very confusing. For simple science why can't I just click on your processed galex image and get a fits file with that data (instead of a link to 200 scans which it's hard to figure what to do with).
Data for individual objects can be straightforwardly downloaded via the Explore page (by one interpretation). By the other reading, users can decide what data products -there are many -they want by going to the one line data descriptions in the table of our help page.
A new option has been added to the GALEX Release 2 website. When you click
on FITS, the default download option is a "Minimum Recommended Set of Data". A tooltip
lists the file types included in this set of data.
The GALEX archive should show whether an observation was made at the
RA and Dec of the query, not just whether an object was cataloged there.
The limitations and lack of astronomer-friendliness of the GALEX search
interface has literally prevented me from using GALEX data or from
proposing to get more. How can I propose to do an observation if I can't
tell what has already been done in that part of the sky?
There is a straightward way of first determining what observations
have been made at a given position in the sky. This is found as query 9
in the SQL query form. More information can be found under
"FAQ MAST: Queries" from the documentation menu item on the left navigation bar.. The last FAQ on the FAQ
page explains this query and how to alter it for (formerly) GI public
The Simple (MAST) form works differently by searching on individual
objects within an search radius of input coordinates. We agree that
we could improve our services by offering a "coverage" option that would
look for whole observations (sky tiles) instead of objects as a return
on the MAST page.
Also, one tool that might help users who want to know what regions of
the sky have been observed is a detailed map that can be zoomed in on
and such. We are currently investigating Google-like maps employing
AJAX technology for this purpose.
Also have noticed problems with some FUSE data (e.g. your quicklook seems to have failed although nothing seems different when I actually analyze).
We receive the preview gifs from the FUSE project. Currently we have two different types of previews.
For data processed prior to 2002, we have a single plot preview. For data processed after that we have several plots including one that shows the overall spectrum. Recently, the FUSE project began processing data through a new pipeline (CALFuse 3.1). This pipeline sometimes fails to produce a full set of the plots, and one of them is the overall spectrum plot. When this happens, there is no plot to display. The project is determining what is causing this pipeline failure and plans to reprocess these particular observations so that a complete set of files is delivered and archived.
In using the FUSE data base, I still have trouble differentiating between FUSE Science and FUSE exposure... not clear what the differences are. Sometimes, targets are in one or another, or both...
FUSE observations are taken as a series of exposures. Observation level data are stored in the "science" table, while the exposure level meta-data are stored in the fuse_exposures table. There are two different searches. For every observation in the science table there may be many exposures. The dataset names can help distinguish an observation from an exposure.
The FUSE observation E9030501000 (of RE0003+433) has 18 exposures. The exposures are named
E9030501001, E9030501002,...E9030501018. Some observations also have fes observation attached and would have 701 as the last three characters. If there are further questions please contact the help desk.
Scaling of STIS previews
We will be implementing an improved scaling mechanism for existing STIS spectral previews. Watch our "What's New' column for the announcement. This improvement does not address the issue of non-extracted STIS data addressed in the question below.
Some echelle STIS exposures do not show as spectra at all when you click on them, but as two-dimensional images. When, if at all, will all data sets be showing as spectra?
Improvements to the previews are on the list of things to do
as part of the STIS close out, but will not occur until after the
calibration issues are resolved. This is because the previews
are derived from the calibrated data.
Historically, if a calibrated spectrum wasn't available at the
time the preview was created, an image was used instead. While
some of these data can now be calibrated, many can still not be
calibrated. Examples are data that used GO specified wavecals
instead of the auto-wavecals, or which used a non-standard aperture
for that grating. The good news is that these two cases should be
handled (i.e., be calibrated in OTFR) within the next few months.
Better preview tools, especially for images. The current generation is pretty much useless for faint objects.
We are working on this right now and should very soon have much more
useful previews. We fully agree that the current previews (particularly
for ACS) are rarely useful.
High-Level Science Products (HLSP) are community contributed data products that are fully processed (reduced, co-added, cosmic-ray cleaned etc.) images and spectra that are ready for scientific analysis. HLSP also include files such as object catalogs, spectral atlases, and README files describing a given set of data. These data are all contributed by the teams that produced them.
We welcome contributions of all types of HLSP from the astronomical community.
MAST has established a set of guidelines and policies to make these data as widely useful as possible.
HST Treasury and Archival Legacy programs agree to provide HLSP to MAST as a condition of the funding, but we are very interested in archiving products from teams using any data archived at MAST.
I need software which works in Windows media.
There are a plethora of ways one could process images, and the limiting of access to the unbinned images to IRAF only (by setting the NAXIS over 2) ends up making the data proprietary to Linux/Unix OS. Most imaging processing applications are Windows based, and most users of imaging applications are not going to spend the time to figure out why the images won't open or are distorted.
There are a couple of software packages that may help all users, including Windows users.
The PyFITS package provides an interface to FITS formatted files under the Python scripting language and PyRAF, the Python-based interface to IRAF. It is useful both for interactive data analysis and for writing analysis scripts in Python using FITS files as either input or output. Please see the website http://www.stsci.edu/resources/software_hardware/pyfits.
PyFITS does not need PyRAF and may be used independently so long as pertinent modules are installed.
You may find Aladin and Specview useful tools. (Both are available as Java applications and applets). Both are available for most platforms.
All MAST missions use standard FITS format which are readable from many different software packages. Some image processing software packages designed for use by the amateur community may not handle some types of standard FITS format data. Users of this software, who wish to read HST data, should ask those software providers to update their software to handle the more complicated FITS formatted data.
If you would like further help reading and performing analysis on HST data please contact the HST help desk. For help with other data archived at MAST please contact the archive help desk.