Implementing CLM-DART within CESM2.3 #519
Comments
|
New dimensions in cesm2.3.0 include There are also many differences in restart file variables (history and vector_history only show numeric differences), but most of these are just diagnostic variables that should not be impactful on functioning on
|
|
I was not able to reproduce the error (all tests ran as expected) using mct driver implementations of cesm2.3.0 using the following tests below. Note:
Side note: cesm2.3.0 version required methane to be turned on (use_lch4= TRUE) if use_nitrif_denitrif = TRUE. This caused mass balance failure in subsequent model integration after initial DART update. Something to consider for cesm2.3.0 SourceMods. |
|
Hi Brett, this could be a bug in how dart reads the state, e.g if some variables have unlimited and some don't, this would cause the counts length = 0 (instead of 1). |
|
@hkershaw-brown So that possibility has been on my radar. In addition to the use of new dimensions I mentioned above, there is a 'cohort' dimension within the |
A netcdf file may have an unlimited dimension, but a particular variable may not have the unlimited dimension. See #519 for CESM2.3 CLM which has the unlimited cohort dimension. In the example restart and history files no state variables (or any variables) have the cohort dimension. Massive assumption in direct_netcdf_mod.f90 that we want to read the one slice (the latest slice) of the unlimited dimension. This may not be true for all models.
|
Hi Brett, I think what is going on here: Assumptions in direct_netcdf_mod.f90:
In the cesm 2.3 clm, there is an unlimited dimension cohorts which is not used by any of the state variables (and, kind of strangely, not used at all) So this line: num_dims - 1 = 0 Gustavo's compiler is picking up this 1:0 and erroring out. intel 19.1.1.21 (running on Cheyenne) just merrily continues, but the counts are incorrect. The count is set to 1 rather than the length of the dimension. For fill_inflation_restart it does not matter if the state is read in incorrectly, since we just fill the output with (mean and sd (e.g. 1.0, 0.6). Side note here is we don't need to be calling read_state in fill_inflation_restart. For filter, which does need to read the state, I think the read does not happen correctly (count is not the size of the variable) . On write, only 'time' (lower case) can be the unlimited dimension. (This is another assumption in dart. It is a weakness in how we deal with unlimited dimensions (#359 (comment))) All the assumptions above are a bit of a hack. I put a fix on https://github.com/NCAR/DART/tree/fix-unlimited_dim-read which checks the variable for unlimited dimension before adjusting the counts reading and writing. It is a narrow solution (it really just fixes the case where there is an unused unlimited dimension). I'm not sure if the cohorts dimension will be used in the state, if it is then improving the state read/write to cope with various (and multiple) unlimited dimensions gets bumped up the priority list. Let me know if this makes sense or not. |
|
Thanks for looking at this @hkershaw-brown. I took another look and have a few responses and questions. First, I was not able to recreate the dimension error mismatch during my initial tests because, as you suspected, the I redid the test by merging in your updates for Couple questions -- should I have been able to detect this dimension issue mismatch with my intel compiler settings? It seems the ability to catch this may be compiler specific, and not necessarily something that can be captured by a more stringent set of compiler options/flags? Is that your understanding? Also, it would seem, this fix is specific to the DART code, and the cmcc compiler with still fail unless the CLM dimensional values are changed, including the offending It's not exactly clear to me what the role of the cohort dimension is in CLM -- I need to take a closer look at the documentation. Perhaps it's only used in certain compset configurations (CLM-FATES?) or is currently being used as a placeholder for further code development. We may need to get feedback from the CGD SE's to get more perspective on this. |
|
Hi @braczka and @hkershaw-brown |
|
Hi @tavicoaz -- thank you for the feedback, it is not immediately clear to me yet if the error is related to the inflation file or specific to the cesm2.3 formatting. In the interest of keeping this issue uncluttered could you post your exact same question to the DART help email (DART(at)ucar.edu) and we can better address it there. |
|
Update on this: after discussions with @tavicoaz this is not an immediate issue. Switched to troubleshooting to cesm2.2 since the previous comment. May revisit this later on when cesm2.3 becomes a priority, so should keep this issue open for now. |
A netcdf file may have an unlimited dimension, but a particular variable may not have the unlimited dimension. See #519 for CESM2.3 CLM which has the unlimited cohort dimension. In the example restart and history files no state variables (or any variables) have the cohort dimension. Massive assumption in direct_netcdf_mod.f90 that we want to read the one slice (the latest slice) of the unlimited dimension. This may not be true for all models.
|
note the fix for Fix for IO for NetCDF files when only some variables have the unlimited dimension (was on branch fix-unlimited_dim-read) is in the main branch of dart as on v11.8 |
Use case
Successfully run CLM compsets within DART using CESM2.3. Currently CLM-DART is vetted using release-cesm2.2.0, but the goal here is to anticipate software changes required for cesm2.3 tags.
Is your feature request related to a problem?
Related to reported challenges of implementing DART within CESM2.3 as reported by CMCC group. Specifically cmcc reports a
shape mismatch errorwhen implementingfill_inflation_restartorfilter. This could be related to structural differences between theclm_restart.nc,clm_history.ncandclm_vector_history.ncfiles.There are related issues to this one including the implementation of NUOPC within CESM2.3 and the impact on the CAM6-Reanalysis files. These related issues are here #474 and here #463.
Problem Description
The text was updated successfully, but these errors were encountered: