Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

oocgcm does not trivially apply to mitgcm outputs #44

Open
serazing opened this issue Feb 2, 2017 · 8 comments
Open

oocgcm does not trivially apply to mitgcm outputs #44

serazing opened this issue Feb 2, 2017 · 8 comments
Assignees

Comments

@serazing
Copy link
Collaborator

serazing commented Feb 2, 2017

I have worked on adding the grid of the mitgcm, it requires a few hack to make it work with the current API:

  • I do not have a mask with the mitgcm files so I used the 'cell_vertical_fraction_at_t_location' instead. It seems to work for the moment even if it is not the best solution
  • I skipped the chunk checking
  • I have relaxed the condition on the required array and have added a function to generate the the cell_size if needed

I have successfully computed some gradients but the laplacian does not work. I think there is some work to do to test if oocgcm apply well to different models.

I have pushed a branch to keep working on it, @rabernat you might be interested in.

@serazing serazing self-assigned this Feb 2, 2017
@rabernat
Copy link

rabernat commented Feb 3, 2017

I would be thrilled if you could get this working! I would be happy to help as much as possible.

My preferred approach is to have oocgcm rely only on the dataset metadata, without special logic for different models. So we may need to change certain aspects of xmitgcm metadata construction.

As for the mask, we could easily add mask variables to xmitgcm based on the hfac variables. If you let me know what names / attributes they should have, I will make a PR asap.

@bderembl
Copy link

Is your implementation for mitgcm available somewhere? I'd be glad to try it.
I've been using Ryan's package so far which works great. But having one single tool for nemo and mitgcm would be easier for me.

@serazing
Copy link
Collaborator Author

serazing commented May 30, 2017

@bderembl, I have created a dedicated branch on the github repo: mitgcm. You are welcome to try and contribute to it.

@rabernat, NEMO uses the following binary mask for the C grid:

_nemo_keymap_byte_mask = {
    'tmask': 'sea_binary_mask_at_t_location',
    'umask': 'sea_binary_mask_at_u_location',
    'vmask': 'sea_binary_mask_at_v_location',
    'fmask': 'sea_binary_mask_at_f_location',

What I have done for the MITGCM part, is to use hFacC, hFacV and hFacS as binary masks (which are not really binaries):

        self.variables["sea_binary_mask_at_t_location"] = \
                        self._get(self.coordinate_file, "hFacC",
                                  chunks=self.chunks, grid_location='t')
        self.variables["sea_binary_mask_at_u_location"] = \
                        self._get(self.coordinate_file, "hFacW",
                                  chunks=self.chunks, grid_location='u')
        self.variables["sea_binary_mask_at_v_location"] = \
                        self._get(self.coordinate_file, "hFacS",
                                  chunks=self.chunks, grid_location='v')

If you can generate binary masks in xmitgcm, it would be great. The names do not matter since they are easily changeable inside the code. What is important, I think, is to have the correct comodo-like attributes (ex: "sea_binary_mask_at_t_location")

@bderembl
Copy link

bderembl commented May 30, 2017

thanks.
for some reason, mitgcm doesn't use the same naming convention for netcdf and binary outputs (e.g. HFacW in netcdf and hFacW in binary).

In your first post, you mention that your successfully computed gradients, etc; what kind of outputs were you using? Can you post your script?

@serazing
Copy link
Collaborator Author

It seems feasible to add a if test to read either HFacW or hFacW, probably not the best solution though. Note that using xmitgcm to read binaries returns a Dataset with hFacW.

@rabernat
Copy link

@bderembl: are you aware of xmitgcm?
http://xmitgcm.readthedocs.io/en/latest/
xmitgcm is a python package for reading MITgcm binary MDS files into xarray data structures.

It is complementary to oocgcm and provides a good way to load your data if you use MDS format. There are several of us working on and maintaining xmitgcm, and I think you will really like it.

Regarding the variable names, we have explicitly tried to use the same naming conventions in our generated xarray datasets as MITgcm's netCDF output. But if you find further inconsistencies, please don't hesitate to open a new issue: https://github.com/xgcm/xmitgcm/issues

@rabernat
Copy link

I should also mention that we are working on xgcm:
http://xgcm.readthedocs.io/en/latest/
whose goals are much more overlapping with oocgcm. We hope to some day merge these packages. For now xgcm is very primitive, but it provides some useful low-level routines for working with mitgcm output. Here is an example notebook:
https://gist.github.com/rabernat/ff43c9726803568ccabd2ed5ac6048e4

@bderembl
Copy link

thanks.
I wasn't aware of xgcm and it seems to complement xmitgcm really well.

about the naming issue, I think your notation is consistent with the name of the binary files. the issue is probably in mitgcm itself (cf. mnc_cw_write_grid_info.F and write_grid.F)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants