MaskFits error

[Haiming19]

when calling fermimodel.maskFits(), the error"global name 'd2r' is not defined" is arise, and how to solve this problem?

[jaulbric]

That's a bug. I think I've resolved the issue and published a new release (v1.2). If you would rather not download the new version you can add a line to fermimodel/MaskFits.py just below the import lines

d2r = np.pi/180.

and then run python setup.py install and it should fix the problem. Thank you for pointing this out.

Jaryd

On Sun, Jun 2, 2019 at 7:39 PM Haiming19 notifications@github.com wrote:

when calling fermimodel.maskFits(), the error"global name 'd2r' is not defined" is arise, and how to solve this problem?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jaulbric/fermimodel/issues/1?email_source=notifications&email_token=AETUQ5MRBH7R2P2S2OJKH23PYR77LA5CNFSM4HSEF43KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GXF22LA, or mute the thread https://github.com/notifications/unsubscribe-auth/AETUQ5OXMVCXCU4DA7BF7DTPYR77LANCNFSM4HSEF43A .

[Haiming19]

Hi, @jaulbric thank you for your suggestion. And I have other problem when running fermimodel.maskFits() with the input file "gll_iem_v07.fits", the error occurred: KeyError: "Keyword 'CTYPE3' not found."

Whether this requires to change the header of "gll_iem_v07.fits" to the same as "gll_iem_v06.fits"?

Also, I try running with the input file "gll_iem_v06.fits", the error occurred: AttributeError: recarray has no attribute energy.

Thanks in advance

[jaulbric]

You are correct. The version of the galactic diffuse model file gll_iem_v07.fits distributed from the Fermi group is missing headers that gtobssim requires. You will have to edit the FITS file to include the headers:

CRVAL3 = 49.99999999999999

CDELT3 = 1

CRPIX3 = 1.0

CTYPE3 = 'Energy '

CUNIT3 = 'MeV '

The maskFits function was only tested on gll_iem_v07.fits. I will update the code so that maskFits can be used with gll_iem_v06.fits.

On Mon, Jun 3, 2019 at 1:21 AM Haiming19 notifications@github.com wrote:

Hi, @jaulbric https://github.com/jaulbric thank you for your suggestion. And I have other problem when running fermimodel.maskFits() with the input file "gll_iem_v07.fits", the error occurred: KeyError: "Keyword 'CTYPE3' not found."

Whether this requires to change the header of "gll_iem_v07.fits" to the same as "gll_iem_v06.fits"?

Also, I try running with the input file "gll_iem_v06.fits", the error occurred: AttributeError: recarray has no attribute energy.

Thanks in advance

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jaulbric/fermimodel/issues/1?email_source=notifications&email_token=AETUQ5PIYX6FGEARAUMDWSDPYTICBA5CNFSM4HSEF43KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWYVGUY#issuecomment-498160467, or mute the thread https://github.com/notifications/unsubscribe-auth/AETUQ5L36ZRGL65UOLT4WB3PYTICBANCNFSM4HSEF43A .

[Haiming19]

Hi, @jaulbric thanks for your suggestion. And I find another error in running mymodel.loadCatalog(): "FluxError: Cannot calculate flux for PLSuperExpCutoff spectral type" for the source which spectral type is PLSuperExpCutoff. Is that a bug? And why the 'PLSuperExpCutoff' & 'PLSuperExpCutoff2' spectral types are available? Thanks in advance.

[jaulbric]

Hello,

Old versions of the source catalogs used the definition PLSuperExpCutoff. When newer catalogs were released a different definition for the power law with an exponential cutoff was used, because the flux definitions were different they named this spectral type PLSuperExpCutoff2. When the 4FGL catalog was first released (gll_psc_v18.fit, and when I first wrote the package) the PLSuperExpCutoff2 flux definition was used for pulsar sources. The 4FGL catalog was then updated (gll_iem_v19.fit), and PLSuperExpCuttoff2 was renamed to PLSuperExpCutoff, but kept the flux definition of PLSuperExpCutoff2. Depending on what version of the 4FGL catalog being used sources will either be PLSuperExpCutoff or PLSuperExpCutoff2, hence the need to have both spectral types available. However, it looks like I missed a check in the code when the catalogs were updated. I will try to fix this later today.

Jaryd

On Wed, Jun 5, 2019 at 1:13 AM Haiming19 notifications@github.com wrote:

Hi, @jaulbric https://github.com/jaulbric thanks for your suggestion. And I find another error in running mymodel.loadCatalog(): "FluxError: Cannot calculate flux for PLSuperExpCutoff spectral type" for the source which spectral type is PLSuperExpCutoff. Is that a bug? And why the 'PLSuperExpCutoff' & 'PLSuperExpCutoff2' spectral types are available? Thanks in advance.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jaulbric/fermimodel/issues/1?email_source=notifications&email_token=AETUQ5OMCTHTHK7PIYLYRRLPY5YRRA5CNFSM4HSEF43KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW66JPQ#issuecomment-498984126, or mute the thread https://github.com/notifications/unsubscribe-auth/AETUQ5LXFLUACDO7QUSK7DDPY5YRRANCNFSM4HSEF43A .

[jaulbric]

PLSuperExpCutoff issue should be fixed now.

Jaryd

On Wed, Jun 5, 2019 at 12:42 PM Jaryd Ulbricht j.ulbricht27@gmail.com wrote:

Hello,

Old versions of the source catalogs used the definition PLSuperExpCutoff. When newer catalogs were released a different definition for the power law with an exponential cutoff was used, because the flux definitions were different they named this spectral type PLSuperExpCutoff2. When the 4FGL catalog was first released (gll_psc_v18.fit, and when I first wrote the package) the PLSuperExpCutoff2 flux definition was used for pulsar sources. The 4FGL catalog was then updated (gll_iem_v19.fit), and PLSuperExpCuttoff2 was renamed to PLSuperExpCutoff, but kept the flux definition of PLSuperExpCutoff2. Depending on what version of the 4FGL catalog being used sources will either be PLSuperExpCutoff or PLSuperExpCutoff2, hence the need to have both spectral types available. However, it looks like I missed a check in the code when the catalogs were updated. I will try to fix this later today.

Jaryd

On Wed, Jun 5, 2019 at 1:13 AM Haiming19 notifications@github.com wrote:

Hi, @jaulbric https://github.com/jaulbric thanks for your suggestion. And I find another error in running mymodel.loadCatalog(): "FluxError: Cannot calculate flux for PLSuperExpCutoff spectral type" for the source which spectral type is PLSuperExpCutoff. Is that a bug? And why the 'PLSuperExpCutoff' & 'PLSuperExpCutoff2' spectral types are available? Thanks in advance.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jaulbric/fermimodel/issues/1?email_source=notifications&email_token=AETUQ5OMCTHTHK7PIYLYRRLPY5YRRA5CNFSM4HSEF43KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW66JPQ#issuecomment-498984126, or mute the thread https://github.com/notifications/unsubscribe-auth/AETUQ5LXFLUACDO7QUSK7DDPY5YRRANCNFSM4HSEF43A .

[Haiming19]

Thank you very much! And I have a problem when using the files with gtobssim: Caught St12out_of_range at the top level: vector::_M_range_check. But if I set the simulation time less than 3e+07 seconds, it will not appear the error. I don't think it is a bug of the fermimodel , because the code can be used successfully now. Do you have any suggestions about this? Thanks in advance.

Haiming

[jaulbric]

Hello Haiming,

Yes, that's a bug in gtobssim. I've run into it myself quite a bit. For some reason when gtobssim tries to simulate the galactic diffuse background it will often throw this error. It has something to do with how the simulator determines the direction from which the photons are originating. Sometimes the problem can be fixed using the maskFits function of the fermimodel package, but it depends on the region you're trying to simulate. What energy range are you interested in simulating? If you're trying to simulate low energies the mask applied to the galactic diffuse file needs to be rather large (roi radius plus ∼ 10∘) to account for the finite spatial resolution of the detector, but if you're only interested in energies > 1 GeV or so you can reduce the size of the mask and that might help solve the problem for you. I've noticed the problem most often when trying to include the galactic center.

The other option is to remove the galactic diffuse from the model and simulate your roi without it (which should run just fine). You can create a model map of the galactic diffuse and try to combine that with your simulations afterwards, but this might mess with your statistics.

The FSSC is aware of this _M_range_check error but has been unable to fix it. I don't think it's very high on their priority list because not a lot of people are trying to use gtobssim. You can mention here https://github.com/fermi-lat/observationSim/issues/1 that you are also experiencing this issue, or send a message to the help center fermihelp@milkyway.gsfc.nasa.gov. If more people bring it up they might be more inclined to fix the problem.

Jaryd

On Sun, Jun 9, 2019 at 7:53 AM Haiming19 notifications@github.com wrote:

Thank you very much! And I have a problem when using the files with gtobssim: Caught St12out_of_range at the top level: vector::_M_range_check. But if I set the simulation time less than 3e+07 seconds, it will not appear the error. I don't think it is a bug of the fermimodel , because the code can be used successfully now. Do you have any suggestions about this? Thanks in advance.

Haiming

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jaulbric/fermimodel/issues/1?email_source=notifications&email_token=AETUQ5MIR2WCGTNWKTM27WLPZUKPXA5CNFSM4HSEF43KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXILSYY#issuecomment-500218211, or mute the thread https://github.com/notifications/unsubscribe-auth/AETUQ5IYMB2YOQRDZWMCUB3PZUKPXANCNFSM4HSEF43A .

[Haiming19]

Hi Jaryd,

Thanks very much for your suggestions. I think you are right, when I remove some sources in the mymodel.txt, it will not appear this error, it depends on the number of the sources to be simulated. And I am interesting in energies > 10 GeV, and I trying to reduce the size of the mask and just consider the sources which TS>25 in the likelihood analysis of real events.

Haiming