Oceananigans.jl: Roadmap to version 1.0

[ali-ramadhan]

Kinda feels like we're getting closer to a version 1.0 release, although I don't think we need to put a time frame on it. Is it worth discussing which major development milestones we think should be part of v1.0?

Since we're following SemVer I guess it's not really about which features we want to see in v1.0 but more about whether we think the user interface will be relatively stable. New features could be introduced in v1.1, v1.2, etc. but if we make any breaking changes we'll have to release v2.0.

Maybe it's still useful to list some major milestones as they're quite likely to introduce breaking changes?

I'll start with the three big ones on my mind:

• [ ] Pressure solvers for all topologies and grids (#586)
• [ ] MPI distributed parallelism (#590) [not necessarily super optimized, just something that works okay]
• [ ] Vertically stretched grid (#471)

Would be great to hear what people think and if anyone has any thoughts on v1.0.

Might also be good to include @whitleyv's immersed boundary implementation and @francispoulin's shallow water model since both might bring some breaking changes as well.

[navidcy]

pressure solver for all topologies -> definitely
MPI -> yeah, I think that's needed also
vertically stretched grid -> good feature but not a deal breaker for v1.0 in my opinion

[francispoulin]

I agree with @navidcy on all counts. Will add that I hope to have Shallow water model together by early next week. Not needed for 1.0 but I am happy to get it done before 1.0, if possible.

[ali-ramadhan]

Ah I don't see us tagging v1.0 for at least a few, probably even several, months so early next week is way ahead of v1.0 haha.

[glwagner]

I'd vote for resolving #1138 and #963 before releasing a 1.0, and also some usability issues like #890 .

1175 is also breaking.

Something to consider: vertically-stretched grids may require specifying the architecture in grid, rather than model... ? This would be a substantial change to the API. So one motivation for requiring a vertically stretched grid implementation for 1.0 would be so that we don't have to "anticipate" breaking changes that the stretched grid requires.

I'm slightly concerned about boundary conditions too (in principle, we should be able to coalesce TracerBoundaryConditions, UVelocityBoundaryConditions into a single FieldBoundaryConditions specifier). But because it's not super high priority we haven't found time to attend to that and maybe it doesn't matter for 1.0.

[navidcy]

1168 is resolved! no?

[glwagner]

Ahh I meant #1138. Ha!

[navidcy]

ok, makes much more sense :)

[tomchor]

I just thought I'd drop by with my point of view as user and (for now) not a developer. Talking with other people who have tried Oceananigans, the most important thing from our point of view may be the MPI parallelism. I know there is some debate to be had in this topic (I've had a couple discussions with @glwagner myself), but for now my understanding is that it's much easier to have access to CPUs then GPUs. Also if I understand correctly that would allow the model to be run on multiple GPUs, which will allow for some really big simulations resolving a huge array of scales. I bet there's new physics to be found there among the nonlinear interactions between all these scales!

From my point of view (now without talking to other users) #1241 seems like a pretty big issue. It's hard to use Oceananigans if you're not sure you're going to be able to calculate the statistics you need to do your science straightforwardly. For what I want right now it seems like I can use LESbrary.jl, but that might not always be the case. I'd definitely put that in the list of issues to be resolved asap.

From a user perspective I think #890 is also important. I've suffered the consequences of lack of attention to BCs already and it'd be nice to have the model check those for me.

I also think #471 would be nice to have. I agree with @navidcy that it's not a deal breaker, but it would save computation and (if I understand correctly) all the hard work for that has been done already, no?

Anyway, I'm still learning about Oceananigans and might be kind of naive in relation to some of the model's particularities. So please that fact into consideration when assessing my suggestions!

Cheers

[glwagner]

It's hard to use Oceananigans if you're not sure you're going to be able to calculate the statistics you need to do your science straightforwardly. For what I want right now it seems like I can use LESbrary.jl, but that might not always be the case.

If we did not have AbstractOperations at all, then isn't Oceananigans still better off than existing codes? I'd argue that even without AbstractOperations, users are still in decent shape for complicated diagnostics compared to other codes, since they can write their diagnostics code in julia (rather than some other language...)

But perhaps I'm missing something? What special diagnostics features are available in other LES codes? Why is writing a kernel using julia code less straightforward than what you'd have to do in another code?

[glwagner]

I guess I agree that it'd be really nice to solve #1241... I've beat my head against the wall for quite a while on that problem.

One solution is to invest more effort in trying to resolve it. Another possibility is to make the "backup plan" a bit easier (developing custom fields for complicated output). Since it's unlikely AbstractOperations will meet all of users diagnostics needs (considering the possibilty of weird / computationally intensive diagnostics...) I think this is a worthwhile investment anyways, even if we can make AbstractOperations more powerful.

@tomchor perhaps including some examples about how to develop custom diagnostics kernels in your own scripts will be useful, so that you don't feel like you are out of luck unless you have something like the LESbrary? What do you think?

[glwagner]

1245 might need to be addressed too, since its solution might lead to breaking changes.

[tomchor]

Basically, from the docs, I thought the only way to calculate statistics with Oceananigans was to use abstract operations. I have recently found that you can also write kernels, so I guess my comment on that part is invalid.