Support #1950

'invalid background response tables' with ctobssim

Added by Eschbach Stefan about 7 years ago. Updated over 6 years ago.

Status:In ProgressStart date:03/13/2017
Priority:HighDue date:
Assigned To:Knödlseder Jürgen% Done:

10%

Category:-
Target version:-
Duration:

Description

Hi,

My name is Stefan, I’m a phd student, new to ctools and could need some help
I want to do simulations of HESS paris data with realistic IRFs. Therefore, I use csfindobs and csiactobs to get all runs to a certain source positions (at the moment crab) and use the received obsdef- and model- file as input for ctobssim. (Maybe this is not the best way to go, see closing thoughts.)

I have just installed the new ctools version 1.2.0, and now I always get the error that my simulated energies are not covered by the background response table. (Did’t appear in 1.1.0). The problem is that I set 'emin’ and 'emax’ for ctobssim globally for all runs in the simulation, and there always seems to be another background table that doesn’t fit, no matter how I adjust emin and emax! I could use only runs with a certain alt/az position, so that only one background response file is used, but I think that’s a bad workaround... Is there any method implemented to extrapolate the range of the bgkresponse tables or something? How did it work before the new version?

Closing thoughts: Maybe my method is stupid anyway. It could be better to pick a certain run (how to decide which?^^) with a certain IRF, so that i get only one observation definition, and then simulate events for a certain timing window. It would be nice if you could comment on that as well

Thanks in advance!!

Best regards,
Stefan Eschbach

Recurrence

No recurrence.

History

#1 Updated by Knödlseder Jürgen about 7 years ago

  • Status changed from New to In Progress
  • Assigned To set to Knödlseder Jürgen

Could you post the exact error message that you get so that I can understand where exactly the error occurs? I can then look into the modifications we did since version 1.1.0 to understand why this problem has not occurred before.

Also posting the run parameters and the ctobssim output can be helpful (for example with chatter=4 so that output is as informative as possible).

#2 Updated by Eschbach Stefan about 7 years ago

Hi Jürgen,

Thanks for the quick response! This is the error message:

terminate called after throwing an instance of 'GException::invalid_value’
what(): *** ERROR in GCTABackground3D::mc(GEnergy&, GTime&, GRan&): Invalid value. Event energy 38.3711407731853 TeV is outside the energy range [315.588086843491 GeV, 36.1207586631742 TeV] covered by the background response table. Please restrict the energy range of the simulation to the validity range of the background response table.
Abort

Parameters:
2017-03-14T09:13:48: inobs .....................: ../obsdef.xml
2017-03-14T09:13:48: inmodel ...................: ../obsmodel.xml
2017-03-14T09:13:48: caldb .....................: [not queried]
2017-03-14T09:13:48: irf .......................: [not queried]
2017-03-14T09:13:48: edisp .....................: no
2017-03-14T09:13:48: outevents .................: all_sim_events.xml
2017-03-14T09:13:48: prefix ....................: sim_events
2017-03-14T09:13:48: startindex ................: 1
2017-03-14T09:13:48: seed ......................: 2
2017-03-14T09:13:48: ra ........................: [not queried]
2017-03-14T09:13:48: dec .......................: [not queried]
2017-03-14T09:13:48: rad .......................: 2.5
2017-03-14T09:13:48: tmin ......................: [not queried]
2017-03-14T09:13:48: tmax ......................: [not queried]
2017-03-14T09:13:48: emin ......................: 1
2017-03-14T09:13:48: emax ......................: 50
2017-03-14T09:13:48: deadc .....................: 0.95
2017-03-14T09:13:48: maxrate ...................: 1.0e6
2017-03-14T09:13:48: eslices ...................: 10
2017-03-14T09:13:48: publish ...................: no
2017-03-14T09:13:48: chatter ...................: 4
2017-03-14T09:13:48: clobber ...................: yes
2017-03-14T09:13:48: debug .....................: yes
2017-03-14T09:13:48: mode ......................: ql
2017-03-14T09:13:48: logfile ...................: ctobssim.log

