GammaLib

Dear the system admin (Jürgen?)

Could you please remove co_OriB.fits from this page? I did not realize that this Redmine page was public.

I took a look at the source code of GModelSky and GModelSpatialDiffuseMap.

void GModelSpatialDiffuseMap::load(const std::string& filename)
{
    // Initialise skymap
    m_map.clear();

    // Store filename of skymap (for XML writing). Note that we do not
    // expand any environment variable at this level, so that if we write
    // back the XML element we write the filepath with the environment
    // variables
    m_filename = filename;

    // Load skymap
    m_map.load(gammalib::expand_env(m_filename));

    // Prepare sky map
    prepare_map();

    // Return
    return;
}

void GModelSky::set_type(void)
{
    // Clear model type
    m_type.clear();

    // Continue only if we have a spatial model component
    if (m_spatial != NULL) {

        // Is spatial model a point source?
        if (dynamic_cast<const GModelSpatialPointSource*>(m_spatial) != NULL) {
            m_type = "PointSource";
        }

        // ... otherwise, is spatial model a radial source?
        else if (dynamic_cast<const GModelSpatialRadial*>(m_spatial) != NULL) {
            m_type = "ExtendedSource";
        }

        // ... otherwise we have a diffuse model
        else {
            m_type = "DiffuseSource";
        }

    } // endif: there was a spatial model component

    // Return
    return;
}

1. Rename GModelSpatialDiffuseMap::prepare_map to GModelSpatialDiffuseMap::normalize_map
2. Remove prepare_map(); in GModelSpatialDiffuseMap::load
3. Add (dynamic_cast<const GModelSpatialRadial*>(m_spatial))->normalize_map(); after m_type = "ExtendedSource";

Since I am not an expert of ctools or GammaLib, I may be writing something stupid. But I would appreciate it if you could review the implementation for diffuse sources.

Hello Jürgen,

I suppose that you and your colleagues have already discussed on this spatial map design and philosophy. But please allow me to post my opinion here.

Knödlseder Jürgen wrote:

I would argue that the thing is not done correctly in the Fermi Science Tools, as the number you get out of gtlike is in fact in arbitrary units.

I partially agree, but partially not. From a point of view as a software developer, the units used in a program should be consistent with each other. So I understand that calculating arbitrary units in gtlike or ctlike should be avoided. But from an astrophysical point of view, units used in FITS files are often arbitrary. For example, gas extinction map, e.g. E(B-V), is written in a “unit” of magnitude which cannot be expressed with MKSA units. CO maps, which are of course very important to analyse SNRs and diffuse emission, has a different unit (K km/s), N(HI) maps use (cm-2). If CFITSIO or GammaLib can handle these arbitrary units in a good unified way, I support your idea that we had better use the same unit in ctlike.

I have another reason to oppose your idea. Assuming that we have a diffuse gas template made from HI or/and CO when analysing the Galactic plane that is much larger than the CTA FOV, what is the physical meaning of the flux calculated in (/s/TeV/cm2)? Is this the total diffuse flux of the Galactic plane? Or is it the flux integrated in the FOV? Neither is the correct answer.

In addition, continuity and compatibility with Fermi Science Tools are important.

I had in fact several times people contacting me about the way how they have to prepare a map for Fermi analysis, and this is not necessarily a trivial task as the solid angles need to be computed correctly.

I understand. So we had better have two options in ctools: “ExtendedSource” for SNRs, AGN lobes and so on, and “DiffuseSource” for literally diffuse sources such as molecular clouds and the Fermi bubble.

But I understand that you need some method or way to get the normalization factor, or to prevent normalization. So we have to think how to handle this. One could add an attribute to the XML file that prevents normalization (something like normalize=“0” if no normalization is requested). In any case, I would store the normalization factor in the class so that it can be accessed for further usage.

Adding a new option “normalize” is OK for me. But as I wrote above, differentiate “ExtendedSource” from “DiffuseSource” will work. What do you think?

Alternatively, one could also add a header keyword in the FITS file to prevent normalization. But this would be somehow fancy, so I won’t really recommend this.

~10% of the users do not know how to edit FITS files

The Prefactor is indeed ignored in the Monte Carlo simulations, as the spatial component is assumed to be always unit in GammaLib. I was in fact not expecting that somebody uses this Prefactor to scale things. I created bug #1135 for this issue.

Thank you very much.

Okumura Akira wrote:

Hello Jürgen,

I suppose that you and your colleagues have already discussed on this spatial map design and philosophy. But please allow me to post my opinion here.

Knödlseder Jürgen wrote:

