usgs / ps2ff

Produce approximated rupture distances from point source information

This respository has moved to gitlab and will be archived.

Use the following repository for the latest version of the code, reporting new issues, or sending merge requests: https://code.usgs.gov/ghsc/esi/ps2ff

ps2ff's Issues

Incorrect paths listed in tests

In the test cases, there are a number of paths listed like:

    r2 = pd.read_csv(
        "TestData/Rjb_WC94_mechA_ar1p7_seis0_20_Ratios.csv",
        header=6)
    v2 = pd.read_csv(
        "TestData/Rjb_WC94_mechA_ar1p7_seis0_20_Var.csv",
        header=6)

However, the TestData directory isn't in the program structure.

Error in dimensions_from_magnitude, Mechanism.N, length computation?

One of these does not look like the others. The formulas used for each Mechanism are similar, so looking at this line for Mechanism.N, is there is a typographical error? Should this line:
length = 10**(-1.88 + 0.50 * M) + sig_length * epsmid
be this instead?
length = 10**(-1.88 + 0.50 * M + sig_length * epsmid)

Update continuous integration

Update continuous integration to use Azure rather than Travis.

Refactor code

We should refactor the code so that we don't have so much redundancy. This code is probably well suited to being subclasses of an abstract base class. Other suggestions by Peter:

• Use enum types instead of strings to identify finite sets of options with specific names
  • e.g. mag-scaling relations
  • e.g. you can also use this for NP, with options like [one, n_minus_one, half, all] to obviate the need know how many cores one has (it’s not clear to me how the programs behaves when given bad options such as more cores than that actually available; perhaps it fails gracefully already).
• Consider modularizing the work being done in the middle of the big loops so that the redundant code between programs is limited; you could also consider collapsing to a single program.