Add empirical calculations to intensity measures

[lispandfound]

Adds empirical calculations to intensity measure outputs where empirical models support a given tectonic type and intensity measure.

To support this structure, I have also refactored im calc so that it finally outputs in xarray data tree format instead of dataset format. The upshot of doing this is that we can uncouple the components so that each intensity measure carries only components it actually computes. Especially for models like NSHM2022 that only support pSA it's kind of silly to have every intensity measure carry all-NaN EAS and empirical model components. The Vs30 is carried through from the broadband calculations. All input parameters (distance metrics, average rake, average dip, etc etc) are injected into the datatree output for completeness. The defaults target a tectonic type of active shallow and NSHM2022. This is not tectonic type aware and I will address this shortly when the subduction defaults are finalised.

[gemini-code-assist]

Code Review

This pull request introduces the capability to calculate empirical intensity measures from ground motion models using OpenQuake wrappers. It updates dependencies, default parameters, and schemas, and adds helper methods to average multi-fault parameters (rakes, magnitudes) weighted by fault moment. The im_calc.py script is refactored to calculate source-to-site distances, site parameters, and empirical IMs, outputting the results as an xr.DataTree in NetCDF format. The review feedback highlights critical issues where running the script with empirical=False or with broadband data lacking vs30 coordinates will result in NameError or AttributeError exceptions.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[Copilot]

Pull request overview

Refactors intensity-measure (IM) calculation output to an xarray.DataTree netCDF structure and adds optional empirical (GMM-based) IM calculations driven by per-realisation configuration (tectonic type + model list), carrying through per-station parameters like Vs30 and derived basin depths.

Changes:

• Refactor im-calc output from a single xarray.Dataset to a structured xarray.DataTree, with per-IM datasets and shared station/source metadata.
• Add empirical IM calculation via oq_wrapper for supported IMs/tectonic types and store results under {im}/empirical/{model}.
• Add vs30 to broadband waveform outputs and introduce realisation/schema/default support for empirical configuration.

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
workflow/scripts/im_calc.py	Major refactor to DataTree output; adds empirical GMM evaluation and metadata/unit annotation.
workflow/scripts/bb_sim.py	Adds vs30 coordinate to broadband netCDF output for downstream site parameter usage.
workflow/schemas.py	Adds EMPIRICAL_PARAMETERS schema for validating empirical config in realisations/defaults.
workflow/realisations.py	Adds moment-weighted averaging helpers and EmpiricalParameters realisation configuration.
workflow/default_parameters/root/defaults.yaml	Introduces default empirical configuration (active_shallow + NSHM2022).
uv.lock	Lockfile change related to dependency resolution (cffi/pycparser marker).
pyproject.toml	Adds netCDF4 dependency to enforce safe import order vs OpenQuake/HDF5 stack.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[joelridden]

Based on what we have done before for empirical results for multi fault events we averaged based on the area of the fault not the moment. There was a few discussions regarding what to use and we landed on using area, however could be open to reconsider this adjustment if there has been a new development for this.

https://github.com/ucgmsim/Empirical_Engine/blob/1d39ae9d620767969f71b63748bbac9eea4e18d6/oq_wrapper/estimations.py#L67

[joelridden]

Do we want to estimate for all of the sites? Wondering if we have any "real sites" in this where we have a better measured / estimate value of z1.0 / 2.5 etc to use those instead from the site database.