GammaLib

Great! Note that there should also be a GModelSpectralLogParabola.i in the pyext folder which will create the Python bindings for the model component. You also have to add the .i file to the list of includes in pyext/gammalib/model.i.

To compile the GModelSpectralLogParabola.cpp file, you need to add the file to the src/model/Makefile.am file. For the include file, you should do the same in include/Makefile.am.

I recommend launching ./autogen.sh after editing the Makefile.am files so that things will be clean.

Ok great, thanks for this important note.

Adapting the code, I encountered two issues we should discuss how to deal with:

• In the Fermi Science Tools, the LogParabola model uses the parameters “norm”, “alpha” and “beta”. This seems to be inconsistent with other spectral models, where the normalization parameter is always named “Prefactor”. I think that “index” and “curvature” would be more meaningful names than “alpha” and “beta”. However, changing the parameter names would complicate crosschecks when using with xml-files produced by the Science Tools.

• The function “GModelSpectralLogParabola::flux(const GEnergy& emin, const GEnergy& emax) const” is not analytically to calculate (at least I did not find a way to do it). Therefore, we would need to implement numerical integration of the function (this is probably similar to the ExpPlaw). Should it be implemented directly in this function, or did you already think of another solution? In addition: I am curios if there is a reason why the function “plaw_photon_flux(double emin, double emax, double pivot, double index)” for the PowerLawModel was outsourced to “GTools”?

Michael Mayer wrote:

Ok great, thanks for this important note.

Adapting the code, I encountered two issues we should discuss how to deal with:

• In the Fermi Science Tools, the LogParabola model uses the parameters “norm”, “alpha” and “beta”. This seems to be inconsistent with other spectral models, where the normalization parameter is always named “Prefactor”. I think that “index” and “curvature” would be more meaningful names than “alpha” and “beta”. However, changing the parameter names would complicate crosschecks when using with xml-files produced by the Science Tools.

Right, things are unfortunately not done coherently in the ScienceTools. What I recommend here (and what I did already for other model components) is that two different parameter names are supported (e.g. GModelSpectralConst which supports Normalization and Value, see GModelSpectralConst::read and GModelSpectralConst::write). This ensures compatibility with Fermi XML files (which I think is very important), but also allows to move towards a new standard. Maybe we should at some point discuss this with Jim Chiang to see whether we can move towards a common standard.

• The function “GModelSpectralLogParabola::flux(const GEnergy& emin, const GEnergy& emax) const” is not analytically to calculate (at least I did not find a way to do it). Therefore, we would need to implement numerical integration of the function (this is probably similar to the ExpPlaw). Should it be implemented directly in this function, or did you already think of another solution? In addition: I am curios if there is a reason why the function “plaw_photon_flux(double emin, double emax, double pivot, double index)” for the PowerLawModel was outsourced to “GTools”?

Numerical integration is already available in GammaLib. To see how this works you may check the method GCTAResponse::irf_extended. You first have to define a class that derives from GIntegrand and which implements an eval method with a single parameter (in the above mentioned case, this is done in the file GCTAResponse_helpers.hpp. The class implements the kernel over which you want to integrate. To perform the integration, use something like

GIntegral integral(&integrand);
integral.eps(m_eps);
irf = integral.romb(rho_min, rho_max);

I guess I should paste this small guide into a Wiki Howto section for developers

Concerning plaw_photon_flux, the reason for outsourcing was that it’s used by several classes (e.g. GModelSpectralFunc and GModelSpectralNodes, which make piecewise integrations).

Started a Development HowTo in the Wiki and added a first item on How to integrate a function.

I generally put these things directly in the class declaration (unless they have multiple usages), see for example GObservation which has class npred_temp_kern defined in the protected area.

Concerning the naming, I often use _kern as suffix (referring to “kernel”). As the classes are subclasses of GModelSpectralLogParabola it’s probably not necessary to add logparabola to the name, so you I would propose the shorter names flux_kern and eflux_kern (as they are used by the flux and eflux methods).

Hi Michael,

After discussions with Christoph (see https://cta-redmine.irap.omp.eu/boards/6/topics/22) I changed the Git workflow. Now, pushing to devel is not permitted anymore. You should create a specific feature branch that you push to the repository. Then, you should put the status of the feature to Pull request.

Read more on the page Git workflow for GammaLib.

If you have comments about the workflow, don’t hesitate to post them on the forum https://cta-redmine.irap.omp.eu/boards/6/topics/22.

The mc() method is not yet implemented.

I added action #654 for this reason. We should try to implement the method before shipping GammaLib-00-07-00.

Integration is finished, the new code is now available in the devel branch.

Congratulations, Michael, for your first contribution to GammaLib!

Looks great!

I added a Wiki page GModelSpectralLogParabola under Development notes. Could you post the plot there, and add eventually some notes related to the implementation? Ideally, we want to have all stuff related to code validation in this place.