Core library design and pre/post split consolidation of duplicate functionality in schism and swan

[benjaminleighton]

@tomdurrant is the plan to still have a very lightweight rompy-core or to keep that as a place that developers would put common cross cutting functionality. I think a "read-only" rompy-core could make it difficult to identify and develop common functionality.

For example some analysis suggests

Category	Duplicated Module/Concept	Files / Classes Involved	Recommended Action	Priority
Testing	Generic Test Utilities	test_utils.py (compare_files, compare_nmls, etc.)	Move to a single rompy_core/tests/utils.py.	High
Data Handling	Tidal Data Processing	TidalDataset	Move to rompy_core/boundary.py.	High
Data Handling	Boundary Condition Abstractions	BoundaryHandler, BoundaryConfig, ElevationType, VelocityType	Move to rompy_core/boundary.py. Refactor SWAN to use them.	Medium
Configuration	Base Namelist Model	NamelistBaseModel	Move to rompy_core/namelist.py. Update all models to inherit.	High
Developer Tools	AI-based Model Generation	generate_models.py (ClaudeClient)	Move to a central rompy_core/scripts/ directory.	Medium
Plotting	Visualization Base Logic	Various plot_* functions	Create rompy_core.plotting with base classes. Refactor model-specific plots to inherit.	Low

[tomdurrant]

Hi Ben,

Yes, the split is still very much the plan and is very near complete. This has been quite involved, and while this i not the final outputs, they are very close.

https://github.com/rom-py/rompy-swan
https://github.com/rom-py/rompy-schism
https://github.com/rom-py/rompy-core

Thanks for your analysis here. I few comments from my end, in the order they are listed:

1. Tests are not packaged, so can't be inherited. We could package them (or a subset), but the shared testing frameworks is actaully very slim at the momement. I have duplicated a couple of things, others (like compare_nml) I have just put with the model that uses them (schism in this case).
2. This is likely a candidate for moving into a shared area, but probably not core. It carries pyTMD and dependencies and a fair amount of tidal definition baggage that is currently only relevant to schism. While it may one day be relevant for SWAN and others, it will never be relevant for say CCAM.
3. There are all very schism specific. They deal with both the very prescriptive data input layout required by schism, as well as the data processing which is again very schism focused. The essentially unify the configuration and data processing, removing the need for the user to ensure consistency. These are documented here https://rom-py.github.io/rompy/schism/boundary_conditions.html#benefits-of-the-new-system. The wave boundary extraction is common between schism and swan with both respective data objects inheriting from rompy.core.boundary.BoundaryWaveStation
4. There are not really generalised AI tools. While there is now a case to develop such tools, these are not those. They are just simple scripts that hit the claude api directly to translate some of the example schism namelists into pydantic models.
5. This is legacy. Again, we can add some plotting to the core package, but nothing is currently using what is in existing core.

My feeling is we don't need to decide everything right now. The priority is to get a reasonably clean migration that and continuity of development across the split. If there are common elements that develop as we develop, we can always elevate them up the chain.

The current migration plan is here. The only slightly contentious thing here is the proposal to leave the main library as rompy and not rompy-core

https://github.com/rom-py/rompy/blob/split/MIGRATION_PLAN.md