Translating {EpiNow2} to Julia

[fkrauer]

Dear Julia Epis

Thank you all for joining the GitHub Org. The idea is to host different Julia packages, applications or just bits of code related to all things EPI(demiological) through collaborative action.

As a first pilot project, we (@seabbs and I) would like to translate EpiNow2 to Julia. The package estimates the time-varying reproduction number (Re) from time series data. The fitting is currently done with stan, but this can take quite long depending on the settings. We think this can be done faster in Julia, possibly with AdvancedHMC.jl or DynamicHMC.jl .

We both are new to Julia, which is why we need help from people who are experienced with programming Julia packages and know the internals of either of the Julia HMC libraries.

The project is currently unfunded, but we could try to get a small grant from NumFocus for an RSE. AFAIK this wouldn't be a full position, more like a consulting fee. I also don't know about tax-related aspects of this. The deadline for proposal submission is 2. September 2022. @ChrisRackauckas knows more about this funding opportunity.

I suggest we have a zoom chat to setup a scope document (is that what you call it, @seabbs?). If anyone is interested in contributing, please let us know here in the chat and we'll schedule a virtual meeting some time this or next week.

Best, Fabienne

EDIT: @pitmonticone @ClaudMor is it possible to notify/tag all members of this Julia Epi about this discussion?

[pitmonticone]

Hi @fkrauer,

Thank you for writing this discussion!

Yes, it's possible to mention all members of JuliaEpi by creating a general team including all members and then mentioning it. I don't know if there's a more efficient way to achieve the same.

I'm going to create the "Members" team here.

[pitmonticone]

Ok @fkrauer. Now you should be able to mention everyone so that they get notified via the "(at)JuliaEpi/members" handle.

[fkrauer]

tagging all members of Julia Epi @JuliaEpi/members, please see my post above :)

[Song921012]

Wow, nice! I am not good at developing packages, but I am willing to do what I can do. EpiNow2 is an excellent package.

[seabbs]

Thanks @fkrauer,

I think this is a great idea and something I have been thinking about for a while so this is pretty exciting.

I'd just note that the approach EpiNow2 takes is from a family of semi-mechanistic approaches of which there are several other neat implementations (for example epidemia (@bhattsamir et al.)). I think the Turing lab may already have some version of these methods implemented in Julia potentially as well?

As we discussed on our call there are two big positives to a Julia reimplementation. One is making easily shareable code for some of the repeated actions needed in these kinds of tools (i.e renewal equations, discrete convolutions etc) and the other is making something actually useful for practitioners. I think that if we implement something relatively simple in the first instance focusing on the latter (i.e sensible defaults, non-parametric estimation targeted towards real-time or retrospective use cases) but with an eye on the former that could really empower other projects that might want to switch to Julia (for example my more recent work on epinowcast shares a similar set of functions but reimplemented as sharing stan is hard which is not very elegant/robust).

Sam

[bhattsamir]

Much of the renewal work I have done of recent is written in Julia. The speed is, of course unrivalled. Inference however is the issue, I have written the same code in Rstan, numpyro and turing, and through the use of matrix computation there is no comparison with Rstan and turing vs numpyro. Turing is fast, and customisable, but it would be good to think of GPU acceleration such as that Jax allows.

[seabbs]

Definitely agree. That aside though I think the benefits of Julia vs stan in this space are pretty clear (unit testing, code portability, composability) and so for less performance-sensitive problems (i.e towards the simpler cases) even without GPU acceleration worth doing.

[SamuelBrand1]

This sounds like a great idea.

There is indeed a Turing version of an early version of epidemia (I think!) here. But I lost track of what did what.

Re: GPU acceleration. I'm a mac user without a CUDA-supported GPU aarrrgggghhh! Heard very good things about Jax/numpyro GPU autodiff, though (which would be critical for this kind of thing). My current playground is Metal.jl (the v recent link to the Max Metal GPU kernel for M-series GPUs). But I haven't tested autodiff functionalities (big array operations are pretty fast though....).

In the CUDA + Julia world, if I was asked to create an epidemia-type model with GPU acceleration and autodiff (for HMC plug-ins) I'd go with making a discrete time model in SciML style and use https://github.com/SciML/DiffEqGPU.jl .

[SamuelBrand1]

Literally just noticed that @pitmonticone is a Metal.jl contributor... great work mate!

[pitmonticone]

