3ML/astromodels issues and desired features

[israelmcmc]

This is to keep track of all issues or desired features in one of our main dependencies, threeml/astromodels

Issues

Open

In progress / under review

In dev but not yet released

Desired features

Open

• Move customs function in cosipy to 3ML:
  -Move Band_Eflux to 3ML #74 (Band, Band_Calderone and Band_grbm are parametrized based on the differential flux, while Band_Eflux is parametrized based on the integrated energy flux)

• Change how 3ML configures logging: Change how threeML configures logging (or rather, do not configure logging) threeML/threeML#647

• Can we make import threeML works without startup_warnings by default (without a config file)? Fix custom startup_warnings setup in user configs threeML/threeML#680

• Revisit which functions are really benefitted by njit. e.g. plaw_eval seems to be just as fast or faster in some systems with njit disabled. This is making our model folding slower. Related PR Add threeml Gaussian and Powerlaw function with torch #628

In progress / under review

In dev but not yet released

[jdbuhler]

Desired feature: an integral method for Functions where we can stick a closed-form formula or approximation so we don't have to use numerical integration.

[jdbuhler]

Resolved but not released: memory release patch to prevent keeping COSILike object around after gc.

[israelmcmc]

Thanks @jdbuhler. I added them to the list with links

[ndilalla]

Thanks @jdbuhler. I added them to the list with links

This fix has been actually released with threeml v2.5.0!

[israelmcmc]

Note: @PreisTo is looking into the integrate function threeML/astromodels#257

[GallegoSav]

We also need to merge my pr : threeML/astromodels#247

Because we need this to makes correct fit with a full sky template.
But I need to fix the unit test

[israelmcmc]

Thanks @GallegoSav. I added it to the list.

[israelmcmc]

I'm removing these since they are part in threeml v2.5.0

• Memory release patch to prevent keeping COSILike object around after gc. See Build-up of the RAM using COSILike for LH fit #430 and Using weakref instead of strong callback links. threeML/threeML#664

• Circular import issue. Solved by Send logs to stderr by default threeML/threeML#646

[israelmcmc]

Added threeML/astromodels#264

[israelmcmc]

Adding threeML/astromodels#280

[israelmcmc]

Tagging #628, PR but related.

[israelmcmc]

I removed a bunch of issues resolved with the release of astromodels v2.6.0. Thanks @PreisTo and @ndilalla!

[jdbuhler]

Note for today's meeting... PRs #284 and #285 propose cleanups in the function and source classes, respectively. 284 was motivated by experiments (shown in the PR summary) suggesting that Numba is not really helping performance in the Function1D classes. 285 is based on some experiments by Savitri Gallego that found that small changes to the call method enable large speedups with Torch-accelerated functions while not slowing down the general case. (It also removes some gratuitous Numba usage and iterator-to-list conversion.)

I would like to see these changes move toward adoption in Astromodels. Particularly if we are thinking about future parallelization via Torch, we want to remove older and often ineffective attempts to accelerate the code.

My main question is, what is the path to getting the changes adopted? At a low level, I fixed the code style as requested, but there are some other infrastructure bits that are still causing failures. At a high level, are there "standard" performance test cases that we could use to show that the changes are likely to be beneficial to neutral for reasonable use cases?

[israelmcmc]

Thanks @jdbuhler. Note: I edited the links

[israelmcmc-ai]

@jdbuhler Following up on this based on the discussion:
@ndilalla suggested to use the existing astormodels jupyter notebook as benchmark to measure optimization gain. We’re aware that it doesn’t cover all bases, but we were all fine to proceed with your PRs as long as it doesn’t make these slower. If at a later timer we realize that a more complicated analysis (e.g. Fermi) became slower, we can revisit, but I don’t expect that to be the case
@PreisTo asked to check if the performance is not degraded for a single query --i.e. even if there’s an advantage from vectorization and a large number of evaluation points, there are some use cases for single float calls.

[jdbuhler]

Thanks for the suggestions. It will be a couple of weeks before I can get to this, but I'll take a look.