Broadening the scope of ronswanson: building table models for other software?

[cosimoNigro]

This issue is related to ronswanson's review for the journal of the open source software, specifically to the item:

Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines

The software is quite young, it started in summer 2022. I do not doubt the amount of work it went in, nor that it will be cited in future; but the fact that it produces template models only for one specific software (3ML), I think makes its scope a bit narrow. Would it be too much work to allow to generate also template models for other packages that have serialisable models (also via .yaml files), e.g. gammapy? I think it would be a huge advantage for this work and it would significantly broaden its scope and usage.

On the other hand, maybe the authors consider this outside of their original intention. It would be good to hear their opinion on this. From a quick look at the documentation, it seems to me that the database with the model and its parameters can be dumped in a 3ML model. Can't a functionality be added to do the same with gammapy? Are there other fundamental routines in ronswanson using 3ML?

If finally generating gammapy-compatible models is judged too much, then maybe a paragraph in the paper can outline future possible expansions of ronswanson to other modelling packages with serialisable models?

[grburgess]

@cosimoNigro I think this is a fair point and could be added on at some point, but this effort may be irrelevant as there is already an existing bridge in 3ML to use gammapy. Specifically, there is a plugin which pumps the models in astromodels into the gammapy likelihood allowing all the fitting capabilities (and multi-instrumental bridges) in 3ML to intefface directly with instruments that utilize gammapy as their likelihood interface:

This work is still preliminary and there have been some small discussions on perhaps having a single modeling language like astromodels in future versions of gammapy to ease the effort currently underway in developing the gammapy plugin. So for now I would like to push this off to a future version... if it will even be needed at all.

On a side note, is there a similar model template model factory in gammapy like what is provided in astromodels? I could not find this in the docs, but it would make having a future interface easier.

Does this satisfy your concern?

[cosimoNigro]

This work is still preliminary and there have been some small discussions on perhaps having a single modeling language like astromodels in future versions of gammapy to ease the effort currently underway in developing the gammapy plugin. So for now I would like to push this off to a future version... if it will even be needed at all.

Maybe you can find a way to mention this briefly in the paper? Was this "pumping of the astromodels directly in the Gammapy likelihood" presented in some conference already?

On a side note, is there a similar model template model factory in gammapy like what is provided in astromodels? I could not find this in the docs, but it would make having a future interface easier.

Not that I am aware of.

Does this satisfy your concern?

As written above, if you can mention this bridge with Gammapy it would be great. I understand what I was asking is an effort larger than the software scope at this particular moment in time.

[grburgess]

@cosimoNigro I have implemented these into the paper now.

[cosimoNigro]

Thanks. All good then.