Roadmap for ROMS/CROCO analysis using xarray/xgcm

[jaard]

Hi!

I just found your code by scanning through the PANGEO forum and I am impressed by the scope of functions that seem to be implemented. I have written a package called xcroco which I started many years ago when nothing else was available. I've had brief discussions with @jbusecke from PANGEO and came to use xgcm upon his recommendation. xcroco is what I use to load and analyse my own CROCO model output. I haven't promoted it really and not many people other than myself have used it.

So i was wondering if you could fill me in on the current developments regarding analysis of ROMS / CROCO output with xarray and xgcm. Is xroms what most people working with those outputs seem to be using in 2022? If so, I would be happy to join the effort, contribute some of my code etc. if there is interest. I'm not sure what functionality may be missing that I could help with. You could check out my xcroco example notebook to get an idea of what my package contains so far.

Hope to collaborate in the future!
I feel like the ROMS / CROCO community is in need of some standardization... a lot of people seem to still be using their own tools, written in Matlab (!) or Python.

Cheers,
Jaard

[jbusecke]

Thanks for tagging me @jaard. I would like to take the opportunity to introduce the new grid_ufunc functionality of xgcm. This makes it significantly easier to implement customized computations (as might be required for certain models) and makes the operations much more performant when using dask.

I think it would be amazing if we could consolidate some ROMS specific functionality into a collection of grid ufuncs (from a quick check of the code, many functions should not require too much reworking?).

cc @TomNicholas

[kthyng]

Hi @jaard and @jbusecke! Thanks for the discussion here. I just want to send a note that I'm out on parental leave right now so not working but I'll chime in here in the next few weeks as I am working again. Thank you!

[kthyng]

@jaard and @jbusecke as perhaps was predictable, things have been really busy. Sorry for my delay. I'm taking a few hours today to give xroms a little love and respond to people!

@jaard I hadn't heard of CROCO before, but it looks good and seems like code would equally apply between the two models — or are there important differences in the output format or grid setup of CROCO?

Is xroms what most people working with those outputs seem to be using in 2022?

I don't know! I would have said no, but I have gotten a number of issues pulled up by people I don't know, and now and then hear about people actually using it but without opening issues. So, I think there is a small user base. I think most people probably use pyroms if they are using Python, though it doesn't use xarray and associated tools, and really most people are using Matlab tools I think.

If so, I would be happy to join the effort, contribute some of my code etc

This sounds great to me if you are still interested! I hope to get some thing spruced up today, especially packaging. I have also put quite a bit of effort into a more general ocean model package that I think xroms should rely on to do the things that can be more generalized: https://github.com/axiom-data-science/extract_model

[kthyng]

@jbusecke What are the obvious places in the code to incorporate xgcm's grid_ufuncs? Sounds like a good way to go!

[jbusecke]

Hi @kthyng @jaard. Thanks for the ping.
It seems to me (and I only scanned the code/example notebook briefly) contains a lot of numpy code, which might be relatively easily converted to xgcm grid_ufuncs, giving the benefit of layering such a computation on very large datasets in a lazy fashion.
I am however now realizing that a lot of the content of xcroco is used to 'prep' ROMS output for the use with xgcm? This would probably not fit into a use_case that I mentioned (apologies if I read this too fast back then).
What I find an interesting use case is the extraction of sections. This is something that would surely be useful for xgcm users.

I wonder if @TomNicholas (who actually wrote the implementation of the grid_ufuncs) has some ideas on this particular example. Tom, what do you think about the section interpolation in @jaard s notebook. Could we accomodate somethign like that with grid_ufuncs?

[jaard]

Hi @kthyng, thanks for the reply!

@jaard I hadn't heard of CROCO before, but it looks good and seems like code would equally apply between the two models — or are there important differences in the output format or grid setup of CROCO?

It should be mostly the same, but some variables may have different names depending on the exact version (e.g. "ocean_time" vs. "time").

If so, I would be happy to join the effort, contribute some of my code etc

This sounds great to me if you are still interested! I hope to get some thing spruced up today, especially packaging. I have also put quite a bit of effort into a more general ocean model package that I think xroms should rely on to do the things that can be more generalized: https://github.com/axiom-data-science/extract_model

I have briefly scanned your code and realized that we solved pretty much the same problems in similar ways, just that your toolbox seems to be much more complete ;-) So I'm not sure how much I can really add, I guess I just have to accept that my package is a bit redundant now.

Do you have exact vertical integration in xroms? That's something that's still missing from xcroco as well, which I'm about to add.

[jaard]

Hi @jbusecke

I am however now realizing that a lot of the content of xcroco is used to 'prep' ROMS output for the use with xgcm? This would probably not fit into a use_case that I mentioned (apologies if I read this too fast back then).

No problem. But yeah, both xroms and xcroco are basically a wrapper around xarray for calculating depth of sigma-levels etc. which then makes use of xgcm.

What I find an interesting use case is the extraction of sections. This is something that would surely be useful for xgcm users.

I wonder if @TomNicholas (who actually wrote the implementation of the grid_ufuncs) has some ideas on this particular example. Tom, what do you think about the section interpolation in @jaard s notebook. Could we accomodate somethign like that with grid_ufuncs?

I agree that sections would be useful to have in xgcm. My sections in xcroco are pretty "dumb" unfortunately, as it works only on a rectilinear lat/lon grid or in the xi_rho/eta_rho model coordinates. In xroms @kthyng makes use of xESMF to handle curvilinear grids, which is great I think. But its another dependency, and I'm not sure it is appropriate to require that for xgcm. Would it be possible to support curvilinear grids natively in xgcm somehow, or is something like that always too slow compared to xESMF and doomed to fail?

[kthyng]

Wait can xgcm interpolate in 2D with curvilinear grids? @jbusecke or @jaard?

[kthyng]

Ah it is coming back to me — interpolation in the usage of xgcm is to regrid between, for example, different horizontal grids. However, it is not meant to interpolate to an input set of locations.

[kthyng]

I'll close this issue for now but happy to discuss more in the future!

[jbusecke]

Ah it is coming back to me — interpolation in the usage of xgcm is to regrid between, for example, different horizontal grids. However, it is not meant to interpolate to an input set of locations.

I think the more common usecase is vertical locations. For horizontal curvilinear stuff Id use xesmf.