read_netCDF_data leads to cryptic model failure when rescale value argument is not 1 #333
Labels
bug
Something isn't working
Comments
|
Can you show the fields or lines where this is happening? |
|
Is it in tidal mixing? MOM6/src/parameterizations/vertical/MOM_tidal_mixing.F90 Lines 510 to 511 in ceb4c92 MOM6/src/parameterizations/vertical/MOM_tidal_mixing.F90 Lines 525 to 526 in ceb4c92 |
|
Yes, these are the variables, but I have a pending fix for this bug. |
Hallberg-NOAA
added a commit
to Hallberg-NOAA/MOM6
that referenced
this issue
Mar 11, 2023
Fixed two horizontal indexing bugs in get_field_nc, where the difference between the array starting index (always 1 in this subroutine) and the values in the handle argument were not being taken into account when the array was being passed in with only its computational domain. Also initialized the internal unlim_index array in get_netcdf_fields to fix a problem with using an uninitialized array that was being flagged when run in debug mode. With this commit, the model is once again reproducing the expected answers when rescaling is applied for vertical distances or time. All answers are bitwise identical in cases that were working before. This commit addresses the issue at github.com/NOAA-GFDL/issues/333, which can be closed once this commit is merged into dev/gfdl.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Calls to
read_netCDF_data()are failing for some fields when the value of the rescale optional argument is not 1. The error messages that are returned are a cryptic warning about invalid memory in the call tohandle%close()at about line 2109 ofMOM_io.F90, but I suspect that this the result of a segmentation fault earlier inread_netCDF_data_2d().The text was updated successfully, but these errors were encountered: