fix: passing istatus set for vertislevel and vertisheight mpas_atm

[hkershaw-brown]

Description:

MPAS_ATM user reported that 2m and 10m fields in the state were not being updated by filter when they had vertical localization switched on.

In get_close_state, state with VERTISSURFACE was being converted to VERTISHEIGHT but given a failing istatus so the distance was "far away" (1e9), and thus not updated in the assimilation.

This pull request adds a passing istatus to convert_vert_distrib_state to the cases that did not set an istatus:

• case (VERTISLEVEL)
• case (VERTISHEIGHT)

This istatus was a problem for get_close_state where the convert_vert_distrib_state is used, but not for convert_vertical_state (since that istatus is ignored).

The mpas state is in height (m) so the 3D state variables (non-surface) don't enter the case statement localizing in height (ztypein == ztypeout).

Note I added a note in case (VERTISSCALEHEIGHT) line 5050 because ztypein == VERTISSURFACE can never be .true. at that point in the code. I can pull this out and make a separate issue to keep track of that.

Fixes issue

fixes #756

Types of changes

• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] Documentation update

Documentation changes needed?

• [ ] My change requires a change to the documentation.
  • [ ] I have updated the documentation accordingly.

Tests

I compared the state (no inflation) t2m variables before and after assimilation. no difference = not updated difference = updated.

Checklist for merging

• [ ] Updated changelog entry
• [ ] Documentation updated
• [ ] Update conf.py

Checklist for release

• [ ] Merge into main
• [ ] Create release from the main branch with appropriate tag
• [ ] Delete feature-branch

Testing Datasets

• [x] Dataset needed for testing available upon request
• [ ] Dataset download instructions included
• [ ] No dataset needed

/glade/derecho/scratch/hkershaw/DART/Bugs/mpas_2m_10m/small_run (low res) /glade/derecho/scratch/hkershaw/DART/Bugs/mpas_2m_10m/rundir this is the user case (high res)

[hkershaw-brown]

@hkershaw-brown todo: thanks to Matt Wilson in release notes

[hkershaw-brown]

its a good question Marlee, and it is great to point out things that don't immediately make sense.

the short answer is, these are the dimensions of W (QTY_VERTICAL_VELOCITY)

       float w(Time, nCells, nVertLevelsP1) ;
                w:long_name = "Vertical velocity at vertical cell faces" ;

cell faces -> zGridFace

You'll see this in lot of models (POP, MOM6, MPAS, MITgcm), where various variables are on the edges vs center of cells, and you also might see "layer" or "interface" for the vertical location of the variable. It would get to get someone (one of the dares scientists) to do a little tech talk on the various grids and terminologies (A grid, B grid, etc).

Here is the dimensions in the file:

netcdf init { dimensions: nCells = 10242 ; nEdges = 30720 ; nVertices = 20480 ; TWO = 2 ; maxEdges = 10 ; maxEdges2 = 20 ; R3 = 3 ; vertexDegree = 3 ; nVertLevelsP1 = 56 ; nVertLevels = 55 ; FIFTEEN = 15 ; Time = UNLIMITED ; // (1 currently) StrLen = 64 ; nLags = 140 ; nOznLevels = 59 ; nMonths = 12 ; nSoilLevels = 4 ;

(note my favorite dimension in this is TWO)

float u(Time, nEdges, nVertLevels) ;
float theta(Time, nCells, nVertLevels) ;

mpas model_model doesn't use the state structure for its variable info, so it doesn't just query the dimension. That is why the if statements are checking the QTY directly.

You can checkout the mpas refactor branch to see mpas using the state structure rather than its own progvar vector structure.