epispot / epispot Goto Github PK
View Code? Open in Web Editor NEWA tool for modeling infectious diseases.
Home Page: https://epispot.github.io/epispot/en/latest/
License: GNU General Public License v3.0
A tool for modeling infectious diseases.
Home Page: https://epispot.github.io/epispot/en/latest/
License: GNU General Public License v3.0
Is your feature request related to a problem? Please describe.
No.
Describe the solution you'd like
Testing with pytest makes everything quicker, more efficient, and faster.
Describe alternatives you've considered
Running each command manually, which is less efficient, and reports aren't given, unlike pytest, which files error and warning reports in the summary.
Describe the bug
The compartments
parameter in the module epi.plots.web
of the massive-plots
branch is not being used. This has led to 2 "unused import" alerts on LGTM, which can be observed here.
To Reproduce
See LGTM error or examine tests/plotting::test_full_web
.
Expected behavior
The compartments
parameter should be used to hide compartments that should not be plotted. The official definition of the parameter is the list of compartments to be plotted, although for technical reasons, it might be easier to implement the reverse, specifically: the list of compartments to not be plotted. However, this will require changing the functions in the epi.plots.native
module as well.
Screenshots
Screenshots will be posted at a later date.
Python
massive-plots
@ a485fedb26887a1985ee759cc0f44f51d2ad5a11
pre-alpha
(in review on PR #67)Additional context
We are still seeking out more details on this issue.
In many cases, the gradient descent fitter fails to converge, often ending up with extremely large parameters that make no sense for a specific problem. It seems that early stopping (limiting the number of epochs) helps to a certain extent, but the model still fails to capture most of the data.
Describe the bug
Models with a probability of resusceptability do not change the derivative of the Susceptible
compartment which means that the Susceptible
compartment continues to shrink and never grows. This is because self.first_layer
is always true, even if a probability of resusceptability is provided.
To Reproduce
Steps to reproduce the behavior:
Infected
and Recovered
compartments shrink to 0 while the Susceptible
compartment never growsExpected behavior
The Susceptible
compartment should grow to keep the population the same.
Python
super-coverage
latestAdditional context
This problem is currently being solved in the super-coverage branch.
Describe the solution you'd like
Travis CI provides a quick and easy CI/CD setup perfect for testing. Work has already started on the travis-ci-setup
branch.
Additional context
Work has started on the travis-ci-setup
branch already.
This issue is a stub: do not comment.
It is intended to test the new claim.yml
and mod.yml
workflows that aim to provide automatic issue labeling based on issue comments. See commit 5eb8ce1 for more information.
Describe the bug
Several syntax errors/untested code creating problems for pytest (hence all the failing PRs)
To Reproduce
(locally)
master
branch:git checkout master; git pull
python -m pytest
Expected behavior
All builds should be passing and most code should undergo testing to prevent any unforeseen bugs like this from reoccuring.
Python
Additional context
@Quantalabs will head the management of this issue, necessary for continuing any release plans we may have.
Is your feature request related to a problem? Please describe.
This feature request is not related to any problems in this repository. However, this does address a potential deprecation concern with epispot v3. In older v2 versions of epispot, there was the option of customizing graphs by adding 'markers,' which was taken away with the new plots
submodule, introduced in #67 (of v3a1). The reason for this was that markers were not supported by plotly, which would mean that if implemented, this feature would cause an incompatibility between the web
and native
modules. However, plotly's latest update (v5.2.1)—discussed in #104—now supports adding markers to line graphs, eliminating any need for discussion about this problem.
Original discussion (pulled from #104)
- plotly/plotly.py#2719
- We can now add markers to epispot web graphs with Plotly! This is actually something that older versions of epispot have supported for quite a while with matplotlib, but being able to bring this functionality back into both plotly and matplotlib is a huge plus. This will be worked on in a separate issue.
Describe the solution you'd like
The new feature will add a markers
parameter to all supported functions in the native
and web
modules. This parameter will accept various kinds of graphical markers (and ideally maintain compatibility with the standards established in epispot v2). The end result should allow for various graphical annotations wherever possible.
Describe alternatives you've considered
No alternatives have been considered as this was an already-implemented feature.
Additional context
No screenshots as of yet (subject to change in the future).
See the stack overflow question - https://stackoverflow.com/questions/66216530/pytest-not-finding-tests-on-github-actions
Code coverage reporting on master
is not even with nightly
despite the merge for v2.1.0
Files were code coverage is low:
New commits in the massive-plots
branch have caused a new gap in code coverage from previous commits in that branch. The first commit in which this gap was exposed is 02253f05a0747f136b983c313093be57e554c570
. The CodeCov diff and coverage analytics for that commit can be seen here. The commit in question resulted in the code coverage drop partly due to new file additions that were not properly covered for in tests. Additionally, there is a missing # pragma: no cover
annotation that should be made for the new ImportError
warnings introduced with the new files. This should be fixed in a matter of commits.
Is your feature request related to a problem? Please describe.
There is no problem directly related to this feature request, though it would solve issues relating to model reproduciblity, which will prove especially useful in research.
Describe the solution you'd like
Two functions, each of which compile an epispot model object into a file (JSON would probably be best, though any object-oriented file type like YAML/TOML could theoretically work). For certain abstract elements related to the models, (e.g. parameters defined as functions) values could be linked to names or special codes which could be interpreted later with the help of a dictionary. With this dictionary, the reader function would be able to read from the file and recreate the model in its original form, solving the problem of reproducibility and drastically lowering the file size required to do so.
Describe alternatives you've considered
There are, of course, multiple alternatives to solving the reproducibility issue, outlined below:
(1) Copying code: While this works, it's inefficient, occasionally hard to read (as it can be clouded with unnecessary functions and scripts), and involves large file sizes for a problem that can be solved more cleanly by other means.
(2) Saving model outputs: This is perhaps the most obvious solution, but it prevents researchers from actually inspecting the models producing the results and only shows part of the larger picture.
(3) Compiling the model to lower-level code
Additional context
It would be nice to ship this with epispot v3b, but the current situation makes that look unlikely. Regardless, @Quantalabs will head development until this enters nightly (or, if we're lucky, beta) testing.
@Quantalabs: Get docs up-to-date using pdoc. Upload straight to the gh-pages branch.
After adding testing files, code coverage actually went down which may signal that
Describe the bug
This is a test of the new issue tracking workflows mod.yml
and claim.yml
To Reproduce
See this issue
Expected behavior
This issue should be automatically labeled as status:review-needed
. Upon review, a reviewer will mark this issue with either the high-priority
or low-priority
tags and then add the /available
message which will trigger mod.yml
to add status:available
, eliminating the previous tag. Finally, someone may claim the issue with /claim
which will trigger claim.yml
to add the status:claimed
label.
Is your feature request related to a problem? Please describe.
This feature is not related to any problem, but it is inspired by epiforcasts/EpiNow2
Describe the solution you'd like
Epispot should include a handful of parameter estimates from literature to aid with the creation of new models. Additionally, epispot should come with built in random modeling of various parameter distributions which can either be selected manually or automatically in the case that the user has not passed in a function for a specific parameter.
Describe alternatives you've considered
The alternative of not including this would complicate model creation greatly as there are often many, many parameters (exponentially many so as more compartments are added). Therefore, it would be helpful to have some kind of "filler" parameter distribution for unlabeled parameters. Additionally, by adding literature estimates, we can fit COVID-19 trends better using vetted sources rather than tweaking parameters to find an exact match for the data.
Additional context
No testing is expected to happen before this code is pushed to production
Current progress:
This error happened when running in GitHub actions, and only happened in the Python version 3.6. It says that there is an extra seed
parameter on line 43 of basic-sir-model.py
.
Importing and exporting epispot models with .yml
and/or .json
files created from a CLI or function would be extremely easy. I've already started to work on this.
NumPy has officially dropped support for Python 3.7, though Python won't end-of-life it for more than 9 months. This of course brings up the question of whether we, as epispot, should follow suit, considering that NumPy is one of our core dependencies and also that most of our other dependencies are in one way or another dependent on NumPy.
Originally posted by @quantum9Innovation in #137 (comment)
It has been decided that support for 3.7 should be deprecated. the following are the steps for what needs to be done:
Copy all existing time-dependent parameters from seircd-model.py
and add to sir-model.py
and seird-model.py
This issue is part of a series of tasks listed in #81.
Parameters for all compartments other than the Susceptible
compartment should include a rate and probability, organized into an easily-understandable matrix which is then parsed by the Model
class. The reason for this is to eliminate the double-parameter chaos created in epispot v2.
Currently, epispot v2 requires parameters to be specified twice. First to the compartment from which people are leaving and second to the compartment which people are entering. This is because each compartment does not have access to the other compartments' derivatives. However, there is a simple fix for this; every compartment needs to be able to change the derivative of every other compartment. This means that all the derivatives need to be stored at the Model
level and distributed to all the compartments. Each compartment should not make a direct assignment to the derivative but rather add or subtract some value from the derivative. Using this system, every compartment can change the derivative of every other compartment, avoiding the complication of having to enter parameters in twice.
The model first learns what compartments are going to be compiled. For this example, we'll use the following compartment codes: A
, B
, C
. Here's a diagram of how they all connect:
┌───────────────────┐
│ ▼
┌───┐ ┌───┐ ┌───┐
│ A │ ──▶ │ C │ ──▶ │ B │
└───┘ └───┘ └───┘
Now we examine how we can represent this as a parameter matrix. We will refer as the compartments from which an arrow extends as the from compartments. On the other hand, compartments which receive an arrow will be referred to as to compartments.
Each from compartment gets its own subarray. Each element of this subarray corresponds to its respective to compartment. This in turn contains a tuple with the structure ({probability}, {rate})
. For our diagram, the matrix looks like this in Python:
matrix = [
[(1/2, 1/3), (1/5, 1/2)], # A: [B, C]
[(1/2, 1/6)], # C: [B]
]
Notice how the matrix simply does not include elements or subarrays that aren't necessary; B
has no subarray of its own and C
lacks a tuple describing rates and probabilities for A
. We can do this because of how we describe connections between compartments:
This won't change much from epispot v2. Here's how connections are described, using our example with A
, B
, and C
. The following graph:
┌───────────────────┐
│ ▼
┌───┐ ┌───┐ ┌───┐
│ A │ ──▶ │ C │ ──▶ │ B │
└───┘ └───┘ └───┘
becomes the following matrix in Python:
connections = [
['B', 'C'], # A
[], # B
['B'] # C
]
Notice how, even despite having any connections, B
must be included in this matrix. This matrix differs from the rate and probability matrix because here epispot
does not yet know what the connections are. After epispot
receives this matrix, the Model
class can then parse following parameter matrices by assuming that non-connections are skipped.
For now, development of this feature will not interfere with the package itself. Rather, the development will be done in a separate module and tested with dummy compartments (as we did above), before it is transitioned into the actual Model
class.
Copy the time markers used in seircd-model.py
and add to other models.
Larger models can create nearly imperceivable differences in the non-susceptible population because such a small fraction of the population is infected. By automatically deploying log scaling, this visualization would capture the small changes in each class.
Test issue
Is your feature request related to a problem? Please describe.
This feature is unrelated to any current issues in epispot. However, using Dependabot will not only make epispot's code more secure, but it allow epispot to support the latest versions of each of our dependencies. Previously, this was not a problem—however, as new versions of epispot add more and more external dependencies, it is critical that we monitor security vulnerabilities and release notes constantly.
Describe the solution you'd like
Solving this problem will require the following steps:
Describe alternatives you've considered
No alternative solutions have been considered. Dependabot is usually the norm for dependency management, especially since it integrates nicely with GitHub.
Currently, all hyperparameter adjustments take place within the code. To avoid this troublesome interface, the code should be put in package-ready form so that models can be tested from an entirely different script.
The current \fitters\gradient-descent.py
bypasses direct gradient calculation by sampling at multiple points to get an estimation of the gradient. Getting an exact value would speed up convergence, solve numerical issues, and would be twice as efficient as the current algorithm.
Before the launch of v3 (stable), we should implement greater testing capabilities to limit the number of bugs and implementation errors that arise in production. The most obvious way of doing this is to check that model estimates seem reasonable after they go through testing. This will require some minor changes to our testing suite, which we hope @Quantalabs will lead.
Describe the bug
From GitHub Actions Runner (source):
Couldn't parse '/home/runner/work/epispot/epispot/epispot/params.py' as Python source: 'invalid syntax' at line 90
To Reproduce
Running pytest
should give the same error.
Expected behavior
Pytest should exit with 0.
Python
Additional context
This is unrelated to the removal of Python 3.7 and has to do with some type of syntax error in the newly-added params module (see #136 for more)
Describe the bug
The newly-added support for native stacked area charts in massive-plots
(epi.plots.native.stacked()
) lacks good legend visibility. This is due to the fact that for some reason, matplotlib
fails to enforce the default white background for graphical elements on plots, resulting in no contrast between the graph itself and the legend.
To Reproduce
See tests/plotting::test_full_native_stack
Expected behavior
All legends should have a white background, thus standing out from the rest of the plot.
Screenshots
As shown in the plot above, legend colors blend in with the actual graphics.
Python
massive-plots
@ 4068117pre-alpha
Anaconda
Additional context
This issue was mentioned in commit 4068117
Models should automatically run sanity checks to ensure that parameter values are reasonable, implemented correctly, and that all layer combinations are proper. If any of these conditions is not met, epispot
should either give a warning or stop the program with a ValueError
.
Store a fully-integrated model every epoch of the gradient descent process and then access the values later to avoid re-integration. Potential speedup: 2x
Describe the bug
Triage on the Hospitalized
layer is not properly put into effect--the compartment continues to take in more incoming patients even when maximum capacity has been reached.
To Reproduce
Steps to reproduce the behavior:
test_critical.py
on the super-coverage
branchExpected behavior
There should be a sharp cut-off as soon as the Hospitalized
compartment crosses the threshold.
Python
super-coverage
latestRight now both pdoc docs and translations are stored on the root folder in gh-pages. There are two problems with this:
docs.yml
is rm *
which only deletes root filesPossible fix:
Create an en/ folder for English documentation solving (1) and then delete all documentation inside en/ including sub-modules
every time docs.yml
is run solving (2).
With the release of epispot v3, we must ensure that all guides are updated to reflect the changes made in the update. Additionally, we must provide a transition guide to help ease the difficulties of switching (possibly even creating an epispot-6
package to automatically convert code). This issue is currently a long (or short?) way off as it's planned for the official release of v3 as opposed to v3b which is due to come out a week sooner.
Describe the bug
@codecov officially does not recognize a base report from the master
branch even though reports are being uploaded to codecov every commit via Travis CI, and can be seen here. Instead, codecov compares each PR to older commits with higher overall code coverage and fails because of this incorrect comparison.
Expected behavior
Codecov should instead find the latest reports from the master
branch and compare those to the PR reports. Codecov should also provide detailed merge information on their website, which currently it does not do due to incorrect base reporting.
This issue is part of several tasks listed in #79.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.