Q: What are the differences between multi-band aperture-matched source lists and band-merged catalogue-like products.

A: Here are some useful information on multi-band aperture-matched source lists and band-merged catalogs.

Multi-band aperture-matched source lists (FITS tables) are produced from the single band source lists and are associated with the tiles observed in different bands for one pointing sky position. The astrometric and photometric calibrations for the ra/dec and magnitudes of the sources in these lists are based on night-calibrations. E.g. these are not global calibrations. The multi-band aperture matched source lists cannot be querable for content from the ESO archive; they can be downloaded as fits tables and will refer to the ra/dec sky position of tiles they were produced from.

Multi-band (or band merged) catalog are released at the milestones for the survey releases. The first of such milestones is October 1st, 2011. The calibration of the astrometry and photometry is global, on the whole region covered by the release. The catalogs will be querable for content, differently from the multi-band aperture-matched source lists , i.e. the individual sources in the catalogs will be accessed via the ESO query interface.

Sources in the catalogs may be detected based on the chi² image or other criteria, driven by the scientific goal of the project. They will not come necessarily from matching single band source lists from the CASU data reduction pipeline.

Furthermore catalogues delivered at the survey releases may contain additional data, that do not come from the VISTA observations: for example photo-z or matched information with X-ray or other multi wavelength observations, weak lensing information etc.

Q: What are multi-band aperture-matched source lists and band merged catalogues for the deep survey fields?

A: It deals with the specific properties of deep surveys with respect to the wide area surveys. As illustrated before multi-band aperture matched source lists are different data products from band-merged catalogues.

Multi-band aperture matched source lists may refer to shallower data products than the deep stacked tiles that are obtained from the data collected over the whole period.

In case of the deep fields, the survey teams may decide to release 1 hr or xx hrs deep tiles with associated multi-band aperture-matched source lists, which will be very valuable data-products for multi-epoch observations, for example monitoring AGN variability or SN searches. In this case the information contained in the multi-band aperture matched source lists is not equivalent to the catalogue extracted from the deep stacks, as the variability information is lost in this final catalogue.

About the multi-band aperture-matched source lists: for deep surveys, the distinction between these source lists and the catalogs expected for the survey releases is more difficult to draw. While for wide surveys the scientific quality difference is clear, it is less so for deep surveys.

Example specific for a deep field

A deep field is observed in Z, J, and Ks in a period  with 28 tile-OBs in Z, 21 tile-OBs in J and 21 tile-OBs in Ks successfully executed. The releative data products would be 28 tiles in Z, 21 tiles in J and 21 tiles in Ks + weight maps + single band source lists as data products for these observations.

One would then have 21 multi-band aperture matched source lists in Z, J, and Ks computed from the single-band source lists closest in time.

Q: Are the data standars specified for light curves data products? When is the submission date for these products?

A: The current ESO/EDP data standard (Issue 2, dated 09.03.2011) does not apply to light curves. EDP has decided to publish the data standard for light curves along with the general specification for catalogue products on time for the VISTA survey data release in October 2011. Therefore ESO does not expect the delivery of light curves in April 2011.

Q: Is the compiled version of fitsverify available from the Phase 3 web pages running on MAC?

A: the version of fitsverify is compiled for the linux operating system. One may download the source code from:

http://heasarc.gsfc.nasa.gov/docs/software/ftools/fitsverify/

and compile it on MAC. We cannot assure though that everything would work, as it was not tested.

Q: Which environment does validator_user.jar need to run? Which Java version?

A: the validator has been developed and tested under Scientific Linux 5.3 (based on Red Hat Enterprise 5). It requires Java version jdk1.6.0_18 or higher.  The validator is expect to run under linux; other platforms are not supported at the moment.

Q: In the example header provided in the user documention the PROV refer to the archive file names, e.g. PROV1 = 'VCAM.2010-09-29T05:55:14.101.fits' while ours is PROV0001 = 'v20100928_00514.fit[1]'. I understand that it makes more sense for you the first one, but can you confirm this point for me please? I.e. we have to change PROV0001 to PROV1 and also look up the name of the ARCFILE in our provenance file.

A: Regarding the PROV* keywords, it is correct that the ESO/EDP standard differs from the convention used at CASU. Specifically, the ESO/EDP data standard mandates that

• the index i (i=1,..,N) of the indexed keyword PROVi is not zero-padded;
• the values of PROVi are pointers to files rather than pointers to FITS extensions, i.e. no trailing extension number in square brackets;
• the PROVi keywords reside in the primary HDU of FITS file.

Generally, the PROV pointers should point to files being archived at ESO. In the case of ESO public imaging surveys this can be either the original raw files using the ESO archive identifier like 'VCAM.2010-09-29T05:55:14.101.fits' or other product files being submitted to ESO for archival and publication.

Examples

VHS is expected to deliver tiles as primary survey products. If the PI/Co-I's choose not to submit the intermediate products, let's say pawprints, from which the tiles were created, then the PROVi keywords written in the tiles should point to the original raw files like 'VCAM.2010-09-29T05:55:14.101.fits'. The header example for the VISTA tile given in Sect. 3.8.1.1 of the ESO/EDP Standard (Issue 2) corresponds to this case.

Otherwise, if, based on an evaluation of the extra scientific merit to be expected, intermediate products (pawprints) are planned to be delivered as well, then the PROVi keywords written in the tiles should point to the pawprints and, in turn, the PROVi keys in the pawprints should point to the original raw files.

In the case of single-band source catalogues extracted per tile, called "source lists" in our terminology, the PROV1 key has to point to the originating tile unconditionally (cf. Sect. 3.8.1.5, p.28).

Q: I note that the PROV keywords do not seem to be mandatory; if that is the case we do not need to provide them, right?

A: Yes, it is correct that PROV keys are currently recommended for image data products (tile, pawprint etc.) but they are not required.

Q: In checking the results of the Phase 3 validator (validation.jar file) I noted that the presence of the ELLIPTIC keyword is not checked for. I noticed this in one file which did not have this keyword defined and the validation did not show any error?

A: Regarding the ELLIPTIC keyword, we know that the validator does not catch the lack of this keyword (and other keywords) in all cases even though it is mandatory according to the EDP format standard. We are working on this issue, but, unfortunately, it is not trivial to fix it quickly.

Q: How can I display the 9Gb fits files of the stacked UltraVISTA images?

A: You must have a 64 bit OS to display the images. It will work right away in ds9 if your machine has at least 9GByte of RAM. If not, you can use imcopy in IRAF or the stand-alone utility fitscopy that comes with CFITSIO. Compiling fitscopy is usually as simple as:
./configure
make
make fitscopy
You can then copy out a subsection e.g. as
fitscopy 'filename.fits[6317:42736,7063:37182]' filename.trim.fits
This particular subsection would be about 4 Gbyte (and requires about 4 Gbyte RAM to make); you can of course try something smaller. The format of the subsection is x1:x2,y1:y2 (just like in IRAF).