Add 3D effective area to the specs

[TarekHC]

Hi all,

I have two main motivations to add a aeff_3d to the specs. and also support within science tools (3D: ENERGY, DETX and DETY):

• In MAGIC, as we only have two telescopes, the acceptance is not radially symmetric.
• If we want to reach the extremely low systematic uncertainty levels of CTA, we definitely need to add the zenith angle dependence within the FoV. For example, if the whole array is pointing 50deg away from zenith, and the whole FoV cover ~9 deg, then there will be a clear difference between the effective area between the top and bottom edges of the field of view (even if the offset is equal).

It shouldn't be a lot of effort to include this neither to the specs nor the science tools. What do you think, would it make sense? I could work on it 2/3 weeks from now.

Cheers!

[cdeil]

@TarekHC - I think it's a good addition.

In principle it's a straightforward addition, we have the same situation for background: http://gamma-astro-data-formats.readthedocs.io/en/latest/irfs/background/index.html

To add it to the spec, the main complication is probably that the AEFF page is already more complicated, and you'll have to find a way to organise the content so that it's clear, but not too much duplication for aeff_2d and aeff_3d: http://gamma-astro-data-formats.readthedocs.io/en/latest/irfs/effective_area/index.html

I haven't thought much about how to do it. Maybe similar to the background spec page?

Feel free to make a pull request directly, or if you want feedback before writing it, put a proposal or concrete questions here.

[TarekHC]

In principle it's a straightforward addition, we have the same situation for background:

What about the science tools? It shouldn't be too problematic either, right?

Feel free to make a pull request directly, or if you want feedback before writing it, put a proposal or concrete questions here.

Ok good, I'll do that in ~3 weeks.

[cdeil]

What about the science tools? It shouldn't be too problematic either, right?

My understanding is that this is the state for both Gammapy and Gammalib:

• Adding a new class that represents aeff_3d is easy.
• Filling that IRF (at least for HESS) is some work. Some thought needs to be given how point-source MC AEFF from given ZENITH / OFFSET is used to get an average aeff_3d for a given time interval.
• Using that class correctly in science tools in analysis requires significant work, because the code to reproject ALT/AZ aligned IRFs into sky images or cubes isn't implemented correctly yet.
• But this will have to be done anyways if we want to keep using bkg_3d, that's the same task.

See http://gamma-astro-data-formats.readthedocs.io/en/latest/general/coordinates.html#field-of-view

I'm not aware of a better suggestion to get more precise AEFF than the aeff_3d you suggest Except a big change where we start exporting IRFs as a function of zenith and say the science tools have to compute exposure by time stepping and ALT / AZ to sky transformations. So +1 to add aeff_3d now, and encourage people to propose and prototype other IRF schemes.

It will take some time to get it in the spec, exporters, CTA pipeline and science tools. Starting with the spec is a good way to get started in my opinion, to make sure everyone is aware and the details are clear and implementation should be faster.

Maybe @jknodlseder or @registerrier or @bkhelifi or @kosack or @parsonsrd have an opinion here or even a better idea how to store more precise AEFF at the DL3 level for HESS, MAGIC, CTA, ...?

[jknodlseder]

DETX and DETY are in reconstructed coordinates, while effective area should be a function of true incident angle. Are you proposing to have a coordinate system for true coordinates that is somehow aligned with the array coordinates?

Le 10 nov. 2016 à 17:37, Tarek Hassan [email protected] a écrit :

Hi all,

I have two main motivations to add a aeff_3d to the specs. and also support within science tools (3D: ENERGY, DETX and DETY):

In MAGIC, as we only have two telescopes, the acceptance is not radially symmetric. If we want to reach the extremely low systematic uncertainty levels of CTA, we definitely need to add the zenith angle dependence within the FoV. For example, if the whole array is pointing 50deg away from zenith, and the whole FoV cover ~9 deg, then there will be a clear difference between the effective area between the top and bottom edges of the field of view (even if the offset is equal). It shouldn't be a lot of effort to include this neither to the specs nor the science tools. What do you think, would it make sense? I could work on it 2/3 weeks from now.

Cheers!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/open-gamma-ray-astro/gamma-astro-data-formats/issues/73, or mute the thread https://github.com/notifications/unsubscribe-auth/AC2oV6T315C9sTMBvmHPju6fEXl8xqeSks5q80hUgaJpZM4Ku3rA.

[TarekHC]

DETX and DETY are in reconstructed coordinates, while effective area should be a function of true incident angle. Are you proposing to have a coordinate system for true coordinates that is somehow aligned with the array coordinates?

