Bug #2174
cstsmapsplit does not work properly when it is initialized using an observation container
| Status: | New | Start date: | 08/03/2017 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assigned To: | - | % Done: | 0% | |
| Category: | - | |||
| Target version: | - | |||
| Duration: |
Description
I initialized cstsmapsplit using the following command:
obs = gammalib.GObservations("obslist.xml")
tsmapsplit = cscripts.cstsmapsplit(obs)
I specified all the parameters required by cstsmapsplit except for inobs and inmodel.
The script runs and produces the cttsmap command list output file, without complaining or querying further parameters.
However, the cttsmap commands do not have the inobs and inmodel parameters, which means that they cannot be used as they are.
The reason is probably at line 202 in cstsmapsplit.py :
if self[par.name()].is_query():
continue
These lines prevents cstsmapsplit from writing in the command list the parameters that were not previously queried, which is the case of inobs and inmodel if cstsmapsplit is initialized as I showed before.
The issue extends also to the response parameters (caldb, irf, expcube, psfcube, ...), since they are not queried if the response is already specified in the observation container.
I could think about two possible solutions:
- We could force cstsmapsplit to query the
inobsandinmodelparameters, even if they are not necessary. - We could save the observations and models in a temporary file, which is then passed to the cttsmap commands. The same should be done also for the response parameters.
Any ideas/opinions?
Recurrence
No recurrence.
History
#1
Updated by Di Venere Leonardo over 8 years ago
- Subject changed from @cstsmapsplit@ does not work properly when it is initialized using an observation container to cstsmapsplit does not work properly when it is initialized using an observation container
#2
Updated by Knödlseder Jürgen almost 5 years ago
- Target version set to 2.0.0
#3
Updated by Knödlseder Jürgen over 3 years ago
- Target version deleted (
2.0.0)
I’m actually wondering whether cstsmapsplit should be maintained in the long run. Implementation of parallel computing in cttsmap seems to be the preferable option.