Observation data model comments

Anita Richards amsr at jb.man.ac.uk
Mon May 10 08:41:00 PDT 2004


I think Francois will reply more, just a somment:

> I am not sure to catch your point.
> For me each data (ObsData, ProcessData...) has it's own Characterisation.
>  From your comment it seems that you suppose that Characterisation is linked
> to only ObsData (raw data or data sufficently related to it, to have
> the same Characterisation). But then how do you handle Characterisation
> for data processing which changes this considerably, like in your example
> with high/low  spatial-res/sensitivity  outputs.
> Or do I missed something?

No, that is exactly my problem, which I thought that Versioning was
suggested to overcome.  At the moment VOs are probably only usefully able
to handle a few sorts of data from any one provider, and that should not
be too raw - I think that ObsData can be _anything_ but in general if it
is of any use to the VO it will be data ready for analysis, e.g. source
extraction.  That is, it is data which has had the instrumental
characteristics taken out of it and can be analysed using generic tools.
(Of course we make all sorts of exceptions like keeping zero-points for
HST wavebands...)

>
> I didn't understand either the two Observation box, and the link between
> them? ?association between Observation and Provenance => simple line
> (change needed?) ?agregation/composition between Provenance and
> Processing => diamond+line (ok) ?inheritance/specialisation between
> Processing and Composition => triangle+line (change?) ?agregation or
> association between Composition and Observation => change or not?

Maybe I should have just left everything with plain lines, if my arrows
don;t make sense just ignor them as they are probably wrong.

> But perhaps a clear gap has to be made between data directly obtained from
> observation (related to only ONE observation, a set of data which shares prov.)
> from the ones deduced from confrontation/agregation of several observation.
> However it seems to me that such a separation is artificial, and sometimes
> not realistice. For example calibration of bservational data uses elaborated
> data deduced from previous experiment and so on.

Absolutely, there is no clear indivisible unit, it has to be flexible as
you say.

>
> PS : As pure intelectual curiosity what are the units of the 7D of
> visibility data? Did yu have any ref. or doc available and usable for a
> beginner in radio data like me?

example

AIPS 1: COMPLEX      3   0.0000000E+00       1.00  1.0000000E+00    0.00
AIPS 1: STOKES       2  -1.0000000E+00       1.00 -1.0000000E+00    0.00
AIPS 1: FREQ       255   2.2235079E+10     128.00  7.8125000E+03    0.00
AIPS 1: IF           1   1.0000000E+00       1.00  1.0000000E+00    0.00
AIPS 1: RA           1    00 00 00.000       1.00       3600.000    0.00
AIPS 1: DEC          1    00 00 00.000       1.00       3600.000    0.00


Complex covers the visibility plane, Stokes is polarization (usually
either LL and RR or just one, or LR and RL, or IQUV), FREQ is frequency
channels IF is when you have a number of frequency bands (each with e.g.
255 channels)

In addition in the visibility plane you have
UU-L  VV-L  WW-L
which are derived from
BASELINE  TIME1
and FREQ
and
SOURCE

COnfused? So am I...

Most of the guides to interferometry start with an idealised
interferometer not with the data representation. Paddy Leahy's chapter in
the MERLIN User Guide is the shortest version of that I ahve seen:
http://www.merlin.ac.uk/user_guide/OnlineMUG/newch0-node30.html

or for general data representation with radio interferometry examples see
the (perm any author combination) Greisen Calabretta Valdez WCS papers -
you probably know far more than me already but if not see
http://www.aoc.nrao.edu/~egreisen/index.html
(bottom of page, under all the birds)

all the best

Anita



More information about the dm mailing list