Add soil modifiers to OED for use in earthquake loss modelling

[johcarter]

There don't seem to be any modifiers for soil type of input exposures in OED. Soil type affects the intensity of earthquake shaking on a building so it is a useful intensity modifier in earthquake modelling.

A suggestion is to have a pair of fields which describe 1) the soil measure and 2) the value.

For example the measure could be the time-averaged shear-wave velocity to 30 m depth 'vs30 (m/s)' and the value could be 240.

In some cases the vs30 data can be directly incorporated into the modelling process using the exposure's lat-lon to lookup the value, not requiring any knowledge of soil conditions of exposures on the user side.

The purpose of adding the exposure fields would be to provide soil information to the modelling process for the following reasons:

• Model uses soil type as a modifier but there is no available soil data in that region
• Precise location of exposure is not known so soil cannot be looked up in the modelling process
• User wants to override/control the soil type used in the modelling process (bad data/sensitivity testing)
• User has defined/captured another measure of soil type (eg categorical) and wants to use it in the modelling process

There is a question over how much flexibility in the definition of soil type is needed and whether the fields should have codified types (e.g. Type 0 = vs30 (default), Type 1 = something else, etc) or is more freedom needed (as for user-defined Geog schemes, for example).

[MattDonovan82]

Agree, it should be included as a modifier in OED. As discussed, it would be good to know whether a soil type modifier would be used differently when using the liquefaction or landslide peril codes?

I've forwarded this to Corelogic and IF to ask what they think.

[peter-pazak]

Hi, we do use the event footprints pre-calculated for the soil type representative for a grid cell, so user does not need to specify in the input. If the user is allowed to specify vs30, it would require pre-calculating event footprints for a set of vs30 (and then possibly implement interpolation...?) which enlarges the event footprint file and may not be preferred for that reason.

Nevertheless I think it might be useful to have the definitions/possibility for some special cases as you describe above or when the model can calculate on the fly.

[dgregory-clgx]

Hi,

Currently we wouldn't utilise user inputted soil values to change the event hazard footprints, but I think it's useful and codified types would be flexible enough e.g. SoilMeasure = 0 = Vs30 etc.

Another use case is model transparency. I think it would be useful for clients to view what the model vendor has assumed for soil value at each site.

i.e. The SoilMeasure and SoilValue columns could be populated reflecting those values actually used in the modelling (regardless of whether this is the user inputted data or not). This would be visible to the client post import.

This does raise concern about data fidelity and whether we as a model vendor should overwrite user inputted data? If this is an issue, perhaps the model transparency use case could be answered by providing users the soil information actually used in the modelling via an 'analysis run' instead(?)

[johcarter]

Thanks @peter-pazak for your feedback and nice use case, @DavidG-Corelogic.

I think rather than populate soil type into users imported data automatically, in an ideal world it could be provided as an optional data enhancement routine, post import, similar to geo-coding locations to fill missing lat-lons. Then users are in control.

I'm going to suggest we go with codified types starting with 1 = Vs30 which can be extended to more values later. In keeping with OED naming conventions (we use Type as a code linked to a range of valid values listed in the spec), perhaps we go for SoilType (int/optional) and SoilValue (float/optional)

With valid values; SoilType = 0 = no soil information (default) SoilType = 1 = time-averaged shear-wave velocity to 30 m depth 'vs30 (m/s)'

[MattDonovan82]

unless any other feedback, the suggestions made by @johcarter will be implemented in the OED spec as minor update.

[MattDonovan82]

closed as implemented in v2.3.0