Started by an SCM change379b89dc55c506ad16e5a3c8eeab762fe3156a8d1e1b89dc55c506ad16e5a3c8eeab762fe3156a8d1e1refs/remotes/origin/clubb_silhs_develb89dc55c506ad16e5a3c8eeab762fe3156a8d1e1b89dc55c506ad16e5a3c8eeab762fe3156a8d1e1refs/remotes/origin/clubb_silhs_develb89dc55c506ad16e5a3c8eeab762fe3156a8d1e1b89dc55c506ad16e5a3c8eeab762fe3156a8d1e1refs/remotes/origin/clubb_silhs_develhttps://github.com/larson-group/cam.gitfalse#37912269311357597cam_BFB_coarse_res_r8029_flags_gfortran_test #379379false3793900SUCCESS1779869649008http://carson.math.uwm.edu/jenkins/job/cam_BFB_coarse_res_r8029_flags_gfortran_test/379/advance_wp2_wp3_module.F90advance_xp2_xpyp_module.F90advance_clubb_core_module.F90advance_xp3_module.F90advance_xm_wpxp_module.F90stats_clubb_utilities.F90advance_helper_module.F9072b3ab76bcae108c36fc6d3130c7c9c4539bfc281779832578000http://carson.math.uwm.edu/jenkins/user/noreplynoreplynoreply@github.comClubb organization part2 (#1304) A number of fields were being calculated in `advance_clubb_core` (`wp2_zt` `wp3_on_wp2` `wp3_on_wp2_zt` `Skw_zm` `Skw_zt) then passed into other routines, however, all these fields depend on `wp2` and were not being updated after `wp2` was being updated by `calc_sfc_varnce`. This commit fixes that by moving where these fields are calculated - instead of computing in `advance_clubb_core` with the incoming `wp2`, we now calculate them "on-demand" where they are needed using the most recent value of `wp2`. Using our default flag set, there are no numerical differences caused by this change set, only a few stats differences. There are real differences that occur when `l_upwind_xpyp_ta = .false.` (a clubb_config_flag value) or when `l_explicit_turbulent_adv_xpyp = .true.` (a parameter in model_flags.F90), but these are small differences and do not visually affect plots for our stable cases. Changing the order of the `advance_` routines would also cause this to be BIT_CHANGING, since that also affects the update path for `wp2` - now these values that got moved would be using the newest `wp2` instead of being "stale", also causing small (but real) differences. * Calculating wp2_zt and wp3_on_wp2 where needed, rather than passing those values around through advance_clubb_core. This is BIT_CHANGING for a handful of stats only variables be default: wp3_on_wp2, wp3_on_wp2_zt, wp3_on_wp2_cfl_num, term_wprtp2_explicit, term_wprtpthlp_explicit, and term_wpthlp2_explicit. Some Skw_ variables when using lmm_stepping, and has actual differences (not just in stats output) when swapping the order of the advance routines * Moving things around, this seems to all be BFB except for the Skw_ movements, which is BIT_CHANGING if the advance_ order changes * Fixing python API * Reverting some BFB changes 2026-05-26 16:56:18 -050072b3ab76bcae108c36fc6d3130c7c9c4539bfc28Clubb organization part2 (#1304)editadvance_clubb_core_module.F90editstats_clubb_utilities.F90editadvance_xp3_module.F90editadvance_xp2_xpyp_module.F90editadvance_helper_module.F90editadvance_wp2_wp3_module.F90editadvance_xm_wpxp_module.F90githttp://carson.math.uwm.edu/jenkins/user/noreplynoreplyfalse378http://carson.math.uwm.edu/jenkins/job/cam_BFB_coarse_res_r8029_flags_gfortran_test/378/