Uh oh!
There was an error while loading. Please reload this page.
Add generic spherical-shell geoid and self-gravity postprocessing - #591
Add generic spherical-shell geoid and self-gravity postprocessing#591gthyagi wants to merge 3 commits into
Conversation
Add pure Appendix A no-self-gravity and self-gravity response operators with explicit internal-load scaling, density-contrast naming, dimensional constant documentation, and harmonic-degree validation. Provide a rotated-Stokes adapter that delegates normal-traction recovery to the existing Stokes.boundary_normal_traction API, projects only the requested P_l^0 response, and avoids duplicate CBF, constrained, or dynamic-topography implementations. Keep the feature in uw.postprocessing rather than adding a Zhong-specific facade to the generic Stokes solver. Add focused formula, serial end-to-end, and two/four-rank MPI validation.
102ef59 to
cce0753Comparegthyagi
commented
Aug 16, 2026
@lmoresi The benchmark integration is now updated to this narrowed API. Could you please double-check the Appendix A sign/normalisation conventions and whether this rotated-only adapter is the right UW3 abstraction? If an existing implementation is preferable, this focused commit can be discarded without affecting the separate memory fix in #593. Production validation from benchmark commit 99fc132:
The isoviscous run is within 3.82% for self-gravity topography and 7.36% for self-gravity geoid at |
Move the public API under uw.postprocessing.geoid and remove Zhong-specific names from the reusable response data types and coefficient functions. Support two-boundary shells with an optional internal load, require model-specific density and gravity inputs explicitly, and retain a focused rotated-free-slip adapter for recovering axisymmetric topography coefficients. Rename the MPI regression, add no-load and parameter-validation coverage, and update developer documentation to distinguish generic postprocessing from a future semi-analytical propagator solver in uw.analytic.
Allow the generic spherical-shell coefficient functions to evaluate the degree-zero radial potential while keeping the rotated-Stokes adapter at degree one or greater because boundary normal traction recovery removes its mean. Add focused degree-zero formula and adapter validation tests and document the distinction.
Summary
Add generic spherical-harmonic geoid and self-gravity postprocessing for two-boundary spherical shells, with an optional internal load.
The reusable mathematics now lives in
uw.postprocessing.geoid. Zhong et al. (2008) supplies the validation case and exact benchmark parameters, but is not encoded in public class or function names.This revision deliberately reuses UW3's existing rotated-free-slip stress recovery. It does not add another topography implementation, automatic BC dispatch, CBF fallback, constrained-multiplier path,
Stokes.geoid()facade, or semi-analytical Stokes solver.API
Pure coefficient operations, independent of a Stokes discretisation:
Convenience extraction from a completed rotated-free-slip solve:
The adapter calls
stokes.boundary_normal_traction(boundary, mass="auto")and projects surface/CMB responses onto the unnormalised axisymmetricP_l^0harmonic. Other harmonic orders or topography-recovery methods can call the pure coefficient functions directly.Inputs and conventions
Mathematics
One radial Green-function operator and optional load vector are shared by both paths:
Here
hcontains surface/CMB topography coefficients,Ncontains surface/CMB geoid coefficients, andQcontains the self-gravity density factors.This is the geoid/self-gravity algebra applied after topography is known. A Zhong propagator-matrix reference solver would solve the spherical-harmonic radial Stokes equations and belongs separately in
uw.analytic.Validation
1/4and eight-rank1/8runs reproduce prior coefficients to printed precision;1/8run reproduces its prior coefficients.Scope
This PR changes only the postprocessing package, focused tests, and concise developer documentation. The independent 3D boundary-flux memory-scaling correction remains #593. Mesh-files-only generation remains separately scoped in #592.