Started by an SCM change397c365e917824d4ca09c1a28b5c1f782bfd1773562c365e917824d4ca09c1a28b5c1f782bfd1773562refs/remotes/origin/masterc365e917824d4ca09c1a28b5c1f782bfd1773562c365e917824d4ca09c1a28b5c1f782bfd1773562refs/remotes/origin/masterc365e917824d4ca09c1a28b5c1f782bfd1773562c365e917824d4ca09c1a28b5c1f782bfd1773562refs/remotes/origin/masterhttps://github.com/larson-group/clubb.gitfalse#397216235868031clubb_BFB_r8029_flags_gfortran_test #397397false3974848SUCCESS1731403628161http://carson.math.uwm.edu/jenkins/job/clubb_BFB_r8029_flags_gfortran_test/397/src/CLUBB_core/advance_xp2_xpyp_module.F90c365e917824d4ca09c1a28b5c1f782bfd17735621731347440000http://carson.math.uwm.edu/jenkins/user/bmg2bmg2bmg2@uwm.eduAs part of generalizing the code to work with both an ascending and descending grid, I discovered an issue. The issue occurs in the xp2/xpyp "upwind" turbulent advection code and involves the "sgn_" variables. Ultimately, for other PDFs, I was setting this variable using equations of the form sign( one, variable) which set the value to either 1 or -1 no matter the value of variable. However, for the ADG1 PDF, I was lazy and simply just set the value of sgn_ to be equal to wp3_on_wp2. The issue arose when wp3_on_wp2 had a value of 0, and therefore is neither negative or positive. To rectifiy the issue, all settings of "sgn_" variables now use equations of the form sign( one, variable ). For a vast majority of cases, this change had absolutely no effect on the results and everything stayed bit-for-bit. However, BIT_CHANGING results were detected for CGILS S6, MC3E, and TWP-ICE. 2024-11-11 11:50:40 -0600c365e917824d4ca09c1a28b5c1f782bfd1773562As part of generalizing the code to work with both an ascending andeditsrc/CLUBB_core/advance_xp2_xpyp_module.F90githttp://carson.math.uwm.edu/jenkins/user/bmg2bmg2false398http://carson.math.uwm.edu/jenkins/job/clubb_BFB_r8029_flags_gfortran_test/398/396http://carson.math.uwm.edu/jenkins/job/clubb_BFB_r8029_flags_gfortran_test/396/