Validation¶

Oasis validates two kinds of data: the model static data (damage bin dictionary, footprint, vulnerability) and the exposure / analysis inputs (OED). There are no standalone validate* binaries in pytools — validation is built into the tools that read the data.

Model-data validation¶

Inline, during CSV → binary conversion (`csvtobin`)¶

csvtobin validates the model data by default as it converts it; pass -N, --no_validation to skip. The checks (implemented in oasislmf/pytools/converters/csvtobin/utils/) are:

csvtobin damagebin — the first bin_index is 1; bin indices are contiguous; each interpolation (mean) damage lies within its bin range. (Warning if the lower limit of the first bin is not 0.)
csvtobin footprint — the probabilities for each (event_id, areaperil_id) group sum to 1; rows are sorted by event_id then areaperil_id ascending.
csvtobin vulnerability — vulnerability_ids are ascending; the probabilities for each (vulnerability_id, intensity_bin_id) group sum to 1; damage bins are contiguous.

csvtobin footprint -i footprint.csv -o footprint.bin        # validates by default
csvtobin footprint -N -i footprint.csv -o footprint.bin     # skip validation

Standalone model-data check¶

oasislmf.validation.model_data.csv_validity_test(model_data_dir) runs the per-file checks plus cross-checks across the three files:

damage-bin ids used in the vulnerability data are a subset of the damage bin dictionary;
intensity-bin ids in the footprint are a subset of those in the vulnerability data.

Note

This helper currently shells out to the legacy ktools binaries (validatedamagebin / validatefootprint / validatevulnerability / crossvalidation) via subprocess — a remaining ktools dependency pending a pytools cutover. The equivalent per-file checks already run inline in csvtobin (above); the cross-file checks are the piece still provided only by the ktools crossvalidation.

Exposure / OED validation¶

OED exposure files are validated by ods_tools against the OED standard (required and conditionally-required fields, valid code lists, peril codes, …). Use it directly (OedExposure(..., check_oed=True) or OedExposure.check(...)), via the CLI (ods_tools check), or as part of a model run with the --check-oed option (check_oed). See the load & validate OED worked example in the ODS Tools docs.

Analysis input checks¶

--check-oed (check_oed) — validate the input OED files during a run.
--check-missing-inputs (check_missing_inputs) — fail the run if IL/RI output is requested without the required generated input files.

Mapping from the legacy ktools validators¶

ktools validator (deprecated)	now
`validatedamagebin`	inline in `csvtobin damagebin` (and the legacy `csv_validity_test`)
`validatefootprint`	inline in `csvtobin footprint`
`validatevulnerability`	inline in `csvtobin vulnerability`
`crossvalidation`	`csv_validity_test` cross-checks (still ktools; pytools cutover pending)
`validateoasisfiles`	OED validation via `ods_tools` + the `--check-oed` / `--check-missing-inputs` run options

See also: Data conversion components (the converters) · Financial Module.