ManyFEWS (the Many Flood Early Warning System) can be deployed by a community where there is currently no such system in place. The system uses weather forecast information from the Global Ensemble Forecast System produced by NOAA, coupled with a catchment hydrological model and a flood inundation model. The user interface is in development and will allow for the issuing of the alerts via a messaging service. A key innovation in the system is the use of statistical emulation of the 2D hydraulic flood model to enable rapid warnings to be generated within an uncertainty framework.
The initial version of the system (v1.0) will become available from Autumn 2022. Funding for the future development of the system is currently being secured.
| Project Member | Contact address | Role | Unit |
|---|---|---|---|
| Dr. Samantha Finnigan | samantha.finnigan@dur.ac.uk | Research Software Engineer (RSE) | Advanced Research Computing |
| Dr. Jiada Tu | jiada.tu@dur.ac.uk | Research Software Engineer (RSE) | Advanced Research Computing |
| Dr. Sim Reaney | sim.reaney@dur.ac.uk | Java Flood One Co-Investigator | Department of Geography |
The initial implementation of the ManyFEWS tool was architected and developed in Python/Django by Alison Clarke.
The development of the new flood early warning system was funded under the Java Flood One project (UKRI grant ref. NE/S00310X/1 ) funded by UKRI’s NERC and Indonesia’s Ristekdikti.
The project is run by Durham University, the UK Centre for Ecology and Hydrology, Bandung Insitute of Technology and local NGO in Indonesia Jaga Balai.
See DEVELOPMENT.md for details of how to set up a development instance, and SCHEDULING.md for how to set up the scheduled tasks to run the weather modelling and create alerts.
A multi-stage Dockerfile is included in this repository. Pre-built Docker images are available for:
- The WSGI server
- The Web frontend
- The Celery backend
The docker-compose.yml file in the root of this repository includes the project dependencies and can be run to set up an instant working development system. For manual setup instructions, see DEVELOPMENT.md.
A couple of different production deployment possibilities are documented in PRODUCTION.md. We include a production docker-compose file for running the system behind a Træfik load balancer.
Please feel free to comment on and create issues. When creating an issue, please use the correct issue template, e.g. for Bug Reports or Feature Requests.
Protected and should only be pushed to via pull requests. Should be considered stable and a representation of production code.
Should be considered fragile, code should compile and run but features may be prone to errors.
Feature branches should be created from the main and devel branches to track commits per feature being worked on. External developers should fork the repository and add their commits to a Pull Request. This follows the "github-flow" model of branching.
Pushing to the release branch triggers the CI/CD workflow to build the Docker images and upload them to the DurhamARC DockerHub repositories, then release to Azure and the backend servers. The release branch is protected and can only be pushed to by authorized members (currently @sjmf and @Abel-Durham).
The release branch is managed by rebasing on top of the main branch and creating a tag. For example:
$ git checkout release
$ git rebase main
$ git tag -a v1.x -m "Release v1.x"
$ git push origin release v1.x
$ git checkout mainWe are using the following frameworks and tools to develop this software:
A CI/CD pipeline is used to test and release this software, using GitHub Actions and Azure Pipelines.
This work is licensed under the GNU General Public License v3.0, which allows Commercial use, Modification, and Distribution, but does not admit any liability or warranty for use of this code.