Started by user Brian GriffingriffinbBrian Griffin188e5ec9afb7da53442bdee3952105faf142b9c3007e5ec9afb7da53442bdee3952105faf142b9c3007refs/remotes/origin/clubb_silhs_devele5ec9afb7da53442bdee3952105faf142b9c3007e5ec9afb7da53442bdee3952105faf142b9c3007refs/remotes/origin/clubb_silhs_devele5ec9afb7da53442bdee3952105faf142b9c3007e5ec9afb7da53442bdee3952105faf142b9c3007refs/remotes/origin/clubb_silhs_develhttps://github.com/larson-group/cam.gitfalse#18813449002524808cam_BFB_coarse_res_gfortran_test #188188false18810278SUCCESS1747962263452http://carson.math.uwm.edu/jenkins/view/all/job/cam_BFB_coarse_res_gfortran_test/188/src/physics/cam/clubb_intr.F90f3e4feee74e7ead32bdc9e6373c1217b7dbb5e3c1747956100000http://carson.math.uwm.edu/jenkins/user/bmg2bmg2bmg2@uwm.eduI've got the magic fix I know if I can fix it once, I can fix twice I fix the baddest bugs ... Changing the pbuf_get_field calls to only go from 1 to ncol in the column dimension for the variables that are newly being passed directly into advance_clubb_core_api thanks to our removal of the _in variables (e.g. wp2_in) in a recent commit. This solves the problem of trying to shove a (pverp-top_lev+1 x pcols) size box into the hole for a (pverp-top_lev+1 x ncol) size box. G-UNIT!!! 2025-05-22 18:21:40 -0500f3e4feee74e7ead32bdc9e6373c1217b7dbb5e3cI've got the magic fixeditsrc/physics/cam/clubb_intr.F90githttp://carson.math.uwm.edu/jenkins/user/bmg2bmg2false189http://carson.math.uwm.edu/jenkins/view/all/job/cam_BFB_coarse_res_gfortran_test/189/187http://carson.math.uwm.edu/jenkins/view/all/job/cam_BFB_coarse_res_gfortran_test/187/