Christoph Deil

OK, so there's concerns about this XML model spec format and ideas to make better model spec formats. Personally I agree that YAML would be nicer both as a serialisation...

There's a thread on this on the ctools mailing list today. @jknodlseder Is it possible to make the ctools mailing list archives public so that we can link to this?

> Question: Why is the OBS_ID allowed in the effective areas, but not in the rest of the IRFs? No good reason. Looks like it was added in https://github.com/open-gamma-ray-astro/gamma-astro-data-formats/commit/abeee47250fad24fd65e1c9e54919e876f8a2ffb#diff-f560ad1cc04c0ea518004c6df78b7549R50 without...

Fine with me to put the more precise formulae. Can you please make a pull request? For such little changes you can just go to the file on Github and...

I think the spec is complete concerning what is required. Is that correct or is something required missing? The description of optional things is certainly minimal and could be improved....

My understanding is that science results always depend on the product `aeff * obs_time * (1 - dead_time_fraction)`, so whether to store the dead time fraction separately, or multiply it...

> Does the per-telescope deadtime really matter? No, at DL3 per-telescope quantities don't matter. The data model is EVENTS and IRFs for sub-arrays. Everything per-telescope should happen at lower levels...

What we have now (a single number `DEADC` in the EVENTS header) works for all existing instruments, no? Yes, in the future CTA might have something more complex, but IMO...

Just a note: there was some discussion that's related to this issue in #97. I briefly re-read the discussion here, and to be honest I'm not sure if any change...

For the record: I've changed my mind on this. As already mentioned in https://github.com/open-gamma-ray-astro/gamma-astro-data-formats/pull/97#issuecomment-428214663 my suggestion for IACT data would be to compute AEFF and BKG rate models **at the...