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
inobs
andinmodel
parameters, 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 7 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 over 3 years ago
- Target version set to 2.0.0
#3 Updated by Knödlseder Jürgen over 2 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.