E3sm: INFs in CPL diagnostic input/output

[worleyph]

I was looking to replace the "in-line" BFB algorithm in seq_diag_avect_mct with a call to shr_reprosum_calc. seq_diag_avect_mct is called in component_diag only if info_debug > 1 (the default is info_debug == 1).

In my testing, the implementation using shr_reprosum_calc is failing with a warning that the input data contain INFs. Looking at the original code, INFs are probably being reset to 0 (as a side effect of the implementations). Rerunning with the non-BFB algorithm (), it does report INF the first time seq_diag_avect_mct is called.

 comm_diag xxx sorr   1 0.0000000000000000000E+00 recv IC atm Sa_z
 comm_diag xxx sorr   2 0.0000000000000000000E+00 recv IC atm Sa_topo
 comm_diag xxx sorr   3 0.0000000000000000000E+00 recv IC atm Sa_u
 comm_diag xxx sorr   4 0.0000000000000000000E+00 recv IC atm Sa_v
 comm_diag xxx sorr   5                  Infinity recv IC atm Sa_tbot
 comm_diag xxx sorr   6 0.0000000000000000000E+00 recv IC atm Sa_ptem

I still want to update this code. I can add an explicit workaround to eliminate the INFs for the implementation using shr_reprosum_calc, but I want to check whether this is a bug that can be addressed before this call.

The test case was

 -compset A_WCYCL1950S_CMIP6_LR -res ne30_oECv3_ICG

run on Anvil.

Not sure who to assign this to, but starting with @rljacob (for CPL) and @singhbalwinder (since this is ATM related).

[worleyph]

So, it appears that initializing Sa_tbot to INF is deliberate and specific to this field (lines 462-464 in physpkg.F90, in routine phys_inidat).

do lchnk=begchunk,endchunk
   cam_out(lchnk)%tbot(:) = posinf
end do

So it is "desirable" to sum over these infinities during this first call to seq_diag_avect_mct? If so, I'll look at modifying shr_reprosum_calc to warn about this but still go ahead and calculate it. It will require an additional MPI_Allreduce though, slowing down the routine. Please do advise though.

[singhbalwinder]

Hi @worleyph ,
I am not very familiar with this part of the code and the codes you are working with. Assigning variables to infinities is generally done to ensure that they are not used inadvertently. I guess this may be the reason here as well but I am not sure. If this is the primary reason, we may be able to achieve the same effect after you do your calculations in the first call to seq_diag_avect_mct. Again, I am just guessing here without knowing the codes. Insights from somebody who knows these codes might be more useful.

[worleyph]

Insights from somebody who knows these codes might be more useful.

Any idea how to identify someone who knows this part of phys_inidat, or when/how Sa_tbot is computed?

[brian-eaton]

It is safe to remove the code causing the problem. After some digging in very dusty archives I found that that code was added in cam3_6_39 to replace code which was supposed to be trying to initialize TBOT from the initial file, but was actually broken and doing nothing. I assume the replacement code was thought to do no harm. But this variable is initialized along with all the other surface state variables to zero in camsrfexch.F90.

[worleyph]

@brian-eaton , thanks! Which code in particular? The initialization of cam_out(lchnk)%tbot(:)? I assume that it needs to be initialized to something (if not posinf) before it is passed into seq_diag_avect_mct? Or should I instead initialize it to zero in this location in phys_inidat?

[brian-eaton]

The code in phys_inidat setting cam_out%tbot to posinf should be removed. tbot is initialized in camsrfexch.F90 (in routine atm2hub_alloc).

[worleyph]

@brian-eaton - I see - it has already been initialized. Thanks again.