10000 Flux unit of FluxPoints object inconsistent when read from an ecsv file · Issue #5783 · gammapy/gammapy · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Flux unit of FluxPoints object inconsistent when read from an ecsv file #5783

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
lmohrmann opened this issue Apr 9, 2025 · 3 comments
Open

Flux unit of FluxPoints object inconsistent when read from an ecsv file #5783

lmohrmann opened this issue Apr 9, 2025 · 3 comments
Assignees
@registerrier @QRemy
Labels
cleanup feature-request

Comments

@lmohrmann
Copy link
Contributor

Gammapy version
1.3

Bug description
I have the following flux points stored in ascii.ecsv format:

# %ECSV 1.0
# ---
# datatype:
# - {name: e_ref, unit: GeV, datatype: float64}
# - {name: e2dnde, unit: erg / (s cm2), datatype: float64}
# - {name: e2dnde_errn, unit: erg / (s cm2), datatype: float64}
# - {name: e2dnde_errp, unit: erg / (s cm2), datatype: float64}
# - {name: e2dnde_ul, unit: erg / (s cm2), datatype: float64}
# - {name: is_ul, datatype: bool}
# schema: astropy-2.0
e_ref e2dnde e2dnde_errn e2dnde_errp e2dnde_ul is_ul
1.40888 4.34712e-11 3.265000000000001e-12 3.1820999999999995e-12 0.0 False
2.82167 2.92988e-11 2.7984999999999962e-12 2.8540000000000038e-12 0.0 False
5.65116 2.20771e-11 2.6938999999999984e-12 2.8816999999999997e-12 0.0 False
11.318 2.07159e-11 2.9949999999999984e-12 2.966900000000001e-12 0.0 False
22.5999 1.11704e-11 3.23616e-12 3.2132e-12 0.0 False
45.2625 1.50335e-11 4.0328e-12 4.181399999999999e-12 0.0 False
90.3808 1.45867e-11 5.03952e-12 4.9076e-12 0.0 False
180.473 1.19726e-11 6.1309300000000004e-12 6.2518e-12 0.0 False

Note the unit specified for the e2dnde columns: it is erg cm-2 s-1.

When I read these flux points using fp = FluxPoints.read("<...>") and then e.g. look at fp.e2dnde, I get

RegionNDMap

	geom  : RegionGeom 
 	axes  : ['lon', 'lat', 'energy']
	shape : (1, 1, 8)
	ndim  : 3
	unit  : GeV2 / (TeV s cm2)
	dtype : float64

The unit is now GeV2 TeV-1 cm-2 s-1, which does not make a lot of sense.

Expected behavior
The unit of the e2dnde objects should be as specified in the file.
@lmohrmann lmohrmann added the bug label Apr 9, 2025
@bkhelifi
Copy link
Member
bkhelifi commented Apr 9, 2025

Thank you for the reporting.
The internal representation of the RegionNDMap seems a bit strange, even if the dimension is correct.

When plotting data after a fp = FluxPoints.read("xxx.ecvs"), here are the results:

ax = plt.subplot()
fp.plot(sed_type="e2dnde");
ax.set_xlim(0.8, 250)

Image

and, fp.plot(sed_type="dnde");

Image

As you can see, the results are correct, even if the internal representation of the RegionNDMap could be surprising.
I think that there is no bug here.

@lmohrmann
Copy link
Contributor Author

Granted, the plotting works as expected. But I would e.g. expect that when I do fp.to_table(), I get the values in the same unit as stored in the file. But also in this case, the unit is changed to GeV2 TeV-1 cm-2 s-1. That is very much non-intuitive. There must be a way to use as default the specified unit, at least for anything that is accessible for the user.

@registerrier
Copy link
Contributor

Hi @lmohrmann internally the FluxPoints is an energy axis (here in GeV) and a reference model (in this case an E^-2 PL with amplitude in TeV- 1cm-2s-1), hence the weird format.

When plotting default units are applied to each flux quantity. It is not the case for table export indeed. It could probably be improved by imposing the same default flux units for the various types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@registerrier registerrier

@QRemy QRemy

Labels
cleanup feature-request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@registerrier @lmohrmann @bkhelifi @QRemy
0