Other output (too long to copy everything since there are 142 observations)1:

2017-03-14T09:13:48:
2017-03-14T09:13:48: ====================
2017-03-14T09:13:48: | Input observations |
2017-03-14T09:13:48: ====================
2017-03-14T09:13:48: === GObservations ===
2017-03-14T09:13:48: Number of observations ....: 142
2017-03-14T09:13:48: Number of models ..........: 144
2017-03-14T09:13:48: Number of observed events .: 218372
2017-03-14T09:13:48: Number of predicted events : 0
2017-03-14T09:13:48: === GCTAObservation ===
2017-03-14T09:13:48: Name ......................: Crab Nebula
2017-03-14T09:13:48: Identifier ................: 16266
2017-03-14T09:13:48: Instrument ................: HESS
2017-03-14T09:13:48: Event file ................: /home/vault/caph/shared/data/Ctools/Paris/parisanalysis/pa/release-1.0/Model_Deconvoluted_Prod26/Mpp_Std/run016200-016399/run016266/events_016266.fits.gz
2017-03-14T09:13:48: Event type ................: EventList
2017-03-14T09:13:48: Statistics ................: Poisson
2017-03-14T09:13:48: Ontime ....................: 1713 s
2017-03-14T09:13:48: Livetime ..................: 1576.462 s
2017-03-14T09:13:48: Deadtime correction .......: 0.920293053123176
2017-03-14T09:13:48: User energy range .........: undefined
2017-03-14T09:13:48: === GCTAPointing ===
2017-03-14T09:13:48: Pointing direction ........: (RA,Dec)=(83.63333,22.51444)
2017-03-14T09:13:48: === GCTAResponseIrf ===
2017-03-14T09:13:48: Caldb mission .............:
2017-03-14T09:13:48: Caldb instrument ..........:
2017-03-14T09:13:48: Response name .............:
2017-03-14T09:13:48: Energy dispersion .........: Not used
2017-03-14T09:13:48: Save energy range .........: 0.4974216 - 41.6586 TeV
2017-03-14T09:13:48: === GCTAEventList ===
2017-03-14T09:13:48: Number of events ..........: 742 (disposed in "/home/vault/caph/shared/data/Ctools/Paris/parisanalysis/pa/release-1.0/Model_Deconvoluted_Prod26/Mpp_Std/run016200-016399/run016266/events_016266.fits.gz[EVENTS]”)
2017-03-14T09:13:48: Time interval .............: 52935.033587963 - 52935.0534143519 days
2017-03-14T09:13:48: Energy interval ...........: 1 - 50 TeV
2017-03-14T09:13:48: Region of interest ........: RA=83.63333, DEC=22.51444 [0,0] Radius=2.5 deg
2017-03-14T09:13:48: === GCTAObservation ===
2017-03-14T09:13:48: Name ......................: Crab Nebula
2017-03-14T09:13:48: Identifier ................: 16267
2017-03-14T09:13:48: Instrument ................: HESS
2017-03-14T09:13:48: Event file ................: /home/vault/caph/shared/data/Ctools/Paris/parisanalysis/pa/release-1.0/Model_Deconvoluted_Prod26/Mpp_Std/run016200-016399/run016267/events_016267.fits.gz
2017-03-14T09:13:48: Event type ................: EventList
2017-03-14T09:13:48: Statistics ................: Poisson
2017-03-14T09:13:48: Ontime ....................: 1712 s
2017-03-14T09:13:48: Livetime ..................: 1564.599 s
2017-03-14T09:13:48: Deadtime correction .......: 0.913901285046729
2017-03-14T09:13:48: User energy range .........: undefined
2017-03-14T09:13:48: === GCTAPointing ===
2017-03-14T09:13:48: Pointing direction ........: (RA,Dec)=(83.63333,21.51444)
2017-03-14T09:13:48: === GCTAResponseIrf ===
2017-03-14T09:13:48: Caldb mission .............:
2017-03-14T09:13:48: Caldb instrument ..........:
2017-03-14T09:13:48: Response name .............:
2017-03-14T09:13:48: Energy dispersion .........: Not used
2017-03-14T09:13:48: Save energy range .........: 0.438973 - 30.86145 TeV
2017-03-14T09:13:48: === GCTAEventList ===
2017-03-14T09:13:48: Number of events ..........: 984 (disposed in "/home/vault/caph/shared/data/Ctools/Paris/parisanalysis/pa/release-1.0/Model_Deconvoluted_Prod26/Mpp_Std/run016200-016399/run016267/events_016267.fits.gz[EVENTS]”)
2017-03-14T09:13:48: Time interval .............: 52935.0557638889 - 52935.0755787037 days
2017-03-14T09:13:48: Energy interval ...........: 1 - 50 TeV
2017-03-14T09:13:48: Region of interest ........: RA=83.63333, DEC=21.51444 [0,0] Radius=2.5 deg

1 The models consist of the 142 backgrounds and 2 point sources that I simulate

#3 Updated by Eschbach Stefan about 7 years ago

The longer I keep looking into it, the more I am of the opinion that I am not using ctobssim in a clever way. I want to simulate a source (in my case two point sources that are very close to each other) with realistic background and IRFs, but doing this run wise might just be a bad idea, using 'genreal’ IRFs seems to be a better approach. Is there any more documentation to ctobssim except the ctools reference manual?

#4 Updated by Knödlseder Jürgen about 7 years ago

The following links provide some tutorials:

Note that you can also feed an observation definition file into ctobssim where for each observation (or run) you can specify the energy range. I noticed that this is not really documented, so I post an example here of the XML file structure:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<observation_list title="observation list">
  <observation name="Crab" id="000001" instrument="CTA">
    <parameter name="Pointing" ra="83.6331" dec="21.0145" />
    <parameter name="EnergyBoundaries" emin="50000" emax="1e+08" />
    <parameter name="GoodTimeIntervals" tmin="0" tmax="1800" />
    <parameter name="TimeReference" mjdrefi="51544" mjdreff="0.5" timeunit="s" timesys="TT" timeref="LOCAL" />
    <parameter name="RegionOfInterest" ra="83.6331" dec="21.0145" rad="1.5" />
    <parameter name="Deadtime" deadc="0.98" />
    <parameter name="Calibration" database="prod2" response="South_0.5h" />
  </observation>
  <observation name="Crab" id="000002" instrument="CTA">
    <parameter name="Pointing" ra="83.6331" dec="23.0145" />
    <parameter name="EnergyBoundaries" emin="70000" emax="1e+08" />
    <parameter name="GoodTimeIntervals" tmin="1800" tmax="3600" />
    <parameter name="TimeReference" mjdrefi="51544" mjdreff="0.5" timeunit="s" timesys="TT" timeref="LOCAL" />
    <parameter name="RegionOfInterest" ra="83.6331" dec="23.0145" rad="1.5" />
    <parameter name="Deadtime" deadc="0.98" />
    <parameter name="Calibration" database="prod2" response="South_0.5h" />
  </observation>
</observation_list>

Assuming that the file is named obs.xml you call ctobssim as follows:
$ ctobssim inobs=obs.xml

#5 Updated by Eschbach Stefan about 7 years ago

Thanks for the links, I looked at them before but I didn’t try creating a new caldb entry, maybe this helps with my problem...
I will try that today!

The tip with the run wise emin/emax is also very helpful, I didn’t know this was possible! But in my case it would be a big effort to look up the energy boundaries for all of the 142 runs and change them in the xml-file, and the real problem is that even if I did so: The energy of the overall simulated events is no longer evenly distributed in the energy interval I want to simulate in (0.1-100 TeV) if I simulate run wise with different boundaries...

#6 Updated by Eschbach Stefan about 7 years ago

Hi again,

caldb also just picks the first observation, so that didn’t improve anything :P

As a workaround, I now switched the background models (from irf to aeff) and this works for the simulation (aeffs seem to be defined in a larger energy range). Of course it would still be interesting to know why it worked before, but it’s not extremely urgent any more now Thanks for the help so far!

#7 Updated by Knödlseder Jürgen about 7 years ago

Eschbach Stefan wrote:

Thanks for the links, I looked at them before but I didn’t try creating a new caldb entry, maybe this helps with my problem...
I will try that today!

The tip with the run wise emin/emax is also very helpful, I didn’t know this was possible! But in my case it would be a big effort to look up the energy boundaries for all of the 142 runs and change them in the xml-file, and the real problem is that even if I did so: The energy of the overall simulated events is no longer evenly distributed in the energy interval I want to simulate in (0.1-100 TeV) if I simulate run wise with different boundaries...

Normally the changing energy boundaries are correctly handled when stacking the events into an event cube.

#8 Updated by Knödlseder Jürgen about 7 years ago

  • Priority changed from Normal to High
  • Target version set to 1.3.0
  • % Done changed from 0 to 10

From the discussions we had yesterday, it looks like you have a specific IRF for an observation where the energy range covered by the effective area is larger than the energy range covered by the background template. It’s not obvious to me whether this is something that should be fixed on the IRF exporter level, or if this is something that should be dealt with at GammaLib / ctools level.

One possibility would be to add GCTAAeff::ebounds() and GCTABackground::ebounds() (and likely also GCTAPsf::ebounds() and GCTAEdisp::ebounds()) methods that the return the energy boundaries for all response components. ctobssim can then use this information to restrict the energy range to valid energy range of the response components. In addition, the LO_THRES and HI_THRES keywords in the effective area response may be used to further restrict the energy range.

Note that the energy boundaries may depend on the other parameters, specifically the off-axis angle. The bounds() methods may take these parameters as arguments.

#9 Updated by Eschbach Stefan about 7 years ago

I have not worked with ctools for the past two weeks, yesterday I installed the new revel-version and tried to continue.
Despite our fixes during the coding sprint it is not possible for me to use ctobssim with multiple runs.
I always run in some invalid values.

With irf-background (i think we didn’t work on this):
terminate called after throwing an instance of 'GException::invalid_value’
what(): *** ERROR in GCTABackground3D::mc(GEnergy&, GTime&, GRan&): Invalid value. Event energy 203.327325817373 GeV is outside the energy range [795.871615409851 GeV, 61.3582085347646 TeV] covered by the background response table. Please restrict the energy range of the simulation to the validity range of the background response table.
Abort

With aeff-background:
terminate called after throwing an instance of std::out_of_range’
what(): basic_string::substr: __pos (which is 61) > this→size() (which is 51)
Abort

Interestingly, the second error appears for different runs when I let the program run multiple times
I will try to look in the code to see where the error originates.
I think it should be possible that ctobssim checks for which energy range in a certain run it can extract background information (aeff/irf) and then only simulate events in this range without throwing an error and we should definitely try to get that running!

#10 Updated by Eschbach Stefan about 7 years ago

Wasn’t able to resolve the issue up to now, would be nice if somebody else could also look into it.

#11 Updated by Knödlseder Jürgen almost 7 years ago

  • Target version changed from 1.3.0 to 1.4.0

#12 Updated by Knödlseder Jürgen over 6 years ago

  • Target version changed from 1.4.0 to 1.5.0

#13 Updated by Knödlseder Jürgen over 6 years ago

  • Target version deleted (1.5.0)

Is this issue still relevant?

#14 Updated by Eschbach Stefan over 6 years ago

Not for me personally since I no longer work on this, but I don’t know if it’s solved in general.

#15 Updated by Knödlseder Jürgen over 6 years ago

Thanks for the response. Let’s see how this goes once the H.E.S.S. public data release comes out.

Also available in: Atom PDF