Git Product home page Git Product logo

opendrr / earthquake-scenarios Goto Github PK

View Code? Open in Web Editor NEW
3.0 5.0 8.0 76.55 MB

Public repository for earthquake scenarios from the National catalogue / Dépôt public de scénarios de tremblements de terre du catalogue national

Home Page: https://opendrr.github.io/earthquake-scenarios/

Python 88.05% Shell 11.95%
earthquakes earthquake-data natural-hazards natural-resources-canada government-of-canada risk-modelling risk-assessment

earthquake-scenarios's Introduction

Canada's National Earthquake Scenario Catalogue

Last update: 21 Oct 2022

Overview of this Repository

Visit www.RiskProfiler.ca to view our user-friendly interface. Here, you can explore the information without downloading data.

This repository is used for the development of the National Earthquake Scenario Catalogue, which presents the probable shaking, damage, loss and consequences from hypothetical earthquakes that could impact Canadians. It considers only damage to buildings, and their inhabitants, from earthquake shaking, and therefore does not include damage to critical infrastructure or vehicles. Losses from secondary hazards, such as aftershocks, liquefaction, landslides, or fire following are also not currently included. The information is provided at the approximate scale of Census dissemination areas, and is intended to support planning and emergency management activities in earthquake prone regions. This project is run by the Geological Survey of Canada's Public Safety Geoscience Program. For inquiries related to the National Earthquake Scenario Catalogue, please contact Tiegan E. Hobbs at [email protected].

For those looking for completed scenarios, please use the 'FINISHED' directory. It contains markdown (.md) files for every published scenario, with each including a high level summary of the scenario impacts, a map of the scenario location, and links to all the output/result csv files. These markdown files can be previewed in your web browser, for easy inspection of scenarios. As more scenarios are published they will be added. A web application is currently being developed to facilitate interaction with these data for non-technical users.

Technical Use

It is possible to download individual files from the web, by clicking on either 'Raw' or 'Download' from the top right corner of a file preview page. For those wishing to clone this repository, please ensure you have Git LFS enabled on your machine prior to cloning. Earthquake risk assessments herein are completed using the OpenQuake Engine which can be cloned here. Any input files which are housed outside of this repository will be made public as soon as supporting documentation is available, including the hazard source model, site response, exposure, vulnerability and fragility functions.

Documentation

A Geological Survey of Canada Open File Report contains basic information about how these models are produced and provides several examples/tutorials. These are aimed at a user who wishes to inspect details of scenarios and has some minimal experience with GIS, Tableau, or Python. For example, emergency managers may find this tutorial is enough to help them identify the impacts of a scenario in their region of interest. This document is available through GEOSCAN.

Additional supporting documentation is in development and will be described here as it is published.

A Note on Acceptable Use

These scenarios are HYPOTHETICAL, but represent credible events which may occur. This suite of scenarios is based primarily on historical earthquakes, known faults, and/or background seismicity levels consistent with Canada's National Seismic Hazard Model. It is by no means an exhaustive list of all potential scenarios that are possible.

Earthquake risk information on RiskProfiler is based on national-scale models of seismic hazard, building exposure, and building vulnerability, and represents typical conditions in any given area, but may not precisely represent local conditions. Results should not be used for building- or property-specific applications and should be interpreted in the appropriate context of a local community. All information represents the expected risk from hypothetical earthquakes. The modelling approach is subject to significant sources of uncertainty inherent in any seismic risk model. Therefore, information should be regarded as estimates, and interpreted in the context of limitations of modelling. Estimates are provided for the effect of shaking damage to buildings and inhabitants; damage from secondary hazards (aftershocks, tsunami, landslide, fire following, etc.), damage to linear infrastructure, and subsequent disruption costs are not included. RiskProfiler provides a visual representation of values, which are rounded as appropriate. See the discussion of uncertainties and intended use here. As stated in the Open Government Licence – Canada, the information is provided with No Warranty.

Attribution

If using any of these scenarios, please include reference to any works which are cited in the scenario descriptions as well as reference to the scenario catalogue itself. The following citation should be used:

Hobbs, T.E., Journeay, J.M., Rotheram, D., 2021. An Earthquake Scenario Catalogue for Canada: A Guide to Using Scenario Hazard and Risk Results; Geological Survey of Canada, Open File 8806, 22 p. https://doi.org/10.4095/328364

Catalogue national de scénarios de tremblement de terre

Date de modification: 21 Octobre 2022

Aperçu du dépôt

Visitez www.RiskProfiler.ca pour voir notre interface conviviale. Vous pourrez y explorer les informations sans avoir à télécharger de données.

Le dépôt est utilisé pour l’élaboration du catalogue national de scénarios de tremblement de terre, qui présente les secousses, les dommages, les pertes et les conséquences probables de tremblements de terre hypothétiques qui pourraient frapper la population canadienne. Le catalogue ne comporte que les dommages causés aux immeubles et à leurs habitants et ne comprend donc pas les dommages causés aux infrastructures essentielles ou aux véhicules. À l’heure actuelle, il ne comprend pas non plus les pertes causées par les dangers secondaires, comme les répliques, la liquéfaction, les glissements de terrain ou les feux. Les renseignements sont présentés selon une échelle qui correspond approximativement aux aires de diffusion du recensement et visent à soutenir les activités de planification et de gestion des urgences dans les régions sujettes aux tremblements de terre. Le projet est mené par les responsables du programme Géoscience pour la sécurité publique de la Commission géologique du Canada. Pour toute question sur le catalogue national de scénarios de tremblement de terre, veuillez communiquer avec Tiegan E. Hobbs à [email protected].

Si vous souhaitez consulter des scénarios complets, veuillez utiliser le dépôt « FINISHED » (en anglais seulement). Il contient des fichiers Markdown (.md) pour chaque scénario publié, et chaque scénario comprend un résumé général des répercussions associées au scénario, une carte de l’emplacement utilisé et des liens vers tous les fichiers de résultats .csv. Il est possible de prévisualiser ces fichiers Markdown dans votre navigateur Web pour faciliter l’examen des scénarios. Les scénarios seront ajoutés à mesure qu’ils seront publiés. On élabore actuellement une application Web pour que les utilisateurs qui ne possèdent pas de connaissances techniques puissent aisément consulter les données.

Utilisation technique

Il est possible de télécharger des fichiers individuels sur le Web, il suffit de cliquer sur « Raw » ou « Download » dans le coin supérieur droit d’une page de prévisualisation d’un fichier. Si vous souhaitez produire un clone de ce dépôt, assurez-vous d’avoir l’extension Git Large File Storage (en anglais seulement) sur votre ordinateur avant d’effectuer l’opération. Les évaluations de risques de tremblements de terre sont réalisées à l’aide d’OpenQuake Engine (en anglais seulement) qui peut être copié à partir de GitHub (en anglais seulement). Tout fichier de résultat hébergé à l’extérieur du dépôt sera rendu public aussitôt que les documents à l’appui seront disponibles, y compris le modèle de la source de danger, l’intervention sur place, l’exposition et les fonctions de vulnérabilité et de fragilité.

Documents

Un rapport public de la Commission géologique du Canada contient des renseignements de base sur la façon dont les modèles sont produits et comprend plusieurs exemples ou tutoriels. Ces exemples et tutoriels sont conçus pour les utilisateurs qui souhaitent examiner les détails des scénarios, mais qui possèdent peu d’expérience de l’utilisation de systèmes d’information géographique, de Tableau ou de Python. Par exemple, les gestionnaires des urgences pourraient trouver qu’un tutoriel est suffisant pour leur permettre de repérer les effets d’un scénario dans la région qui les intéressent. Le document est disponible sur GEOSCAN (en anglais seulement).

Des documents à l’appui supplémentaires sont en cours d’élaboration et une description sera ajoutée ici à mesure qu’ils seront publiés.

Remarque sur l’utilisation acceptable