I would argue that the thing is not done correctly in the Fermi Science Tools, as the number you get out of gtlike is in fact in arbitrary units.

I partially agree, but partially not. From a point of view as a software developer, the units used in a program should be consistent with each other. So I understand that calculating arbitrary units in gtlike or ctlike should be avoided. But from an astrophysical point of view, units used in FITS files are often arbitrary. For example, gas extinction map, e.g. E(B-V), is written in a “unit” of magnitude which cannot be expressed with MKSA units. CO maps, which are of course very important to analyse SNRs and diffuse emission, has a different unit (K km/s), N(HI) maps use (cm-2). If CFITSIO or GammaLib can handle these arbitrary units in a good unified way, I support your idea that we had better use the same unit in ctlike.

Ideally I would like to interpret the units of the FITS file, but almost nobody sets these correctly, hence we cannot reply on this possibility.

I have another reason to oppose your idea. Assuming that we have a diffuse gas template made from HI or/and CO when analysing the Galactic plane that is much larger than the CTA FOV, what is the physical meaning of the flux calculated in (/s/TeV/cm2)? Is this the total diffuse flux of the Galactic plane? Or is it the flux integrated in the FOV? Neither is the correct answer.

Agree. This case is not well covered.

In addition, continuity and compatibility with Fermi Science Tools are important.

Well, GammaLib provides it’s own Fermi tools, and my goal was rather to convince Jim at some point to adopt a common XML format

I had in fact several times people contacting me about the way how they have to prepare a map for Fermi analysis, and this is not necessarily a trivial task as the solid angles need to be computed correctly.

I understand. So we had better have two options in ctools: “ExtendedSource” for SNRs, AGN lobes and so on, and “DiffuseSource” for literally diffuse sources such as molecular clouds and the Fermi bubble.

The difference between ExtendedSource and DiffuseSource is that the first is a parametric model (where the parameters describe the extension and shape of the model), while the second is a map. SNRs and AGN lobes are thus a DiffuseSource, and from the code you cannot distinguish them from molecular clouds or Fermi bubbles.

But I understand that you need some method or way to get the normalization factor, or to prevent normalization. So we have to think how to handle this. One could add an attribute to the XML file that prevents normalization (something like normalize=“0” if no normalization is requested). In any case, I would store the normalization factor in the class so that it can be accessed for further usage.

Adding a new option “normalize” is OK for me. But as I wrote above, differentiate “ExtendedSource” from “DiffuseSource” will work. What do you think?

As described above, the logic behind is different, so I would prefer adding an attribute. What about adding a unit attribute? This can be even very general as an extension to the Fermi Science Tools format. If specified, GammaLib would read the unit from the attribute (each model parameter has in fact an attribute string), and we could use the attribute to switch between functionalities. For example unit="arbitrary" as in the example below could switch off the normalization:

        <spatialModel type="SpatialMap" file="data/cena_lobes_parkes.fits">
            <parameter scale="1" name="Prefactor" min="0.001" max="1000.0" value="1" free="0" unit="arbitrary"/>
        </spatialModel>

Alternatively, one may add a normalize attribute as shown below:

        <spatialModel type="SpatialMap" file="data/cena_lobes_parkes.fits" normalize="0">
            <parameter scale="1" name="Prefactor" min="0.001" max="1000.0" value="1" free="0"/>
        </spatialModel>

Okumura Akira wrote:

Dear the system admin (Jürgen?)

Could you please remove co_OriB.fits from this page? I did not realize that this Redmine page was public.

We’re doing open source

Adding normalize and/or unit sounds reasonable. Then an XML itself will explain everything that the user is doing.

http://gammalib.sourceforge.net/user_manual/modules/model.html

FYI. The very bottom of the above document made Tak and me very confused. While this explanation is not written for DiffuseSource but for FileFunction,

cm?2s?1MeV?1sr?1 for a diffuse source

is a bit misleading for users who want to simulate diffuse sources with DiffuseSource. Adding a short note about the unit would be helpful.

Okumura Akira wrote:

http://gammalib.sourceforge.net/user_manual/modules/model.html

FYI. The very bottom of the above document made Tak and me very confused. While this explanation is not written for DiffuseSource but for FileFunction,

cm?2s?1MeV?1sr?1 for a diffuse source

is a bit misleading for users who want to simulate diffuse sources with DiffuseSource. Adding a short note about the unit would be helpful.

You’re right. I think this statement is simply wrong and should be changed. Thank your for catching that.

Well, there is one case where the units are per MeV, which is the constant diffuse model used for isotropic emission. This needs to be stated clearly somewhere when models are introduced, because this applies to all kinds of spectral models.