shakyground2 merge requestshttps://git.gfz-potsdam.de/shakemap/shakyground2/-/merge_requests2021-05-25T16:09:31+02:00https://git.gfz-potsdam.de/shakemap/shakyground2/-/merge_requests/16add pre-commit configuration, docs and gitlab-ci integration2021-05-25T16:09:31+02:00Marius Kriegerowskimarius@gfz-potsdam.deadd pre-commit configuration, docs and gitlab-ci integrationThis MR adds pre-commit for improved workflow.
\approve @gweather @rizac
\fyi @allThis MR adds pre-commit for improved workflow.
\approve @gweather @rizac
\fyi @allhttps://git.gfz-potsdam.de/shakemap/shakyground2/-/merge_requests/13Implements classes to handle Regionalization and assignment of ground motion ...2021-04-28T11:54:16+02:00Graeme WeatherillImplements classes to handle Regionalization and assignment of ground motion modelsFor shakemap applications a set of ground motion models (and their corresponding weights) needs to be defined for each earthquake. Though these can be defined manually, it also desirable to define a `Regionalization`, i.e. a set of geogr...For shakemap applications a set of ground motion models (and their corresponding weights) needs to be defined for each earthquake. Though these can be defined manually, it also desirable to define a `Regionalization`, i.e. a set of geographical regions each with their own associated set of ground motion models. This is explained in https://git.gfz-potsdam.de/shakemap/shakyground2/-/issues/7
This MR implements two classes for handling regionalizations at any scale:
1. A `Regionalization` class, that loads and stores a given regionalisation and can, for a given earthquake, apply the geographical selection procedure to identify the region to which the earthquake is associated and its corresponding ground motion models.
2. A `RegionalizationSet` class, that manages multiple regionalizations, the order of which defines their own hierarchy. For example, a different regionalization may be required for `A`) a country, `B`) a continent (the spatial domain of which may include part or all of the country `A`), and `C`) a global scale regionalization. The order in which the `Regionalization` objects are input into the `RegionalizationSet` defines the hierarchy, e.g. if the three regionalizations are input in the order `A B C` then regionalization A will be applied if the earthquake falls within its domain, then `B` or `C` otherwise. If the order were reversed (`C B A`) then the global regionalization (`C`) would be applied in favour of the local regionalizations (`A` or `B`).
The geographical regions are managed within the `Regionalization` class as a GeoPandas GeoDataFrame, which must include the attributes `id`, `REGION`, `LOWER DEPTH`, `UPPER DEPTH` and geometry. The ground motion model mapping is manages as a dictionary, the structure of which reflects the json definition explained in https://git.gfz-potsdam.de/shakemap/shakyground2/-/issues/7.
A `classmethod` is include in both `Regionalization` and `RegionalizationSet` that allows the user to define the regionalization in the form of a `GeoJSON`, and the corresponding ground motion model mapping as a standard `json`. If a region type is found in the `GeoJSON` for which the ground motion model mapping is not defined in then an error is raised.
A set of files defining the "standard GFZ" ground motion model is also included, though further edits to these may be made in future merge requests.
For the geometry configurations tested so far, a reasonable amount of speed is gained by using `Rtree` for spatial indexing in order to determine the polygon in which the earthquake falls. This dependency is added to the `setup.py` file.https://git.gfz-potsdam.de/shakemap/shakyground2/-/merge_requests/12Implements initial complete shakemap feature2021-03-11T16:42:57+01:00Graeme WeatherillImplements initial complete shakemap featureImplements the initial `Shakemap` class that combines the earthquake, site and ground motion models (here defined in terms of a dictionary containing a list of models and a list of their respective weights). This MR addresses two issues:...Implements the initial `Shakemap` class that combines the earthquake, site and ground motion models (here defined in terms of a dictionary containing a list of models and a list of their respective weights). This MR addresses two issues:
1. The migration of the main shakemap calculations from the original shakyground repository (https://git.gfz-potsdam.de/shakemap/shakyground2/-/issues/10)
2. The implementation of the synthetic rupture generator to handle the construction rupture surface needed for the ground motion calculations given the limited available information on the earthquake source (https://git.gfz-potsdam.de/shakemap/shakyground2/-/issues/9)
Additional methods have been added to the `Earthquake`, `SiteModel` and `RuptureMechanism` classes to handle the synthetic rupture generation and subsequent shakemaps more cleanly.https://git.gfz-potsdam.de/shakemap/shakyground2/-/merge_requests/11linting source code and tests2021-03-04T17:43:30+01:00Marius Kriegerowskimarius@gfz-potsdam.delinting source code and testsApplied `black` to auto-lint the source code.Applied `black` to auto-lint the source code.https://git.gfz-potsdam.de/shakemap/shakyground2/-/merge_requests/2Add basic ci pipeline2021-02-03T17:36:51+01:00Marius Kriegerowskimarius@gfz-potsdam.deAdd basic ci pipelinehttps://git.gfz-potsdam.de/shakemap/shakyground2/-/merge_requests/1setup rudimentary project structure2021-02-02T15:44:11+01:00Marius Kriegerowskimarius@gfz-potsdam.desetup rudimentary project structure@all please have a look at the rudimentary project structure.
The Makefile is a shortcut for linting. Just run
make check
to check your code or
make black
to let black format it. That's also documented in the README.md.
We...@all please have a look at the rudimentary project structure.
The Makefile is a shortcut for linting. Just run
make check
to check your code or
make black
to let black format it. That's also documented in the README.md.
We use a line length or 96 in other projects. But I'm open for anything between 80 and 120. Thoughts?