Hi @SamuelBrand1,

I'm a macOS user too, but I'm not at all a core contributor of Metal.jl. Just an early user who fixed a few typos in the docs while consulting them.

[SamuelBrand1]

Hi @fkrauer !

I'd be up for contributing to this as much as possible including looking at/contributing to a bit of numfocus funding.

@pitmonticone and I met at a Royal society meeting a few weeks back, and chatting about Julia in Epi the idea of doing a Julia version of EpiNow (or some EpiNow functionality) was something we both thought sounded like a great idea!

[InterdisciplinaryPhysicsTeam]

Hi all @JuliaEpi/members,

We've just created the child/sub-team for all JuliaEpi members working on the translation of {EpiNow2} functionalities into Julia.

If you're interested please consider joining here.

[ChrisRackauckas]

The project is currently unfunded, but we could try to get a small grant from NumFocus for an RSE. AFAIK this wouldn't be a full position, more like a consulting fee. I also don't know about tax-related aspects of this. The deadline for proposal submission is 2. September 2022. @ChrisRackauckas knows more about this funding opportunity.

It's the NumFOCUS small development grants. For general Julia things you'd apply as a representative of the JuliaLang organization. For SciML work you'd apply as a representative of the SciML organization. But either way, it's funding to the NumFOCUS organizations for doing development and maintenance.

[fkrauer]

Thanks @ChrisRackauckas . In the funding submission, do we already have to identify the person for which we apply the money for? And can it be someone from the SciML org (like a steering or advisory member), or is this a COI?

[ChrisRackauckas]

The person is you. You, as a person of the JuliaLang organization or as a person of the SciML organization, would apply for the grant. You should first okay this with the governing body, but such a nebulous organization is made up of the members and contributors of the community, including you, who could apply for the grants on behalf of the organization.

[fkrauer]

Right, so e.g. I (or @seabbs) can apply for funding for a project, but then use the money to hire/pay an RSE to do some of the work? The fiscal implications of the whole thing are a bit unclear to me. We are academic employees in the UK. Would the funding be given to our University (which will probably take some overhead?), or will NumFocus give the funding to e.g. SciML and they would pay whomever we hire directly?

[ChrisRackauckas]

Whomever applies should be the person contracted to do the work. They would be paid directly through NumFOCUS.

[bdklahn]

Did anything ever come of this? A colleague is using EpiNow2.
I'm currently waiting for EpiNow2 to install in Apptainer, on my beefy server-grade desktop machiine. It's taking forever (was over an hour, so far) via Github Actions Docker buildx build. The more I've been using Juila, the more I love it's speed and fundamental design. I would love for (tools like) this to be ported over to Julia. -because I know dependency compilation will be only the beginning of the slowness and unnecessary complexity of using R. For "open source", I really wish R would better support open source OSes with binary builds. I wish I knew more about the algorithms to be able to help implement this in Julia.

[SamuelBrand1]

Hey there!

I've been totally distracted by a new job (I now work for the Centre for Forecasting and Outbreak Analytics which is a fairly new group within CDC).

However, I'm now a colleague of @seabbs and we've talked about a Julia version of Epinow2 which incorporates good ideas from epidemia and epinowcast. But this project has not taken off yet.

[seabbs]

Yeah as @SamuelBrand1 says the short answer is no not yet. The long answer is hopefully once we/I get some capacity. At the moment most of the focus is on epinowcast which is the successor of EpiNow2 (also stan/R based) which should improve things for you a little hopefully.

On the user side if you have any issues then feel free to use the EpiNow2 discussion board and we will try and help (as capacity allows).

[bdklahn]

Hey there!

I've been totally distracted by a new job (I now work for the Centre for Forecasting and Outbreak Analytics which is a fairly new group within CDC).

However, I'm now a colleague of @seabbs and we've talked about a Julia version of Epinow2 which incorporates good ideas from epidemia and epinowcast. But this project has not taken off yet.

