search

CliMA / Oceananigans.jl

🌊 Julia software for fast, friendly, flexible, ocean-flavored fluid dynamics on CPUs and GPUs
https://clima.github.io/OceananigansDocumentation/stable
MIT License
991 stars 195 forks source link

What should be split into submodules? #495

Closed ali-ramadhan closed 4 years ago

ali-ramadhan commented 5 years ago

Probably makes sense to split output_writers.jl, diagnostics.jl, and poisson_solvers.jl into submodules.

They're turning into megafiles that will benefit from being split into smaller logical chunks.

And this will probably only get worse with time.

glwagner commented 5 years ago

Yes, let's not have megafiles.

I think the question is what shouldn't be in a submodule!

Fields would make good one. It could even be split into a separate package, eg StaggeredFields.jl.

glwagner commented 5 years ago

Probably we should just start with the most important modularizations and work our way to the less important ones. I'd say output writers and poisson solvers are most important. We need the poisson solver functionality written more generally and abstracted a bit more because, if it were, we could use a poisson solver for implicit time-stepping

glwagner commented 5 years ago

Probably Grids will need a submodule when we have more than one.

glwagner commented 5 years ago

This is related to issue #456

ali-ramadhan commented 5 years ago

Ah sorry I remember we talked about this but forgot there's already an existing issue!

Diagnostics and output writers could probably already be split into submodules.

Maybe the grids can be modularized at the same time as the vertically stretched grid is introduced, while the Poisson solvers can be modularized when the new FACR solver (PR #306) is introduced (which might nuke some existing solvers too).

glwagner commented 5 years ago

I am wondering if physics should also go to submodules, eg Buoyancy, Coriolis, and soon, SurfaceWaves.

I think this will help us keep our parameter structs concise. For example, FPlane is a bit confusing when it appears in isolation. But Coriolis.FPlane is clear. Also, the word "Buoyancy" appears a lot. If all buoyancy-related things are encapsulated within submodules, naming becomes easier.

We can stop exporting so many names at the top-level, and instead export the submodules. So a user will write

buoyancy = Buoyancy.Seawater()

or

coriolis = Coriolis.FPlane()

or

surface_waves = SurfaceWaves.UniformStokesDrift()

What do we think?

glwagner commented 5 years ago

By the way, we might take some inspiration from Documenter.jl's structure:

https://github.com/JuliaDocs/Documenter.jl/tree/master/src

ali-ramadhan commented 4 years ago

Yeah I think it's starting to make a lot of sense for Buoyancy, Coriolis, and SurfaceWaves to have their own modules.

Actually I also think that boundary_conditions.jl is becoming painful to parse and edit and would also benefit from becoming a submodule with multiple files.