Comments (4)
The following enhancement suggestion is an excerpt from opencadc/caom2tools#60 by dr-rodriguez:
"Some other wishlist items for CAOM v2.4 at the observation level:
An observation mode tag. While observation.type can get us some information about the type of observation, we sometimes need to provide more details and this observation.mode can be used to further refine that."
from caom.
There can be a (small) number of elements that make up the instrument, but in some cases different paths result in different planes or different artifacts or different parts. At some point this connects to the named bandpass (filter) which is currently specified in Chunk.energy and (summarised/aggregated) to Plane.energy.bandpassName... it seems worthwhile to revisit multiband data description and try to use a consistent pattern to describe multi-instrument-element
Although current multiband observations (eg. JCMT, MACHO) implement this as different files (artifacts) in different planes (thus with one bandpassName per plane), if someone were to store such data in a single file -> single artifact -> single plane with multiple bandpassName(s).
from caom.
CAOM currently has Telescope-Instrument with little more than names.
Interferometry looks more like Telescope-Collector-Instrument. Correlator info belongs in the provenance of the "raw" Plane.
Quick list of use cases:
- DerivedObservation created by combining data from multiple telescopes and/or instruments (stack, mosaic, SED, time series, etc)
- SimpleObservation created by combining data in real time from multiple telescopes (VLBI) -- multiple telescopes
- SimpleObservation created by correlating data from multiple collectors in real time (interferometry) -- single telescope, multiple collectors
- SimpleObservation created by passing signal through a combination of sub-components before recording it (filter, polarizer, grating, grism, beam splitter, ... detector) -- single instrument name but with different configurations that make it behave differently, so name is not very informative
The boundary between hardware and software in the "instrument" is intentionally vague.
Some long standing design principles/notes:
a. CAOM has never included collector size because the goal was always to be able to query on science rather than engineering metadata; collector size + exposure time is nominally related to depth/sensitivity but we always preferred to characterise this directly rather than have users do math to estimate it crudely.
b. pretty much every Telescope-Instrument in the world is bespoke so there is not a lot in common and a more detailed model probably has a very low value-to-complexity ratio
from caom.
On the line between hardware and software in the context of interferometry:
There is one instrument attached to each collector and the correlator is farther downstream so it is described by the provenance of the raw visibility data. Therefore:
- normally, the most raw plane (Plane.calibrationLevel = 0 or 1) does not have provenance because it is implicitly "from the instrument"; in principle such raw data could have provenance (eg describe the software/version used to format the data in FITS and store it) if that's considered worthwhile
- raw visibility data (Plane.calibrationLevel = 0) should have provenance information describing the correlator, eg:
Plane.provenance.name = {correlator name}
Plane.provenance.lastExecuted = {timestamp of data acquisition, probably start}
Plane.provenance.reference = {identifier for extra details about the named process}
Plane.provenance.version = {correlator software version(s)}
Pane.provenance.keywords = {additional adhoc metadata}
The other provenance fields look n/a and there would be no Plane.provenance.inputs
(this is the first product stored).
If it makes sense that correlator is provenance and not instrument, then in the case of VLBI with between 2+ telescopes the observation does not have a common telescope or a common instrument and just has
provenance. It could be feasible/desirable to create something like:
data stream A: SimpleObservation, telescope A, plane X, no/minimal plane metadata,
no artifact
data stream B: SimpleObservation, telescope B, Plane Y, no/minimal plane metadata,
no artifact
and
correlated raw visibililty: DerivedObservation, 2 simple members above, no telescope,
raw plane w/ metadata and artifact(s)
because that's the first things stored. TBD
from caom.
Related Issues (16)
- Add lunar keywords HOT 2
- restrict Algorithm.name values for simple observations HOT 1
- Provenance from multiple versions HOT 3
- add reference URL to proposal HOT 4
- python module validation of observation_id field - too stringent? HOT 6
- Addition of *_calib_status "optional" ObsCore attributes to the model? HOT 1
- Extend Observation Intent Type HOT 1
- expand fields to allow multiple values HOT 15
- Observation.observationID and Plane.productID are too restrictive HOT 6
- uniqueness of Artifact.uri HOT 7
- Add Artifact description lookup
- more formal refence to existing IVOA vocabularies
- make PolarizationState more flexible HOT 1
- align Plane metadata with IVOA Radio IG work on an ObsCore extention for radio
- reconcile IVOA DALI xtype usage with Plane metadata HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from caom.