Feature #1872

Support weight attribute for spatial composite models

Added by Tiziani Domenico about 8 years ago. Updated about 8 years ago.

Status:ClosedStart date:10/18/2016
Priority:NormalDue date:
Assigned To:Tiziani Domenico% Done:

100%

Category:-
Target version:1.2.0
Duration:

Description

A vector of weights should be added to the class GModelSpatialComposite that allows for model components with different amplitudes.

The value should be read from an attribute in a component’s XML element:

<spatialModel type="Composite>
   <spatialModel type="GaussFunction" weight="0.7">
    ...
    </spatialModel>
    <spatialModel type="GaussFunction" weight="0.3">
    ...
    </spatialModel>
</spatialModel>

1_DEC.png (46.8 KB) Tiziani Domenico, 10/27/2016 09:49 AM

1_RA.png (46.9 KB) Tiziani Domenico, 10/27/2016 09:49 AM

2_DEC.png (46.8 KB) Tiziani Domenico, 10/27/2016 09:49 AM

2_RA.png (39.7 KB) Tiziani Domenico, 10/27/2016 09:49 AM

Index.png (47 KB) Tiziani Domenico, 10/27/2016 09:49 AM

Prefactor.png (48.5 KB) Tiziani Domenico, 10/27/2016 09:49 AM

1_dec 1_ra 2_dec 2_ra Index Prefactor

Recurrence

No recurrence.

History

#1 Updated by Knödlseder Jürgen about 8 years ago

  • Assigned To set to Tiziani Domenico

A minor comment: I’m wondering whether weight is an appropriate attribute name, or whether we many not consider something like scale. The intention here is to scale a model with respect to it’s intrinsic normalisation. We use already the term scaling for this kind of model modification (see for example the use of the <scaling> tag here: http://cta.irap.omp.eu/gammalib-devel/users/user_manual/modules/model.html#xml-model-definition-format).

Note that while the sum over all weight attributes should be 1, the sum over all scale attributes should be the number of model components.

#2 Updated by Tiziani Domenico about 8 years ago

  • % Done changed from 0 to 10

OK I think we can also call it scale for consistency reasons.
In either way it will be a problem, when to check if the sum over all scales has the correct value. We can’t really tell how many components there will be in the composite model when components are appended. So the composite model will be in an invalid state as long as not all components have been added.
Do you have any ideas how we could solve this problem?

#3 Updated by Mayer Michael about 8 years ago

I think each scale is 1.0 on default, right. In my view there doesn’t need to be a rule on what the sum of all scales has to be. For instance, I have two Gaussians and just want to scale one of them by 0.5, the user should be do that without thinking how to scale the other one.
Ideally, the code can figure it out in the eval-method and apply the correct scaling for the normalisation. I guess this requires changes in the GCTAResponse methods as well, where we divide (for now) just by the number of components.

#4 Updated by Knödlseder Jürgen about 8 years ago

I would not do any implicit computations for that, since it will be difficult for the user to track down what’s going on. I guess when you are at the level of using the scale attribute you need to be aware of what you are doing, and that this may influence the flux you get. So I would simply apply the scale, and then describe well in the user documentation what this implies.

#5 Updated by Tiziani Domenico about 8 years ago

This feature is now implemented in the branch 1872-spatial-model-component-weights in my gitlab repo https://cta-gitlab.irap.omp.eu/dtiziani/gammalib.git .
The pull distributions that I generated for a composite model with two point sources with different scales seem to be OK:






#6 Updated by Knödlseder Jürgen about 8 years ago

I integrated your code. I’m currently running the integration tests and will drop a note once the code is merged into devel.

I changed the method name component_scale() to scale() since simple method names are preferred.

#7 Updated by Knödlseder Jürgen about 8 years ago

  • Status changed from Pull request to Closed

Merged into devel.

Also available in: Atom PDF