Closed adamrher closed 5 days ago
Just remembering something @brian-eaton explained to me was the "correct" way to call a pbuf field. I don't remember exactly but I think the optional "ierr" argument is used in the pbuf_get_index call, and that it could be used as a "proxy" for the deep_scheme = 'off' case (i.e, if the ZM pbuf variable doesn't exists, then deep_scheme must be 'off').
This is relevant to step (2) above.
Hi @adamrher. I propose that we have build-namelist
set use_gw_convect_dp=.false.
when deep_scheme='off'
. In the moving mountain code block check whether ttend_dp_idx>0
before trying to associate ttend_dp
with the pbuf. Otherwise allocate ttend_dp
and fill with zeros. Sound OK?
Yes @brian-eaton, that sounds like a plan!
What happened?
When I run a configuration with deep_scheme='off' and use_gw_convect_dp=.true., it errors out as gw_drag.F90 is doing a pbuf_get_index for a ZM pbuf variable that doesn't exist. So I just run with use_gw_convect_dp=.false, which is fine. However, with the new moving mountains gw sources that came in recently, it's using that same pbuf index
ttend_dp_idx
to perform a pbuf_get_field call in the moving mountains code block. If use_gw_convect_dp=.false, then that index retains its initialized value of -1 and the model errors out in the pbuf_get_field call.I propose:
(1) Move the pbuf_get_index outside the
use_gw_convect_dp
conditional (2) Create logic to only call pbuf_get_index if deep_scheme /= 'off', otherwisettend_dp_idx
retains its initialized value of -1 (3) Put a kill switch in ifuse_gw_convect_dp
=.true. andttend_dp_idx
= -1 (4) Add logic around the moving mountain code blockuse_gw_movmtn_pbl
to only perform the pbuf_get_field whenttend_dp_idx
/= -1, else fill an array of the same size as that ZM pbuf variable with zeros, and pass that into the subroutine callgw_movmtn_src
(the ZM array is not actually used by the moving mountains at this time, so making it zero doesn't change answers).What are the steps to reproduce the bug?
see above.
What CAM tag were you using?
cam6_4_015
What machine were you running CAM on?
CISL machine (e.g. cheyenne)
What compiler were you using?
Intel
Path to a case directory, if applicable
No response
Will you be addressing this bug yourself?
Any CAM SE can do this
Extra info
@JulioTBacmeister