Well, I guess it must be aligned with the stronger performance dependencies. And in IACTs, the zenith/azimuth (specially zenith within CTA's FoV) affect the AEFF very strongly.

We need to think of a way to add this dependency. This aeff_3d could be one solution. Another solution would be to leave the aeff_2d as it is, but add a new axis with the zenith dependency. That way each event would be properly described by the correct IRF.

[kosack]

You may also be able to get away with far less bins if you choose a polar coordinate system for this instead of DETX/DETY, like (R, phi), since to first approximation it's radially symmetric, and then there is a phi-dependence that would generally be second-order and only very prominent with 2 telescopes or a strange layout during construction. Therefore having all Aeff lookups be a function of r with a phi dependence that could be simply a single bin (radially symmetric) or many bins if not.

That way you don't even need two types of lookup, just one but where the number of bins is variable.

[jknodlseder]

This may be true for H.E.S.S. but is it still true for CTA with a larger FoV or if you use a divergent pointing mode that may be 10-20° wide?

We should make sure that the format covers all cases, and allows the low systematic uncertainties imposed for example by CTA requirements.

Le 14 nov. 2016 à 11:12, Karl Kosack [email protected] a écrit :

You may also be able to get away with far less bins if you choose a polar coordinate system for this instead of DETX/DETY, like (R, phi), since to first approximation it's radially symmetric, and then there is a phi-dependence that would generally be second-order and only very prominent with 2 telescopes or a strange layout during construction. Therefore having all Aeff lookups be a function of r with a phi dependence that could be simply a single bin (radially symmetric) or many bins if not.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/open-gamma-ray-astro/gamma-astro-data-formats/issues/73#issuecomment-260296731, or mute the thread https://github.com/notifications/unsubscribe-auth/AC2oV96V8vbGyoq-rMWFgmIkzpX7Flykks5q-DQIgaJpZM4Ku3rA.

[TarekHC]

I believe that what @kosack suggests makes sense. Using square bins in DETX and DETY can be approximately correct, but similar bins in (R,phi) would probably make more sense, and would simplify interpolations (even for a non-symmetric layout of telescopes, or divergent pointing). That would allow bigger bins for similar systematic uncertainty level, which would reduce the required amount of MC statistics, which is a sensitive matter for CTA...

We currently support 3D background using DETX and DETY, and I think also in this case it makes more sense to use THETA and PHI. So now the question is: do we need a different format for a 3D background using THETA and PHI as FoV coordinates (e. g. bkg_3d_rad)? Or should we give some freedom to the user to store the IRF as a function of the FoV coordinates of choice, and let science tools handle the rest?

[cdeil]

So now the question is: do we need a different format for a 3D background using THETA and PHI as FoV coordinates (e. g. bkg_3d_rad)?

Yes. That's how it works at the moment.

Or should we give some freedom to the user to store the IRF as a function of the FoV coordinates of choice, and let science tools handle the rest?

That's how it could work in the future.

Science tools could be aware of certain axes (see current list here) and know how to transform those into their internal dataspaces used in analysis (mostly LON, LAT, ENERGY) and possibly have clever axis-specific methods for interpolation (e.g. circular for PHI here).

@TarekHC - You've thought about this a lot and prototyped in flexIRF. I think any contributions in that direction to the spec or existing code (ctapipe or science tools) would be welcome. The way I see it is that what we wrote down now is because "something is better than nothing" and that's what we were using already, not because it's a great, flexible system that is the final solution.

[TarekHC]

Yes. That's how it works at the moment.

That may be the best solution for now.

@TarekHC - You've thought about this a lot and prototyped in flexIRF. I think any contributions in that direction to the spec or existing code (ctapipe or science tools) would be welcome. The way I see it is that what we wrote down now is because "something is better than nothing" and that's what we were using already, not because it's a great, flexible system that is the final solution.

The problem is that, up to now, I always had the impression that we did not want a flexible data format. What I understood is that the format should be simple, stable and "solid", while the software could be more flexible (but not the specs).

Also, regarding flexIRF, I mostly focused on storing those IRFs, and not "reading" them (i. e. interpolating), which is probably the trickiest part.

I am already starting to play with CTA IRF generation within ctapipe, but still everything is extremely preliminary. But yes, I should get more involved also in the science tools side, as it is not clear at all who does what (e. g. background calculation).

[maxnoe]

On a side note, I think we should call them not by their shape but find more appropriate names.

E.g. 2d could be AEFF_RAD for radially symmetric, 3D could be AEFF_DET_RPHI and AEFF_DET_XY to allow both possibilities.

[maxnoe]

Just to add: we probably then can use the same format also for background and psf tables that are not radially symmetric in the FOV

[maxnoe]

DETX and DETY are in reconstructed coordinates, while effective area should be a function of true incident angle. Are you proposing to have a coordinate system for true coordinates that is somehow aligned with the array coordinates?

Coordinate systems are independent of whether we express an estimated or a true quantity in them.