Les scénarios sont HYPOTHÉTIQUES, mais ils représentent des événements envisageables. Cet ensemble de scénarios est fondé principalement sur des tremblements de terre antérieurs ou des niveaux de sismicité de référence qui correspondent au Seismic Hazard Model of Canada (en anglais seulement – modèle d’aléa sismique du Canada). Il ne s’agit en aucun cas d’une liste exhaustive de tous les scénarios possibles.

Les informations relatives au risque sismique sur RiskProfiler sont basées sur des modèles à l'échelle nationale de l'aléa sismique, de l'exposition et de la vulnérabilité des bâtiments, et représentent les conditions typiques d'une zone donnée, mais peuvent ne pas représenter précisément les conditions locales. Les résultats ne doivent pas être utilisés pour des applications spécifiques aux bâtiments ou aux propriétés et doivent être interprétés dans le contexte approprié d'une communauté locale. Toutes les informations représentent le risque attendu de séismes hypothétiques. L'approche de modélisation est soumise à d'importantes sources d'incertitude inhérentes à tout modèle de risque sismique. Par conséquent, les informations doivent être considérées comme des estimations, et interprétées dans le contexte des limites de la modélisation. Les estimations sont fournies pour l'effet des dommages causés par les secousses aux bâtiments et aux habitants ; les dommages causés par les risques secondaires (répliques, tsunami, glissement de terrain, incendie consécutif, etc.), les dommages aux infrastructures linéaires et les coûts des perturbations ultérieures ne sont pas inclus. RiskProfiler fournit une représentation visuelle des valeurs, qui sont arrondies comme il convient. Voir la discussion sur les incertitudes et l'utilisation prévue [ici] (https://riskprofiler.ca/learn-more/uncertainties-and-intended-use/index.html). Comme indiqué dans la Licence de gouvernement ouvert - Canada, les informations sont fournies sans garantie.

Attribution

Si vous utilisez l’un de ces scénarios, veuillez ajouter un renvoi aux travaux qui sont cités dans les descriptions de scénarios ainsi qu’un renvoi au catalogue de scénarios. La référence suivante devrait être utilisée :

Hobbs, T.E., Journeay, J.M., Rotheram, D., 2021. An Earthquake Scenario Catalogue for Canada: A Guide to Using Scenario Hazard and Risk Results; Geological Survey of Canada, Open File 8806, 22 p. https://doi.org/10.4095/328364

earthquake-scenarios's People

Contributors

anthonyfok avatar damonu2 avatar dependabot[bot] avatar jvanulde avatar tieganh avatar wkhchow avatar

Stargazers

avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar

Forkers

jvanulde anthonyfok eclambs jordanharding damonu2 mpconda ai4disaster wkhchow

earthquake-scenarios's Issues

Renaming scenarios in GitHub [Pages]

Hey guys - I know we already fixed the scenario names in RiskProfiler, but we need to also change them in Git. I'm sorry - I should've thought to rename them after they were first added to the repo. Is this doable now? Then for the rest of Jeremy's scenarios we can change the names while we're adding them? I just don't want us using a municipality name for a specific earthquake scenario when the scenario might not even be that close to the municipality. The names were set because we wanted scenarios to affect each of the ten riskiest scenarios. @anthonyfok @DamonU2 what do you think?

upload_assets.yml GitHub Actions workflow run out of space

The data files have grown big enough that, as of v1.2.2, the default GitHub runner no longer has sufficient disk/build space for upload_assets.yml (was generate_assets.yml) to complete, in spite of the use of easimon/maximize-build-space in v1.2.3. For example:

Potential solution is to download from release assets of the previous release in a piecemeal fashion, and use Git LFS only for downloading new or changed files.

Idea to add a "display_name" variable to the initialization files

The issue is partially resolved as in we have done the bulk of the work for the necessary renaming of 16(?) scenarios, but @DamonU2 has a very good point on "add[ing] a "display_name" variable to the initialization files, and consistency on naming, etc., so I am reproducing his comment here as a new issue for us to really think about and improve on in the future.

As @anthonyfok said, this is bigger issue than it seems. Specifically, for GitHub pages, the "code name" is used to generate the "display name", as it was set up to add additional scenarios with limited manual updating. All of the links, tiles, and associated files use the "code name" for ID, so we'd have to change the "display name" down the line.

The easiest way to do this is probably to add a "display_name" variable to the initialization files, and pull that in. However, we then have the issue of someone looking at a scenario named "Georgia Strait 4.9" and downloading a file called "capilano5", and probably assuming the link is broken (side note - should Georgia Strait be Salish Sea?). This is probably a good method if the code name and display name are similar, ex. "Ottawa" to "near Ottawa", and we just want additional detail, but seems problematic otherwise, ex. "BurwashLanding" to "Denali Fault".

The best way going forward may be to add a display name variable, but also to rename the files in the case of big changes, and reprocess them. @tieganh Do we have a list of proper names for the scenarios in Jeremy's repo?

Originally posted by @DamonU2 in #73 (comment)

Add a "ChangeLog" page to document major or breaking changes

Major or breaking changes such as the scenario renaming that was done in #77 should probably be publicly documented on some kind of "What’s New" or "ChangeLog" page, probably on GitHub Pages (web pages), or maybe a link to a ChangeLog.md Markdown file rendered as HTML.

Investigate if scripts/consequences-v3.10.0.py could be optimized

While casually observing a scripts/run_OQStandard.sh run, I noticed that OpenQuake itself would happily use all available CPU cores to do calculations in parallel (which is awesome), but some other processing are single-threaded and could take over 12 hours. For example:

from ps auxwww nearing the end of python3 scripts/consequences-v3.10.0.py -2 run:

user    2151  0.0  0.0   8756  3792 pts/0    S+   07:51   0:00 bash scripts/run_OQStandard.sh SCM6p5_Montreal_conv -h -r -d -o
user    2225  0.0  0.0 3065888 101008 ?      Sl   07:51   0:01 oq-dbserver
user    6603  100  0.0 2836080 263132 pts/0  Rl+  09:53 759:05 python3 scripts/consequences-v3.10.0.py -2

from top:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   6603 user      20   0 2836080 263132  50196 R 100.0   0.0 286:58.05 python3

from free -h:

              total        used        free      shared  buff/cache   available
Mem:          749Gi       1.4Gi       739Gi       1.0Mi       8.6Gi       744Gi
Swap:            0B          0B          0B

So, in this particular case, calculations before python3 scripts/consequences-v3.10.0.py -2 took just over 2 hours, but python3 scripts/consequences-v3.10.0.py -2 alone was approaching 5 hours took 12.65 hours (759 minutes), running single-threaded (not using a lot of RAM) and writing to CSV files at about 200 lines/second (487,211 lines per CSV file in this scenario):

-rw-rw-r-- 1 user group 96764235 May  2 10:40 consequences-rlz-000_-2.csv
-rw-rw-r-- 1 user group 96262336 May  2 11:28 consequences-rlz-001_-2.csv
-rw-rw-r-- 1 user group 96978159 May  2 12:15 consequences-rlz-002_-2.csv
-rw-rw-r-- 1 user group 97646335 May  2 13:03 consequences-rlz-003_-2.csv
-rw-rw-r-- 1 user group 98016335 May  2 13:50 consequences-rlz-004_-2.csv
-rw-rw-r-- 1 user group 83709311 May  2 14:31 consequences-rlz-005_-2.csv

Ditto for the python3 scripts/consequences-v3.10.0.py -1 command which is expected to take another 12 hours.

Would be an interesting exercise to profile this script and see where it is spending most of its time, and find ways to make it speedier.

(Low priority, could have)

P.S. A quick-and-dirty script that I am using to record basic metrics:

#!/bin/bash
LOGFILE=~/logs/log_2022-05-02_cpu-ram-process.log
while true; do
  ( date; uptime; free -h; ps auxwww | grep ^user ; echo) | tee -a "${LOGFILE}"
  sleep 15
done

Explore OQ Engine >> 3.11 and set up CI tests

Current release of OpenDRR/earthquake-scenarios (as of v1.2.3) has been tested/certified to work with only OpenQuake Engine 3.11.5.

As we'll need to upgrade to a newer version of OQ Engine (such as the latest 3.18.0 release) eventually, it would be a good idea to start exploring getting OpenDRR/earthquake-scenarios to work with OQ Engine >> 3.11.

  • Update our code to be compatible with OQ Engine >= 3.11.5
  • Set up CI tests (with a GitHub Actions workflow) for multiple OQ Engine releases (e.g. 3.11.5, 3.12.1, 3.13.0, 3.14.0, 3.15.0, 3.16.7, 3.17.1, 3.18.0) and compare their calculation results
  • Update documentation, especially Python version requirement for different OQ Engine releases

Thanks to @MPConda for the idea and inspiration!

update dsra_attributes_en/fr

add indicators from exposure to help build charts. Need to update attribute dictionary since new indicators being added.

  • "E_BldgOccS1"
  • "E_BldgTypeG"
  • E_BldgDesLev
  • add worksheet for shakemap_hexbin
  • french section may need to be updated/translated

@tieganh @drotheram

Add LICENSE file

We need to add a license file. Suggest MIT but we can choose whatever makes the most sense. Please let me know if there are any questions.

r2 to r1 for finished scenario

@tieganh if we check the https://github.com/OpenDRR/earthquake-scenarios/blob/master/FINISHED/SIM9p0_CascadiaInterfaceBestFault.md it shows b0/r1 files but in the finished folder for cascadia interface we see b0/r2. I think this was from the previous iteration where we did a dirty fix to to run all the scenarios and in my script rename it back to r1.

Now that we are starting this 'final' repo for scenarios, We should be reverting back to how it was originally planed b0/r1 and we will implement the changes on our end. So this way it should run fine with all the current and new scenarios that will you will be putting in the repo. Right now the Cascadia interface best fault scenarios are labeled b0/r2, and the newer leech river ones are b0/r1.

Would you be able to rename the cascadia scenarios back to r1?

Changes to GitHub Pages

From Julie. Changes needed to: https://opendrr.github.io/earthquake-scenarios/en/

  • Need to add new scenarios
  • Need to update descriptions with ones in this document or want to keep as-is and technical? Scenario names should probably align with RP ones?
  • Is there additional documentation?
  • Add to view our user-friendly interface to explore the information without downloading data, visit www.RiskProfiler.ca.

@DamonU2 maybe you could help out with this? I don't understand the github pages structure on this one.

Review README wording

Check that the readme covers the necessary topics (introduce the material, point people where they need to go, answer questions someone would have, liability, etc) with appropriate wording.

Investigate missing tiles in some scenarios, regenerate as needed

Some of the new tiles generated seem to be missing some tiles (only checked dsra_sim9p0_cascadiainterfacebestfault_indicators_s_900913) at various zoom levels.
Need to investigate and regenerate (geoserver?) and check the other scenarios if it is the same issue.

run_OQStandard.sh should do the hazard calculation only once per scenario

The run_OQStandard.sh script needs to be optimized to avoid repeated identical hazard calculation. The ideal behaviour, as envisioned by @tieganh, is to make only one hazard calculation per scenario, and to refer to that same haz calc for the damage baseline, damage retrofit, risk baseline, and risk retrofit calculations.

@tieganh explained in more details in #86 (review):

… The reason to get rid of running the haz calc was because I changed how I used it in my workflow for the most part. The damage and risk calculators need a hazard calculation, so either you give them the name of one or they will do the calculation internally. Since we run both baseline and retrofit scenarios, my goal was to redo this script so that it would do the hazard calc only once and then use the '-hc' flag (need to double check this, just going off memory) in the damage and risk calculators to point them to that hazard calculation for baseline and retrofit. However, I don't think I got to that point. I only made it so it shares one haz calc for the baseline and retrofit of each calculator type (dmg and risk). I also just started skipping the hazard calc since it wasn't needed for some calculations.

I'm really open to your feedback about the best way to proceed, and have approved the changes as is. If you've got some bandwidth to change this script to do the ideal behaviour (1 haz calc per scenario and call to it for the damage baseline, damage retrofit, risk baseline, and risk retrofit calculations) then that would be the best outcome. …

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.