Skip to content
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

Closed
ghost opened this issue Sep 10, 2021 · 3 comments · Fixed by #90
Closed

Handle some inconsistencies in eq demand types and units naming on hazard service #15

ghost opened this issue Sep 10, 2021 · 3 comments · Fixed by #90
Assignees
Labels
enhancement Improvement to an existing feature
Milestone

Comments

@ghost
Copy link

ghost commented Sep 10, 2021

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.

@ghost ghost added the bug Something isn't working label Sep 10, 2021
@ghost ghost added this to the 1.6.0 milestone Sep 10, 2021
@ghost ghost modified the milestones: 1.6.0, 1.7.0 Oct 13, 2021
@ghost ghost added enhancement Improvement to an existing feature and removed bug Something isn't working labels Nov 2, 2021
@diegoac2 diegoac2 self-assigned this Nov 3, 2021
@ghost ghost assigned longshuicy and unassigned diegoac2 Nov 8, 2021
@ghost ghost modified the milestones: 1.7.0, 1.8.0 Dec 1, 2021
@ghost ghost modified the milestones: 1.8.0, 1.9.0 Jan 24, 2022
@ghost ghost modified the milestones: 1.9.0, 1.10.0 Feb 9, 2022
@navarroc navarroc modified the milestones: 1.10.0, 1.11.0 Jun 27, 2022
@navarroc navarroc modified the milestones: 1.11.0, 1.12.0 Aug 17, 2022
@longshuicy
Copy link
Member

notes:

When creating new DRF3 curves, now we check if the demand type is valid. For EQ we do these:

// check first if demand type exist
            // sa and sd are special cases
            if (demandType.contains("sa") || demandType.contains("sd") || demandType.contains("sv")) {
                String[] demandTypePhrase = demandType.split("\\s+");

                // check if first word is positive numeric value
                Pattern pattern = Pattern.compile("\\d+(\\.\\d+)?");
                if (demandTypePhrase.length > 0 && demandTypePhrase.length <= 3
                    && pattern.matcher(demandTypePhrase[0]).matches()
                    && (demandTypePhrase[demandTypePhrase.length - 1].equals("sa")
                    || demandTypePhrase[demandTypePhrase.length - 1].equals("sd"))) {

                    // replace demand type 0.1 sec Sa with just sa
                    demandTypeEvaluated = demandTypePhrase[demandTypePhrase.length - 1];
                }
            }

@longshuicy
Copy link
Member

When get the values of hazards, it try to parse the demand type:

public static String[] getHazardDemandComponents(String fullDemandType) {
        String[] demandParts = {"0.0", fullDemandType};
        if (fullDemandType.equalsIgnoreCase(PGA) || fullDemandType.equalsIgnoreCase(PGV) || fullDemandType.equalsIgnoreCase(PGD)) {
            return demandParts;
        } else {
            String[] demandSplit = fullDemandType.split(" ");
            if (demandSplit.length == 2) {
                demandParts[0] = demandSplit[0].trim();
                demandParts[1] = demandSplit[1].trim();
            } else if (demandSplit.length == 3) {
                // The assumption here is something like 0.3 Sec SA, 0.3 Sec SD, etc
                demandParts[0] = demandSplit[0].trim();
                demandParts[1] = demandSplit[2].trim();
            } else {
                // Unexpected format
                demandParts = null;
            }
        }
        return demandParts;
    }

@longshuicy
Copy link
Member

demandUnit validation can be improved:

public static boolean verifyHazardDemandUnits(String demandType, String demandUnits) {
        if (demandType.equalsIgnoreCase(HazardUtil.PGA) || demandType.equalsIgnoreCase(HazardUtil.SA)) {
            return demandUnits.equalsIgnoreCase(HazardUtil.units_percg) || demandUnits.equalsIgnoreCase(HazardUtil.units_g);
        } else if (demandType.equalsIgnoreCase(HazardUtil.PGV) || demandType.equalsIgnoreCase(HazardUtil.SV)) {
            return demandUnits.equalsIgnoreCase(HazardUtil.units_cms) || demandUnits.equalsIgnoreCase(HazardUtil.units_ins);
        } else if (demandType.equalsIgnoreCase(HazardUtil.PGD) || demandType.equalsIgnoreCase(HazardUtil.SD)) {
            return demandUnits.equalsIgnoreCase(HazardUtil.units_cm) || demandUnits.equalsIgnoreCase(HazardUtil.units_m_abbr) ||
                demandUnits.equalsIgnoreCase(HazardUtil.units_in) || demandUnits.equalsIgnoreCase(HazardUtil.units_ft_abbr);
        }

        return false;
    }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvement to an existing feature
Projects
None yet
3 participants