GammaLib

I just check: reducing temporarily the bookkeeping in GSPIEventCube to a minimum does not reduce the computing time, hence bookkeeping should not be an issue.

I guess the possible reason for the difference is the large number of parameters. GammaLib does not handle efficiently the gradients for a large number of parameters. For every event bin, all gradients have to be initialised to zero (which means that for every bin several 1000 zeros are written) and then the several 1000 gradient values are checked to fish out the gradient value that did change for a given event (it’s just a single one!).

I cross-checked this by implementing an eval() method that directly operates on the gradient vector, avoiding to use the gradients stored in the model parameters. This gave the same fitting results after only 8 seconds, hence slightly faster than spi_obs_fit. This calls for a redesign of the code that allows using such an alternative eval() method.

I added the methods GModel::has_eval_indices() and GModel::eval_indices() to allow for a more efficient computation.

GModel::has_eval_indices() echos a boolean flag m_has_eval_inx that can be set to inform the GObservation::model() method that a list of parameter indices that were updated by eval() is available. This list can then be access via the GModel::eval_indices() method that returns the vector of integers m_eval_inx. Both members, m_has_eval_inx and m_eval_inx, have to be managed by the clients, i.e. they need to set or reset the flag and the vector.

I implemented handling of these flags in GSPIModelDataSpace::eval(). Now ctlike for the above example takes less than 8 seconds. This is really great!

I added the POINT model.

• DATE
• EVCLASS
• GEDFAIL
• GEDANNEAL