usgs / nshmp-haz Goto Github PK
View Code? Open in Web Editor NEWNational Seismic Hazard Mapping Project (NSHMP) Code
License: Other
National Seismic Hazard Mapping Project (NSHMP) Code
License: Other
Although an initial assumption was that multiple system sources would be run in parallel, this is unlikely when it comes to running USGS webapps and it's probably better to distribute the numerous inputs to curves task once the inputs have been built on a single thread (this usually only takes 15-20% of total compute time for a site).
Presently, a system source set parser will automatically look for both fault and grid sources and fail if either is absent. Even though coupled (in terms of rates as in UCERF 3), fault systems and grids run in completely independent ways.
Currently GridSources only work with mag-length-relationships due to uncertainty about what reasonable down dip widths and aspect ratios should be; perhaps this should be regionalized or keyed to tectonic setting.
Develop ability to interpolate between periods; useful when building response spectra when sources use Gmm's with different period support. See #16
When epistemic and aleatory uncertainty dip below the uncertainty 'cutoff' magnitude, magnitude uncertainty is suppressed. Specifically, if (1) MFD is GR and mMax-epi < 6.5 or if (2) MFD is SINGLE and m-epi-2s < 6.5. However, if MFD is SINGLE but doesn't have epistemic uncertainty (e.g. 2008 bFault.ch.in Santa Monica Alt 1 & 2), aleatory uncertainty still applies if enabled.
Hazard program output consists only of total curves. It would be helpful to output more (by GMM or source type). Not sure if this should be configurable or just the default; if the latter, may result in a lot of unwanted files.
...instead of annual rate. Do this as a post processing/output step; preserve native storage in annual rate.
Most NSHM implementations of subduction zone models impose odd constraints on hypocentral depth. (e.g. interface 'depth' being fixed at 20km; max slab depth 100km, or 125km). What's wrong with using hypocentral depth? In some Cascadia interface cases, 20km is actually below the bottom trace of a fault.
Current GMM implementations (adhering to past practice in the fortran codes) do not adhere to author defined focal mechanism cutoffs. This was due to the fact that the fortran input files could only handle integer based identifiers for fault-type (1,2, or 3) instead of using rake directly.
Campbell and Bozorgnia (2014) use hypocentral depth. We've implemented it as (zTop - zBot) / 2. Perhaps something different along the lines of CB14's suggested models should be used. Zhao '06 also considers hypo depth but we fix it at 20km for interface sources (which sometimes isn't even in the fault plane) and use zTop for slab sources. Perhaps zHyp should be included in source XML files.
Add sum (others?) to DataTable and DataVolume.
Add DataArray with chain able builder to complement DT and DV.
Consider a new overall documentation structure.
For the CEUS we need a list of cities that will be used for comparison with hazard computed using NRC codes and for unit tests of USGS code. This will be added as an enum and used to generate config and/or site files.
... or clearly document exceptions.
The project Wiki claims the code loosely follows the Google Java Style Guide. The project should more strictly adhere to the standards in that document or should document the exceptions to the style guide. Of note, the following rules are violated (ordered by appearance in style guide itself):
A continuous integration solution should be leveraged by this repository. Continuous integration is a means of automatically checking each commit/pull request against a suite of unit-, integration-, and/or other- tests; it can optionally be used for shipping/deployment as well.
Integration hooks should be configured on the repository such that continuous integration is run prior to any pull request being merged. The latest continuous integration results should be immediately visible on the repository README file.
Results of unit tests and/or coverage reports can also be automatically included on the gh-pages branch (or other location) to clearly show the current state of the project.
Should run unit, benchmark and coverage reports.
There are a lot of poorly named and unused methods that were added to support CompoundSurfaces in OpenSHA but that are not needed here.
Also consider guava's ArrayTable as a replacement for Container2D.
We are not supplying a public api for creating the components of a hazard calculation like OpenSHA so we want to privatize and cloned classes where possible.
Take advantage of GitHub's ability to render GeoJSON files
sites.geojson
or sites.csv
filetypes.Moving forward, we want to favor dynamic interpolation between periods instead of creating custom sets of coefficients that look 'reasonable'. Most CEUS GMMs have a 0.4s that was added for some NRC project. SH has also been adding 1.5 and 2.5 sec to CEUS, and possibly PNW. Others?
The documentation is out of date. Many references to refactored classes still exist and it leads one to question what else may not be accurate. Consider moving the documentation from a Wiki to the gh-pages branch. This has many benefits including:
Currently, GMM-specific curves are scaled by their weight when stored; perhaps this should be done only once aggregating a total curve, thus preserving the originals.
Current results are sent to files in a results
folder. Subsequent results override previous runs. Subsequent runs also do not remove results from previous runs. This can lead to polluted results directories.
Perhaps results should go into a results/TIMESTAMP
directory to stay unique.
In its current state,it is difficult to take advantage of new/different models which use different parameters/inputs. For example, the org.opensha2.calc.Site class has the following site data types hard coded: Vs30, Z1.0, and Z2.5. That is the set of values used by current ground motion models but that may or may not be the set of parameters used by future models.
For example, add configs to etc/ that reflect WUS and CEUS map regions. Site files, either as json configs or cvs files should be added for NEHRP and NRC test cities.
Consider changing the argument order for HazardCalc
command line usage so custom sites are specified before custom configuration. It seems more likely to have a custom set of sites of interest rather than custom configuration for the default site.
They should be updated or removed.
Test full application end-to-end for known input and output. Consider 34 fixed cities or similar list. Define clear criteria for passing (results should be within some delta).
Create benchmark statistics for this to measure performance.
2014 NSHM Wasatch unclusetered model was not configured with addf'l epistemic uncertainty on ground motion. By default the new codes do implement it, but a custom source subdirectory will need to be configured for 1:1 match. Considering this was an oversight, we should probably leave it as is and add comment to release notes.
A Linter should be implemented for this project. Linting validates the source code against the style guide to ensure source code remains compliant. A CONTRIBUTING.md file should be added to the repository root directory in order to clarify the style guide expectations for contributions (among other things).
A task should be added to the build.xml file to execute the linter against existing source code.
Currently functioning, but messy.
Possibly to license file, or elsewhere.
Although uncertainty values are supplied in the gmm.xml
files, it is not yet applied. This will likely require refactoring ExceedanceModel (ProbabilityModel in future) to in some way handle/take a median ground motion uncertainty model.
A code coverage solution provides reporting on how much (lines, logic branches, etc…) of the code is being tested by the unit test suite. This provides some confidence as to the overall code quality. For example, it means little if the unit tests all pass but only test 10% of the code base. A variety of code coverage solutions exist; one should be chosen appropriate to the project.
Although hazard is generally presented in terms of probability of exceedance, for deaggregation we want the option of computing probability of occurrence. The enum should therefore be renamed with instances providing both probability()
and exceedance()
methods.
Some single MFD sources for which the 'characteristic' magnitude is a rupture smaller than the defined area of the parent fault require a floating boolean property to be set. It would be better to do away with this attribute and simply use magnitude scaling relations in place to set whether a rupture should float or not. This should be problematic in situations like the CEUS-SSCn RLME multi-mMax models; its possible that some smaller mags would float, possible tapering hazard towards the ends of the fault, whereas larger mags might not.
Source code lifted directly from the OpenSHA project should continue to live in the org.opensha… (or similar) package; however source code developed specifically for the nshmp-haz project should be moved to a gov.usgs.nshmp... (or similar) package.
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.