Comments (8)
Hi @cosimoNigro and @maxnoe
This is something that was discussed in the past, and I believe the conclusion was we don't want to "impose" it. The issue was that looking at other instruments, each calls their IRFs with different EXTNAME (even if their meaning is identical), so if we added a fixed name to the specifications, then every single high-level IRF would not be GADF compliant.
I don't see any harm with suggesting one name, though. If in the future several effective areas are added to one FITS file, it will be easier for the user to understand their content if their name is descriptive, and will also guide the DL3 "producer". If several HDUs of the same type are added to a single file, they could have "*_N" labels.
I would perhaps add "recommended" EXTNAME values, different for each IRF component type (as I believe we have for the effective areas). But I don't have a strong opinion, as the HDUCLASn keyword family is the method we decided to use to identify HDUs.
from gamma-astro-data-formats.
It's mostly for science tools, If I want to load an IRF directly from a HDU I have to open the header and search in the specific HDUCLAS*
keywords. But if the IRF component had a standardised EXTNAME
then I could directly fetch it from the HDU list.
from gamma-astro-data-formats.
Actually, there is no difference between looking for a specific extname and specific HDUCLAS keywords. You have to loop through the file until you find it.
A FITS file is not a mapping with random access, it's a sequence of HDUs.
I dont think we should prescribe extnames and science Tools should not rely on them.
from gamma-astro-data-formats.
Ok I see your point, but beside the specific structure of the files and how we read it, wouldn't it be good to provide also mandatory values for EXTNAME
to the specs?
The specifications we provide go beyond science tools and if people were to explore the CTA and the H.E.S.S. data they would find different HDU names. Of course they would be able to figure out what an AEFF
is, but still, why not to provide uniform HDU names?
Why there is one recommended for the effective area and not for the others HDUs?
from gamma-astro-data-formats.
@cosimoNigro I don't think it makes sense to prescribe EXTNAMEs, since extnames must be unique but people might want to store multiple HDUs of the same type in the files.
E.g. Both point-like and FE IRFs or for different cut values, or different methods of background estimation as @AtreyeeS mentioned here gammapy/gammapy#3514.
There is already an issue about making the recommended extnames consistent: #165
However, I don't think there is a reason for science tools to rely on extnames other than when using HDU index tables.
If there is only one HDU per IRF component it is identifiable via the HDUCLAS
header entries. If not, that's a case that is solvable by creating a hdu index table pointing to the one the science tools should use (using an arbitrary EXTNAME).
from gamma-astro-data-formats.
@TarekHC exactly, so as we have the other issue about providing recommendations (#165) and we don't want to require extnames, I think this issue can be closed, right?
from gamma-astro-data-formats.
If @cosimoNigro and others think it is ok to add recommendations, definitely close it. If others support Cosimo's suggestion of imposing the EXTNAME, feel free to re-open and farther justify the change.
My feeling is that following up on #165 would be easy, and a "good enough" solution.
from gamma-astro-data-formats.
Ok, then I am closing it and I will follow-up on #165.
from gamma-astro-data-formats.
Related Issues (20)
- Event lists for simulated events HOT 7
- 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
- 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.