GammaLib

I propose the following XML interface for an elliptical disk model (the spectrum part is simply for illustration):

  <source name="Crab(disk)" type="ExtendedSource">
    <spectrum type="PowerLaw">
       <parameter name="Prefactor" scale="1e-16" value="5.7"  min="1e-07" max="1000.0" free="1"/>
       <parameter name="Index"     scale="-1"    value="2.48" min="0.0"   max="+5.0"   free="1"/>
       <parameter name="Scale"     scale="1e6"   value="0.3"  min="0.01"  max="1000.0" free="0"/>
    </spectrum>
    <spatialModel type="EllipticalDisk">
      <parameter name="RA"          scale="1.0" value="83.6331" min="-360" max="360" free="1"/>
      <parameter name="DEC"         scale="1.0" value="22.0145" min="-90"  max="90"  free="1"/>
      <parameter name="PA"          scale="1.0" value="45.0"    min="-360" max="360"  free="1"/>
      <parameter name="MajorRadius" scale="1.0" value="1.00"    min="0.01" max="10"  free="1"/>
      <parameter name="MinorRadius" scale="1.0" value="0.50"    min="0.01" max="10"  free="1"/>
    </spatialModel>
  </source>

Michael Mayer wrote:

Class implementation almost finished... The only thing left is that I am still trying to find a way to implement the mc() - method.

Great. For MC, in the worst case you may simply use a rejection method.

By the way: I found a copy and paste issue in GModelSpatialElliptical::init_members(): At “Initialise Position Angle” there should be m_posangle initialised and not m_dec again . Is that a separate issue, or could it be combined with the commit of GModelSpatialEllipticalDisk?

For tiny things like this I recommend to just correct the bug and commit. In particular, no one is using so far the functionality, so no need to keep track of it in the tracker.

And also, we should think about different names of the radial models: E.g. “DiskFunction” → “RadialDisk” for GModelSpatialRadialDisk

I fully agree. Maybe we can start a discussion about this on the forum. I invented the names in analogy to Fermi-LAT, but they are badly chosen. We may want to define better names.

I was even planning to discuss with Jim Chiang about this, one of the core developers of the Fermi ScienceTools. It would be nice if we could find a common strategy for naming conventions, which would help to make this more compatible.

Another aspect is the virtual observatory: Ultimately, I would like to have models in a VO compliant format, but I’m not some that anything exists so far. I still need to learn more about VO formats, but in thinking about the XML format it would be nice to keep also this aspect in mind.

So before releasing a new version of GammaLib we probably want to clean up a bit the XML interface. I’m actually doing the very same thing for the C++ interface (see #692) with the aim to have a homogenous and stable interface that won’t be changed much in the future. This is quite a big task, but we better do this earlier than later.

Great!

I started to work on the integration and stumbled over this: https://github.com/pokerth/pokerth/pull/166. In fact, the integration failed on FreeBSD, and the link explains why. minor() and major() are predefined macros. So we can’t use them as methods! Here you see the power of a continuous integration system, you find really weired bugs in a few minutes. See: https://cta-jenkins.irap.omp.eu/job/gammalib-integrate-os/55/

I propose to remplace both names by semimajor() and semiminor(), which is more precise anyways.

BTW: I’ll be on vacation next week, so also from my side it will be silent.