Oceananigans.jl
Oceananigans.jl copied to clipboard
CliMA
Support curvilinear grids with `NetCDFOutputWriter`?
Right now it looks like we're assuming rectilinear grids, eg:
https://github.com/CliMA/Oceananigans.jl/blob/adffd0cb67373da364a54d7f300d1f33817539bd/src/OutputWriters/netcdf_output_writer.jl#L31-L43
and
https://github.com/CliMA/Oceananigans.jl/blob/adffd0cb67373da364a54d7f300d1f33817539bd/src/OutputWriters/netcdf_output_writer.jl#L28-L29
For rectilinear grids there are just six node ranges (2 locations for each dimension); however on curvilinear grids there are 24 (8 locations for each dimension).
One possibility is to attempt to infer the dimensions of the output and store verbose names like "xᶠᶠᶜ". We can also store the six defaults that we have currently but with new verbose names "xᶠᶜᶜ". Note that in a latitude-longitude coordinate system, x becomes λ, etc.
I think it's also nice if the grid can be easily reconstructed from the file content. We would need this if we ever support FieldTimeSeries with NetCDFOutputWriter.
I don't know if it's relevant, but whatever solutions we invent we may want to think a bit about how we are going to make maintaining output writers easier in the future. Because we may have to support even more output formats (like Zarr).
Curious to hear from the NetCDF users out there like @tomchor, @francispoulin ...
I don't have much insight to give here regarding the problem of maintaining the writers in the future, since I have't changed that part of the code much. Although I agree with @glwagner that other formats may be useful in the future (I see that Julia already has a Zarr package, which is nice!)
One possibility is to attempt to infer the dimensions of the output and store verbose names like "xᶠᶠᶜ". We can also store the six defaults that we have currently but with new verbose names "xᶠᶜᶜ". Note that in a latitude-longitude coordinate system, x becomes λ, etc.
I definitely agree with storing the names currently used in Oceananigans, otherwise I think it may confuse users to have two notations to deal with.
I think it's also nice if the grid can be easily reconstructed from the file content. We would need this if we ever support FieldTimeSeries with NetCDFOutputWriter.
I also agree with that, and possibly we want to make output easier to play with xgcm, like discussed in https://github.com/CliMA/Oceananigans.jl/issues/1334. I think we're already there for regular grids, but I suspect it won't be trivial to get there for curvilinear grids.
I agree with both of you on both counts.
Yes, let's store the names and it would be ideal of the grid can be reconstructed from the data alone.
I don't know anything about xgcm so nothing to add there.
@navidcy points out this might already work for lat lon anyways
I suspect that's the case as well. @glwagner if that's the case, should we add a test for it?
The main thing is that the dimensions will be wrong since we assume "m", but are "deg" with lat lon
@tomchor have a look now that #2979 is merged -- perhaps we are mostly there?
E.g., now the code the @glwagner pointed out at the top msg is
https://github.com/CliMA/Oceananigans.jl/blob/200f0622278fcfa583da0119e9696048b334146f/src/OutputWriters/netcdf_output_writer.jl#L43-L57
This should work for LatitudeLongitudeGrid.
We should modify the netCDF variable names to λF, λC or something... I didn't do this in #2979 because I didn't know if netCDF allows unicode (and because I felt it was outside of the scope of that PR).
We should modify the netCDF variable names to
λF,λCor something... I didn't do this in #2979 because I didn't know if NetCDF allows unicode (and because I felt it was outside of the scope of that PR).
Sorry for the delay in chiming in here. Yes, NetCDF works fine with unicode, but I suspect that due to the SGRID conventions we will have to name our coordinate a default, non-unicode name, which will be different from the names we use in Oceananigans. ~The downside of this is that I think it'll be a bit harder to output spacings and other metrics separately in meters and degrees, which I think would be useful for curvilinear coordinates.~
What are the conventional names? I couldn't find them easily in the link. We can consider changing Oceananigans to reflect the convention if we like the convention.
The downside of this is that I think it'll be a bit harder to output spacings and other metrics separately in meters and degrees, which I think would be useful for curvilinear coordinates.
You mean the convention not only specifies what you have to output but also disallows additional information?
The downside of this is that I think it'll be a bit harder to output spacings and other metrics separately in meters and degrees, which I think would be useful for curvilinear coordinates.
You mean the convention not only specifies what you have to output but also disallows additional information?
I had interpreted something as saying that it puts limits on the metadata in files, but it turns out I misinterpreted. So no, it doesn't disallow anything afaik. I amended my previous statement.
Happy to work on this!
Besides full support for curvilinear grids I think there are a lot of improvements that can be made to NetCDFOutputWriter, and being able to construct a FieldTimeSeries from a NetCDF file would be great.
What would be the first steps? I can draft a list of proposed changes/additions here.
I also see that @tomchor has done quite a bit of work with PRs #2652 and #3143. Also happy to help with those. I do see that grid spacings and metrics can be a thorny subject.
I also see that @tomchor has done quite a bit of work with PRs #2652 and #3143. Also happy to help with those. I do see that grid spacings and metrics can be a thorny subject.
Between these two, I'd say https://github.com/CliMA/Oceananigans.jl/pull/3143 should probably take priority. It should be simpler and I see it as a bug, which should be fixed. That PR didn't move forward because I unfortunately ran out of time, so feel free to take over it if you want! That said, it's a different issue than the one raised by @glwagner here.