More Questions - RAMP, PyRossGeo, Contact Tracing and FlameGPU.

[dentarthur]

Q3. Its been nearly 4 weeks since my Q1 and Q2 in:

#307

Could somebody please confirm when or whether there will be a response or a request for clarification?

BTW SYCL 2020 v1 provisional is now out.

Q4 Are the python bindings and jupyter example for OCCA of any relevance?

https://github.com/libocca/occa.py

https://notebooks.gesis.org/binder/jupyter/user/libocca-occa.py-oq3qbhzd/notebooks/notebooks/Tutorial.ipynb

https://libocca.org/#/history

Q5 publications list here includes some missing from public site:
https://flamegpu.github.io/publications/

1. Could this be updated to include last few years and made easily accessible? (Does not include some very useful papers from 2017-18 and hopefully others even later).

2. Some links from main publicly available list are broken and should be fixed:
   http://www.flamegpu.com/publications

Q6. If I am pointed to a markdown version of publications list to update I could add a few items I have come across though I imagine it would be better to generate direct from a bib file that somebody should have.

Q7. Could somebody please checkout the potential relevance of FLAME GPU to PyRossGeo?

https://github.com/lukastk/PyRossGeo#documentation

See also the (java!) Scottish Covid Response contact tracing model mentioned by RAMP and consider relevance of ABMs on GPUs to Individual based contact tracing of clusters and outbreaks integrated with microsiulation based PyRossGeo:

https://github.com/ScottishCovidResponse/Contact-Tracing-Model/blob/develop/docs/Build%20Documentation.docx

The PyRoss and PyRossGeo docs are a lot easier to understand than the original Imperial College model and it is well known how compartmentalized SBML style chemical reaction models can be translated to more granular ABMs with actual behavioural variation for better insight into emergent phenomana arising from the heteogeneities in compartments that are NOT well mixed than can be obtained from tau leaping with the Gillespie algorithm.

1. I gather there has been no RAMP response to expression of interest from FLAME GPU?

https://epcced.github.io/ramp/

2. Item 10 h) of their previous updates (linked from above) makes it clear there are lots of offers from software developers to help projects but not enough actual epidemiological modelers to cope. The inevitable focus on immediate firefighting means nobody is looking at likely needs for future software platform development that could only be useful later (but which will be needed before a vaccine is available).

3. After reviewing a fair bit of the necessary reading including the recommended seminars at Isaac Newton Institute I am convinced the point I made in my first contact here in March has been fully confirmed:

#222

• ie they will need more granular models for which FLAME GPU is likely to be highly relevant, especially in connection with contact tracing and localised restrictions (eg Leicester). They have explicitly confirmed my claim that the Imperial College model would need to be replicated and identified PyRoss as the project most relevant to that. The existing modeling teams will be preoccupied with their existing models and obtaining actual data rather than considering how to integrate the various models. Some aspects like hospital logistics, aerosol dynamics and disease progression are orthogonal to each other and can just supply input parameters to transmission and contact tracing or take outputs from them. But transmission and contact tracing models need to be closely integrated for real-time quarantine and social distancing decisions and that clearly points towards ABMs on GPUs. Its a lot more difficult than half a million cars on a road network but looks to me just as clearly well suited to FLAME GPU.

4. PyRoss Geo is where the difficulty of achieving the necessary granularity without GPUs and the potential relevance of FLAME GPU should become obvious.

[mondus]

Hi @dentarthur I have responded to and closed #317. In response to your other questions;

Q3: We are every busy with development and have a current development road map which we are following. We are not anticipating changing the underlying languages or approach and will not consider doing so until we reach a stable release. It would only delay development.

Q4: I am personally working on pyflamegpu. It is under development in the swig branch but not ready for release at this stage. It is preferred to wrap our library rather than develop from scratch in python to target GPUs using the approaches you suggest.

Q5: The website is out of date. We have a prototype new site which we will deploy with the first release of FLAME GPU 2. New papers will be published on the architecture when we are ready.

Q6: Our new site will be github driven so you will be able to issue a pull request to add publications. For now you could add an issue to https://github.com/FLAMEGPU/flamegpu.github.io/issues which is an old port of our current site which will be used as a starting point for the new one.

Q7: I am aware of RAMP and the Scottish covid response. We need to focus on core development of FLAME GPU 2 for this tool to be useful in epidemiology. Once we reach a release state we plan on releasing epidemiology examples as a starting point to engage in useful discussion with epidemiology modellers.

[dentarthur]

Thanks for clear response.