Change request #1197

Gammlib should check consistency of model and observation xmls

Added by Lu Chia-Chun almost 10 years ago. Updated almost 10 years ago.

Status:NewStart date:05/09/2014
Priority:HighDue date:
Assigned To:Knödlseder Jürgen% Done:

0%

Category:-
Target version:-
Duration:

Description

It took me quite a while to find out that I put mismatched instrument names in observation and model xml files so gammalib can’t find the corresponding data for the model. (I put “HESS” in observation xml and “CTA” in model xml.)

In this case, a warning message should be thrown to warn users.

Avg_Crab_model_Gaus.xml Magnifier - Background model labelled with 'CTA' (1.81 KB) Lu Chia-Chun, 05/09/2014 08:43 AM

Avg_Crab_obs.xml Magnifier - observation xml labelled with 'HESS' (424 Bytes) Lu Chia-Chun, 05/09/2014 08:44 AM

ctlike.log - ctlike works but background parameters are not fit (15.4 KB) Lu Chia-Chun, 05/09/2014 08:45 AM


Recurrence

No recurrence.


Related issues

Related to ctools - Action #1288: ctmodel doesn't work for GCTABackground3D Rejected 07/21/2014

History

#1 Updated by Lu Chia-Chun almost 10 years ago

#2 Updated by Lu Chia-Chun almost 10 years ago

#3 Updated by Lu Chia-Chun almost 10 years ago

#4 Updated by Knödlseder Jürgen almost 10 years ago

  • Tracker changed from Bug to Change request

#5 Updated by Knödlseder Jürgen almost 10 years ago

I guess the logic should be to check whether for every specified observation there is a corresponding background model. This would imply to hardwire some logic in the code that knows what model types are background model for a given instrument.

Maybe this can be done by searching the GModels container for GModelData type models with a specific instrument identifier. This would at least work for CTA and alike. The same logic can apply for COMPTEL.

For Fermi-LAT things are more complicated, as a source model is used to model the background. Here one would need to check for diffuse model components, without any guarantee that we can unambiguously identify the correct component. Maybe we should not apply this test for Fermi-LAT?

In any case, it should lead to a simple warning in the log file, and the executing of ctlike should continue, so that users could use ctlike w/o background model.

Maybe this is best implemented by a ctools support function, so that other code (such as ctmodel) can use the same code. Alternatively, one would add a method to gammalib to do the job (e.g. GObservations::check_model(const GLog& log)) that returns a flag and that dumps warning to a logger.

#6 Updated by Lu Chia-Chun almost 10 years ago

I think checking “for every specified observation there is a corresponding background model” is a very nice way, but I didn’t realize it’s so complicated to implement such a function in gammalib.

An alternative instead of adding a lot of check loops in the code is to build a troubleshooting database. I don’t think I will fall into the same trap the third time. I’ve learned it, but it’s a mistake people can easily make and most end users probably don’t have time and ability to dive into the code to find the problem.

Knödlseder Jürgen wrote:

I guess the logic should be to check whether for every specified observation there is a corresponding background model. This would imply to hardwire some logic in the code that knows what model types are background model for a given instrument.

Maybe this can be done by searching the GModels container for GModelData type models with a specific instrument identifier. This would at least work for CTA and alike. The same logic can apply for COMPTEL.

For Fermi-LAT things are more complicated, as a source model is used to model the background. Here one would need to check for diffuse model components, without any guarantee that we can unambiguously identify the correct component. Maybe we should not apply this test for Fermi-LAT?

In any case, it should lead to a simple warning in the log file, and the executing of ctlike should continue, so that users could use ctlike w/o background model.

Maybe this is best implemented by a ctools support function, so that other code (such as ctmodel) can use the same code. Alternatively, one would add a method to gammalib to do the job (e.g. GObservations::check_model(const GLog& log)) that returns a flag and that dumps warning to a logger.

Also available in: Atom PDF