Developer notes#
This section documents the contributor-facing side of GeoPrior-v3. It is intended for maintainers, contributors, and advanced users who need more than end-user instructions: a clear view of how the package is organized, how its current structure emerged, and how new changes can be introduced without weakening the scientific, workflow, or documentation contract.
GeoPrior is not just a collection of model classes. The project brings together a staged command-line workflow, a subsidence-focused model family, documentation-aware packaging, and reproducibility-oriented scripts. Because of that, the developer documentation needs to explain both software architecture and domain-specific design choices.
This section is therefore organized around three practical questions:
how the package is structured,
how legacy ideas from FusionLab map into GeoPrior-v3,
how to contribute code and documentation in a way that stays consistent with the existing project design.
For broader user-facing guidance, see FAQ and the API reference reference. For the scientific context behind the main model family, refer to GeoPriorSubsNet.
Note
The purpose of this section is to preserve architectural clarity. When extending GeoPrior, prefer documented public modules, keep imports stable, and avoid introducing hidden import-time side effects that can weaken the CLI, the documentation build, or autosummary- based API generation.
Review the organization of the source tree, the role of the major subpackages, and the logic behind the current documentation and workflow layout.
Trace how concepts, workflow patterns, and module organization were adapted from the earlier FusionLab environment into GeoPrior-v3.
Read the contributor guidance for proposing changes, keeping the package style coherent, and maintaining documentation quality.
How to read this section#
This part of the documentation works best when read as a contributor ramp rather than as a flat reference.
A natural reading path is:
begin with Package structure,
continue to Migration from FusionLab,
finish with Contributing.
That sequence gives you the current project layout first, then the historical and architectural context behind it, and finally the working rules for making changes that fit the existing codebase.
Readers will often come here with different goals. If your aim is to understand where code should live and how the package is partitioned, start with the structure page. If you are trying to understand naming, workflow, or organizational choices inherited from earlier work, the migration page provides the most useful background. If you already know where you need to work and want the maintenance expectations directly, move quickly to the contributing page.
Tip
Before making a substantial change, it is usually worth reading the structure page first. That one step often prevents changes that work locally but cut across the intended CLI, documentation, or package boundaries.