[DevOps]: xgcm warnings polluting test suite and yaksa leaking handlers

[tomvothecoder]

There are DeprecationWarnings from xgcm that are polluting the test suite.

Warning 1

  /usr/share/miniconda3/envs/xcdat_ci/lib/python3.11/site-packages/xgcm/grid.py:1283: DeprecationWarning: The `xgcm.Axis` class will be deprecated in the future. Please make sure to use the `xgcm.Grid` methods for your work instead.

Source:

• https://github.com/xgcm/xgcm/blob/0934c3722d0b8e4842fe8e1bc3daba2ee70f665b/xgcm/grid.py#L1282-L1288
• These warnings will always appear whenever we reference the Grid class. Idk why they decided to do this instead of having the warning in the Axis class instead.

Solution:

• Now - silence these specific deprecation warnings
• Future - The next xgcm will remove the Axis class and the deprecation warnings

Warning 2

  /usr/share/miniconda3/envs/xcdat_ci/lib/python3.11/site-packages/xgcm/grid.py:989: FutureWarning: From version 0.8.0 the Axis computation methods will be removed, in favour of using the Grid computation methods instead. i.e. use `Grid.transform` instead of `Axis.transform`
    warnings.warn(

Source:

• https://github.com/xgcm/xgcm/blob/0934c3722d0b8e4842fe8e1bc3daba2ee70f665b/xgcm/grid.py#L989-L994
• These warnings will always appear like the other warning.

Solution:

• Now - silence these specific deprecation warnings
• Future - The next xgcm will remove the Axis class and the deprecation warnings

Warning 3

Also a "yaksa: 10 leaked handle pool objects".

Not sure what is causing this one.

[pochedls]

I wonder if the yaksa issue is something that goes beyond dev ops. I get it when exiting iPython. I first noticed it in the vertical regridding PR, but I could reproduce it on main (so I think it preceded vertical regridding).

[tomvothecoder]

I wonder if the yaksa issue is something that goes beyond dev ops. I get it when exiting iPython. I first noticed it in the vertical regridding PR, but I could reproduce it on main (so I think it preceded vertical regridding).

Based on what I read below, we can probably ignore this warning unless it actually causes some issue.

The full message is:

[WARNING] yaksa: 2 leaked handle pool objects

I believe it is coming from MPICH itself. I see the same warning running other Python scripts and PETSc executables.
Note that this is a warning and not an error and I have been safely ignoring it.

If the above warning is causing some other issues, specifically with Firedrake, feel free to elaborate below.

-- Source: firedrakeproject/firedrake#2672

[tomvothecoder]

Also a "yaksa: 10 leaked handle pool objects".

I performed debugging for a segmentation fault in e3sm_diags introduced by cdms2=3.1.5 patch 21 which was released two weeks ago (PR). This yaksa warning appears in patch 21 (includes support for esmf>=8.4). However, it does not appear in patch 20 which uses esmf=8.2.0.

I think esmf>=8.4 might be producing these yaksa warnings.

[chengzhuzhang]

Also a "yaksa: 10 leaked handle pool objects".

I performed debugging for a segmentation fault in e3sm_diags introduced by cdms2=3.1.5 patch 21 which was released two weeks ago (PR). This yaksa warning appears in patch 21 (includes support for esmf>=8.4). However, it does not appear in patch 20 which uses esmf=8.2.0.

I think esmf>=8.4 might be producing these yaksa warnings.

In my e3sm_diags testing with e3sm_unifiedrc12, I also saw "yaksa: 10 leaked handle pool objects". Not sure if this is related to slow e3sm_diags run on Chrysalis.E3SM-Project/zppy#485

[tomvothecoder]

Also a "yaksa: 10 leaked handle pool objects".

I performed debugging for a segmentation fault in e3sm_diags introduced by cdms2=3.1.5 patch 21 which was released two weeks ago (PR). This yaksa warning appears in patch 21 (includes support for esmf>=8.4). However, it does not appear in patch 20 which uses esmf=8.2.0.
I think esmf>=8.4 might be producing these yaksa warnings.

In my e3sm_diags testing with e3sm_unifiedrc12, I also saw "yaksa: 10 leaked handle pool objects". Not sure if this is related to slow e3sm_diags run on Chrysalis.E3SM-Project/zppy#485

@chengzhuzhang When I have time I will try to create a minimum reproducible example with ESMF/xESMF to figure out why and where this warning might be thrown. I'll open up a GitHub issue in the esmf repo afterwards.

It might be a useful experiment to compare performance of e3sm_diags using ESMF 8.2 vs. 8.4+ (through cdms2).