Comments (7)
Hi @maxnoe
This is essentially #30.
The thing is that it is hard to be consistent, given that ENERGY
within the IRFs refers to the true energy, while within the event lists it refers to the estimated one...
Using TRUE_*
might be more consistent with what the IACT community has been using until now, although I think using MC_*
would be way more obvious, so no one makes a mistake. What do you (and others) think?
We would also need some metadata to store the usual MC-related parameters... Although that is probably something not so high level...
from gamma-astro-data-formats.
from gamma-astro-data-formats.
The same as for the other definitions, to have a common data format for easy exchange and processing of such data.
Right now, one of the use cases would be to compare output of MARS, EventDisplay and ctapipe and to calculate the IRFs from such inputs.
from gamma-astro-data-formats.
@maxnoe I think calculating IRFs needs DL2, not DL3. So @jknodlseder is right that it might be slightly out of scope regarding that specific science case.
But there are probably other tests and use cases that could benefit from such a definition. You could, for instance, compare a full simulation of any source with the high-level simulation of e.g. ctaobssim.
from gamma-astro-data-formats.
As the only difference between DL2 and DL3 is the added IRFs, this does not matter for the event list format, it would be the same for DL2 and DL3, right?
from gamma-astro-data-formats.
As the only difference between DL2 and DL3 is the added IRFs, this does not matter for the event list format, it would be the same for DL2 and DL3, right?
Mmmm... I kind of disagree. Even if technically they may be extremely similar, DL3 contain only gamma-like events and DL2 doesn't (so it would mean a change of paradigm, no?). In addition, DL2 would need to contain all the metadata/provenance from the simulations, which again might be slightly out of scope for this repo.
It is of course a matter of what we want to do, but DL2 is something probably more internal to ctapipe, so perhaps this is not the place for its definition (or perhaps it is?). Anyway, I still agree that it could eventually be useful to have a definition of true quantities, in case we ever need them.
from gamma-astro-data-formats.
In Gammapy we introduced "true" (energy / ra / dec) columns for simulated DL3 events lists, but this was only meant to be used internally for debugging / testing and is un-documented. During the implementation of the event sampling having access to the "true" information was useful, now that it's implemented not so much anymore. In general I agree it might be useful to have e.g. for technical studies.
I think the DL3 event list format is still rather simple and I wouldn't see any problem adding "true" columns as optional columns (https://gamma-astro-data-formats.readthedocs.io/en/latest/events/events.html#optional-columns). But I would rather see it as a preliminary solution, because I also agree with @TarekHC, that the technical requirements are different for DL2/DL3. Before cuts the DL2 event files can be orders of magnitude larger, different meta data is required and in terms of performance I'm not sure either whether FITS is the best suited format for DL2 event lists.
from gamma-astro-data-formats.
Related Issues (20)
- Recommended EXTNAME only given for few of the HDUs
- Required axis order and make clear how axis order is defined HOT 2
- Generalize to wide-field ground array instruments HOT 9
- Error in python time example
- Invited contribution in the "Universe" journal on data formats for gamma-ray astronomy HOT 7
- PSF Table documentation HOT 3
- Organisation / maintaining GDAF HOT 5
- Mailing list down HOT 6
- Order of axes in Edisp IRF HOT 20
- Standardise EXTNAMEs for HDUs HOT 8
- Add systematic errors in the error columns of the SED specifications HOT 2
- CALDB and IRF keywords in IRFs HOT 21
- Presentation of the initiative at the DPG spring meeting HOT 14
- Trigger automatic build of readthedocs HOT 10
- RADECSYS and co are deprecated in FITS standard 4.0
- What to do if OGIP conventions and the FITS standard are in conflict? HOT 2
- Make a final release before handing over to VODF? HOT 10
- Documentation not updated to version 0.3 HOT 1
- Presentation at the Astroparticle-Physics Symposium 2022 HOT 9
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 gamma-astro-data-formats.