-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle some inconsistencies in eq demand types and units naming on hazard service #15
Comments
notes: When creating new DRF3 curves, now we check if the demand type is valid. For EQ we do these:
|
When get the values of hazards, it try to parse the demand type:
|
demandUnit validation can be improved:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
DFR3 service has many fragilities that are defined with demandType that contain the word "sec", example "1.0 sec SD". When pyincore maps this fragility and makes values call, it will pass the fragility in this format and our values endpoint behavior is not clear or buggy in this case(see 4th location of 3rd example above). It returns inaccurate demandType in response and seemd to always calculate for "SA" and not respecting the 3rd word in the demandType ("SD" here). We should find a solution to make this convention consistent in hazard and dfr3 services
The earthquake value calculation code is not returning the applied demandUnits but just returning what is passed. Even if we pass "blah" as the unit for PGA to /values endpoint, it calculated the "g" value, but doesn't return it, it still returns "blah" in the result.
The text was updated successfully, but these errors were encountered: