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 are providing, please contact us through the help desk archive@stsci.edu 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 or comments.

• 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.

• GALEX

  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 more useful.

  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 data. 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.

• FUSE
  • 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.

• HST Previews
  • 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.

• Hubble Legacy Archive
  • Just improve EXISTING functions without worrying about developing others. MAST downtime and retrieval times remain too long!

    The main goal of the HLA is to reduce the retrieval time for data from the current ~1 hour to just the time required to transfer the data to the user's machine. Another major goal is to allow access to image cutouts so that small sections of HST images can be retrieved almost instantly (in FITS or JPEG formats) for image browsing.

  • It would be great to be able to pull out of the archive drizzled, combined ACS images. Of course, this is difficult, because where do you draw the line on what data belongs to which data set? Along the same lines, have you thought of GRID-style reduction of HST imaging? WFPC2 and ACS reduction is very straightforward, so it could be done on the STScI machines and only the result forwarded to the user, since that's all the user cares about.

    This is indeed a good question with which we are currently wrestling. At the start we will include combined products for single visits, just as the current pipeline produces. But we do have longer-term plans to produce images that combine data from multiple visits as well. We will probably make the highest level images the default, but also allow people to drill down to get lower limit products (e.g. special mosaics like M51) > associations > visits > exposure).

    We also have longer-term plans to provide the ability for users who need to run programs that access large quantities of data to use STScI computers that have local access to all the archive data. That will make large-scale projects possible without the necessity of downloading all the data. This is a lower priority though and so likely won't be available for at least a year.

  • Better search support for solar system/ moving targets

    We understand the need for this type of search and do expect to add it in the future, but it is not a high priority for our current year's work.

  • Would the data include source lists for each field? Those of us working in other spectral bands would find it very useful if we could pull up data with point sources already marked or somehow identified for the field e.g. to see if x-ray sources in the field have optical counterparts and for checking astrometry.

    The current HLA plan includes creation of source lists for each field as a new key product. Initially these would be made for ACS data, and later for other image fields. The source lists may never cover 100% of all images, but should be available for a significant fraction, especially of the ACS and WFPC2 images.

  • Plotting of spectroscopic slits as overlays on DSS or HST images

    The HLA team is starting to develop a "foot-print" service that will eventually include this capability. However, the first priority is for ACS and WFPC2. We expect all the other instruments to be included next year.

  • [Provide] easily downloadable ascii tables

    The HLA team plans to provide easy access to ASCII tables. You can already get search results in a CSV format, which can be saved as an ASCII file. Some spectral data (IUE, EUVE, ASTRO, and ORFEUS) are currently available as ASCII files.

• Virtual Observatory

  Many survey respondents expressed their support for providing MAST data through the Virtual Observatory. A few respondents were unaware of the VO (please visit http://us-vo.org/) and a few others expressed concerns, such as the funding for the VO should be small compared to the money spent on building new telescopes (it is!!). We hope that as VO capabilities continue to grow, more astronomers will discover and make regular use of them. MAST is committed to providing VO-compliant data discovery and data access, and this can be done at a very modest level of effort.

• High-Level Science Products

  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.

• Using Data
  • 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.

  Fv: The Interactive FITS File Editor, written and maintained at our sister archive HEASARC, is a software tool for viewing and editing any FITS format image or table.

  Many astronomers utilize SAOImage DS9, an astronomical imaging and data visualization application available at http://hea-www.harvard.edu/RD/ds9/. DS9 runs on most platforms.

  For those who are working with images in Adobe Photoshop or Photoshop Elements, there is a plugin called the FITS Liberator. There is an article on using the FITS Liberator that explains how to use this tool.

  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.