ctools

We had this already some time I ago (see #1445). These are two distinct informations that have not necessarily to do with each other. The purpose of the XML ID is to link an observation to a model. The OBS_ID is an OGIP standard (see https://heasarc.gsfc.nasa.gov/docs/heasarc/ofwg/docs/general/ogip_94_001/ogip_94_001.html) and is a sequence number.

But by reading the OGIP document again, I see that it says it’s a string. In Karl’s event format document this is an integer, and also on https://gamma-astro-data-formats.readthedocs.io/en/latest/events/events.html it’s an integer (well, I wrote that part of the document).

We could (and probably should) transform it to a string. But there is still the problem that you could image that two event files have the same OBS_ID value, but in the XML file the id’s must be unique. I see no good way to make both things identical.

Thanks for pointing out the previous discussion - I forgot about this.
Nevertheless, just from a user perspective, I think it would be good to increment the m_obs_id attribute for each observation in ctobssim (unless it is already provided in an input observation container). Having all obs_id as zeros in the simulated FITS files is a bit confusing, right?
In case no obs_id is given e.g. like in the above XML example, we could start from obs_od=1 and increment by one for each observation. Alternatively, we could leave it as it is and just expand the above format by an optional XML element:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<observation_list title="observation list">
  <observation name="None" id="000001" instrument="CTA">
    <parameter name="Pointing" ra="83.63" dec="22.01" />
    <parameter name="EnergyBoundaries" emin="200000" emax="3e+07" />
    <parameter name="GoodTimeIntervals" tmin="0" tmax="20" />
    <parameter name="TimeReference" mjdrefi="51544" mjdreff="0.5" timeunit="s" timesys="TT" timeref="LOCAL" />
    <parameter name="Deadtime" deadc="0.95" />
    <parameter name="ObsID" obs_id="1" />
  </observation>
  <observation name="None" id="000002" instrument="CTA">
    <parameter name="Pointing" ra="83.63" dec="21.01" />
    <parameter name="EnergyBoundaries" emin="400000" emax="2e+07" />
    <parameter name="GoodTimeIntervals" tmin="20" tmax="40" />
    <parameter name="TimeReference" mjdrefi="51544" mjdreff="0.5" timeunit="s" timesys="TT" timeref="LOCAL" />
    <parameter name="Deadtime" deadc="0.95" />
    <parameter name="ObsID" obs_id="2" />
  </observation>
</observation_list>

The point is that OBS_ID is set by the provider of the data, we formally don’t have control over that. The purpose of the obs_id() method is to return simply the attribute that was set by the data provider.

But I agree that for ctobssim, which is in fact a data provider, we should increment the m_obs_id as you suggest. I simply did not care so far about the content of that attribute

Would this be sufficient, or are there cases where you want to specify this in the XML file?

Would this be sufficient, or are there cases where you want to specify this in the XML file?

I think it would be sufficient to just increment by one. However, adding the option in the XML file probably allows for more flexibility.
The reason I stumbled upon this was because I was creating a script to simulate a IACT database with more realistic obs_id values (e.g. OBS_ID=28001). So I had to set the OBS_ID manually in the script (which is not a big deal). I am not sure if there is indeed another use case why we should have it in the XML format.

Then I would prefer to implement the ctobssim incrementation of that value. Probably we want to add a hidden obsid parameter that would be taken as value of the first observation. This will provide full control over the obsid assignment, for example in case that multiple ctobssim runs will be combined.

There is still the other pending question on whether to use an integer or a string. I would suggest a string. But before changing this for GammaLib I’d like to discuss this with the data formats group. I just created an issue at https://github.com/open-gamma-ray-astro/gamma-astro-data-formats/issues/64.

We may also decide to keep for the moment the integer interface (which is more natural for a value that will be incremented), but use a string when writing to the FITS file.