Thanks for responding, @SamuelBrand1 !
Interesting.
That's encouraging. I can understand other job duties, etc. . . .
I work with a great group of epidemiologists at the Biocomplexity Institute at University of Virginia. We mostly use Python (+ C/C++) with a little R for the epi codes.
I'm just a little frustrated: The compilation of EpiNow2 Linux dependencies ended up taking almost 5 hours in Github Actions (linux/amd64, linux/aarm64). It looks like I could base my R build on an Ubuntu jammy repo (R2u), and get pre-built GNU/Linux binaries. But I was hoping to just use the latest Julia, Micromamba, and R containers, without a lot of fiddling with paths and symlinks, etc. My hope is/was to create a reproducible/portable environment where epidemiologists could run their favorite script/language code. But some languages seem to always complicate things. :-)
I'm currently just going to have the R container built in a separate stage (which I may almost never update, if it will take forever), and pull that into the later ones with Julia and Python (via Micromamba).

But I've been thinking to use Julia more, because I see that as a great way to more easily move the research script software to production, without having to completely re-rewrite/factor in/with another (faster) language.

[seabbs]

The compilation of EpiNow2 Linux dependencies ended up taking almost 5 hours in Github Actions (linux/amd64, linux/aarm64).

This is a really surprising amount of time and does sound very annoying. The most I have seen is about 40 minutes (which I agree isn't great).

Is this container from scratch or are you basing it on one of the rocker project images?

[seabbs]

My hope is/was to create a reproducible/portable environment where epidemiologists could run their favorite script/language code. But some languages seem to always complicate things

This is a very good idea by the way. If your doing this in the open somewhere happy to pinged to offer any support with EpiNow2/epinowcast related issues.

[bdklahn]

I'm sorry to have apparently just dropped off of this. I'm involved in different software efforts at work, and often have to just drop things to move to the next context.

First, I'd like to thank the EpiNow2 contributors. My colleagues have been using this, after using EpiEstim, then EpyEstim. It does appear to provide a nice scientifically complete/thoughtful treatment.
I can get a little salty about R. Part of that is my R (ecosystem) knowledge is probably pretty rusty, by now. But I know there is a lot of good/useful R software for/by a lot of good people. The RStudio folks (one of which is an old colleague) have created a nice interactive experience for people.

Yes, I have been using rocker images (partly because they now use that linux-friendly CRAN mirror). It looks like the biggest time issue for me was compilation of arm deps. So I just removed that from my buildx options. I guess I, maybe like the Julia founders, was a little greedy. I wanted that to run natively for folks using Docker Desktop on their Mac laptops (rather than the VM fallback), as well as on HPC and cloud. But I know a lot of software out there (not only for R) is still not yet "Tier 1" for arm.

I do have some effort (in my "spare time") into some early prototyping of something supporting a multi-script container.
https://github.com/bdklahn/JuMambaR/blob/main/Dockerfile
(I put R on top of the stack, with it always being a bit of a "problem child", with it's implicit host lib dependency entanglements)
https://github.com/bdklahn/CollabTainer
(looking at that last one, again . . . there might be some advancements I might want to "backport", from an instance we've been testing)
I have an Epi-focused instantiation of that CollabTainer in our private repos, we've just started testing for our deliverables.

I love containers, and some of the updates the recent Apptainer has added to the Singularity code, are really useful. Of course, the Docker Github CI integrations are nice, too.
But containers are not so user-friendly for folks who might want to contribute/test more completely their epi services stack, locally.
They, at least, have to have some form of tooling (E.g. Docker (Desktop) and/or Apptainer) installed.

Having surveyed a lot of nice software the Julia design seems to really enable, it occurred to me that it might be possible to have the "container" just be a Julia package. R, again, might throw in a wrench to including it. It seems R makes it a little involved to create a general jll. I guess that effort would work easiest wi/with many of it's deps also jlls.

Maybe "EpiApps"?

True Julia experts might chime in. But I'm thinking/wondering . . .

• pull in Python (et.al.) scripts/libs using Scratch.jl. -of course maybe move to Artifacts (jll?), as they harden/mature.
• Use MicroMamba.jl and pin their Python (only up to minor semver) vers and top-level deps in a minimal environment.yml (analogous to pip-tools pip-compile requirements.in or a Julia Project.toml). Many apps might share a "base" env. Others might need their own Python/dep versions in a separate env. -I haven't tested if stacked conda envs always "actually"/"reeeally" work.
• Maybe Dagger.jl could connect some of the apps into workflows(???).

Anyway, aside from this "grand scheme". I look forward to something like an "EpiNow.jl". :-)
Oh . . . also . . . a quick search turned up this.
https://github.com/timueh/COVID-19

-seems maybe a little closer to "POC" level (and unmaintained?). Might you consider that closer to a "naive" version of the algorithms?