On Fri, 6 Jun 2003, Anita Richards wrote:
> 1. Name and nature of observatory and/or facility
Berkeley-Illinois-Maryland Association (BIMA) Millimeter-wave Telescope
> 2. Current archive status and description:
Archive: NCSA BIMA Data Archive (http://bimaarch.ncsa.uiuc.edu)
(We also maintain the publicly-accessible NCSA Astronomy Digital Image Library, ADIL, http://adil.ncsa.uiuc.edu, which features images in FITS format from the BIMA telescope, among others.)
> a) How are data stored?
For long-term Storage we use the NCSA Mass Storage System, a massive
robotic tape system. Our archive server features a local cache of
spinning disk that can hold several months worth of data; data is moved on
and off the cache from long-term storage transparently in response to user
requests. All metadata are stored on disk (in XML format and in an
RDBMS).
> b) How are data catalogued?
Project information is extracted from the observing proposals, and dataset metadata are extracted from the datasets. All metadata are stored on disk in XML format; a (large) subset is also stored in an RDBMS (PostgreSQL) to support searching.
> c) Do you provide information about sources (as distinct from about
> observations) e.g. calibrator lists, target properties, and if so
> is this:
Not as of yet.
> 3. What can be accessed on-line?
All metadata are browsable on-line; all datasets are download-able.
> 4. Who can access it?
All telescope observers; not open to public.
> 5. What are the methods of access?
HTTP: Searching, dataset browsing, dataset downloading. Single-file downloads via browser; multi-file downloads enabled through browser helper app (DaRT).
> 6. What search parameters are available?
ProjectID, Investigator name, Observe file name observation date, sky position, frequency, dataset name,....
> 7. What is your Archive Policy?
I'm not sure what this means.
> 8. What software do you use?
OTS products: PostgreSQL, rsync, Miriad, Apache, Tomcat Development tools: Perl, Java, Java Servlets, XML, XSLT, Python.
> 9. What software do users need, and can you provide it?
Miriad: for end-user calibration & processing; available from Miriad site. DaRT (Data Retreival Tool): a Java application we distribute to enable multi-file downloads.
> 10.What format(s) are your data in (or can be translated into)?
Formats:
Raw UV-Datasets: Miriad (translatable to AIPS++ MS2)
Calibrated UV: Miriad & AIPS++ MS2 Images: FITS (translatable to Miriad, AIPS++, ...)
(Multiple formats supported for ancillary data)
> 11.Do you use pipelines?
Yes; currently in prototype phase.
> 12.How far are data normally reduced before being supplied to the
> user?
Phase one calibrates and images single tracks. Phase two will combine tracks for imaging.
> 13.Are these stages:
> a) documented?
Dataset Histories maintained; scripts delivered to users.
> b) reversible?
No, but unprocessed data is available.
> 14.Can data be processed remotely?
??
> 15.What Virtual Observatory projects (if any) are you involved in?
NVO
> 16.Do you use explicitly any interoperability tools, e.g. data models,
> UCDs, VOTable?
The ADIL is used to prototype VO tools and interfaces (e.g. Cone Search,
SIA).
> 17.Do you publish any data via existing VO-like facilities e.g. CDS,
> MAST?
The ADIL is such a repository.
> 18.Making data acess easier for a wider range of astronomers - what are
> your views on whether/how these suggestions should be impliments:
> a) Using a VO interface to radio observatories/data centres to run
> hidden software to provide required image, light curve,
> visibilities etc.?
Image access (a la SIA) is definitely useful; however, support for image cubes is clearly necessary.
Access to visibility data is potentially useful, but requires some prototyping to discover what scientists will find useful. It's not clear, for example, if a standard interface (like SIA) for accessing visibility data buys us much.
It would be interesting to float some specific ideas for standard services to see how many might be able to implement them easily.
> b) Supplying information about hidden processing (software, versions,
> parameterisation, etc)?
(I'm not exactly sure what is meant by "hidden processing".)
> c) Standardising the software in use at radio observatories/ data
> centres?
In general, not a good idea at any waveband; such choices are best made by the curators in consideration of their primary users and requirements.
> d) Standardising the format of data products?
For interchange purposes, yes. In particular, there is not a good FITS format for interferometry data sufficiently general for all modern telescopes with some information loss. (I just went through this for CARMA.) Formats that are locked to specific software packages are not good candidates for standardization.
Note that standardizing on formats is different from standardizing on data models, which is useful.
> 19.What do you think astronomers want from your data?
In order from most desired to least desired: 1. Deconvolved Images, ready for analysis and comparison with data at
other wavebands.
2. Calibrated uv-data, ready for imaging, possibly in combination with
observations from other radio telescopes (Single dish or
interferometer).
3. Value-added services that remotely analyze the data (e.g. measuring
fluxes of calibrators).
> 20.What are your plans for archive development or any other relevant
> suggestions?
Progress BIMA pieline to production mode, advance processing capabilities, add support for more user-driven processing of data from archive. Received on 2003-06-06Z18:03:57