They should be updated or removed.

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.

Add sum (others?) to DataTable and DataVolume.
Add DataArray with chain able builder to complement DT and DV.

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.

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.

Consider a new overall documentation structure.

• Home
• Getting Started
  • Obtaining Source Code
    • Following the first release of the software, add links to download a zip/tarball of the released software package.
  • Building
    • Building should not make assumptions but rather explain each step required to successfully build the software.
    • Include variations, as appropriate, for each supported OS.
    • Document each available built target in build.xml.
• Source Models
  • Obtaining USGS models for use
  • Source types
  • GMM
  • Config
• Applications
  • HazardCalc
    • Usage
    • Output
    • Example commands to run code
  • Deaggregation
    • Usage
    • Output
    • Example commands to run code
  • Response Spectra
    • Usage
    • Output
    • Example commands to run code
• Dependencies
• Functional PSHA
• API Docs

Figure 65 (p. 103) is incorrect. New Adobe Illustrator version on PCMAC/NSHMP/FINAL_IP-052282Documentation/FinalFIGS. Low res image attached

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.

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 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.

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.

OFR

• p. 51 Fig. 34 'earthquakies'?; wrong smoothing weights; wrong truncated GR mMax
• p. 46 Fig. 31 includes Meers GR branch although none exists in code (2008 or 2014); see CEUScm2014.in)

Other docs and code

• Cheraw SSC paritial (GR) rupture has dip of 50° whereas all other representations dip 60°; see CEUScm-srgr_2014.in
• Charlevoix uses meanrjb.srl not meanrjb.Aeast as other 2014 CEUS grid sources do
• ERM-S1_RLME_2014.770.in is missing a GMM count of 9 on line 20; not sure how this is impacting results for 5-Hz and 1-Hz

...instead of annual rate. Do this as a post processing/output step; preserve native storage in annual rate.

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.

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.

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:

• gh-pages can be managed at the same time as the source code itself.
• gh-pages can go through the same pull request process for review prior to integration.
• gh-pages uses simple Markdown and can benefit from Jekyll templating to produce a more USGS visually-compliant product.
• gh-pages can be updated as part of an integration hook to keep it up-to-date with the code itself.

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.

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.

• Speed
• Memory footprint
• etc...

... 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):

• 2.3.1 Whitespace characters
• 3.3.3 Ordering and spacing
• 3.4.2 Class member ordering
• 4.1.1. Braces are used where optional
• 4.2 Block indentation: +2 spaces
• 4.4 Column limit: 80 or 100
  • Note: While columns never exceed 100, it appears 80 was the intended target and that is exceeded in multiple locations.
• 4.5.2 Indent continuation lines at least +4 spaces
• 5.2 Rules common to all identifiers
  • Use of unicode (non-ascii) member names
• 5.2.2 Class names
  • Some class names are not nouns, eg. “ClusterToCurves”
• 5.3 Camel case: defined
  • Some references like: “anXMLVar” should be “anXmlVar”
• 6.3 Static members: qualified using class
• 7.2 The summary fragment

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.

Take advantage of GitHub's ability to render GeoJSON files

• Change site locations and polygons to be defined using GeoJSON.
• Refactor HazardCalc to process sites.geojson or sites.csv filetypes.
• Use the bounding box property to define a rectangular region when exporting curves as binary; this only applies to map polygons.
• Use intersection of bounding box and map polygon to define where hazard curves are computed (e.g. intersect large US polygon with CEUS bounding box)
• Remove site specification from config entirely; this dovetails with #67 and #93

Possibly to license file, or elsewhere.

Should run unit, benchmark and coverage reports.

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, 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.

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 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).

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.

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.

Develop ability to interpolate between periods; useful when building response spectra when sources use Gmm's with different period support. See #16

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.

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.

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.

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.

Currently functioning, but messy.

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?

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.

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.