<div dir="ltr"><div><div><div><div><div><div><div>Hi all,<br><br></div>Two problems in the NEMSAppBuilder are causing a lot of trouble right now.  I held off fixing these issues because it will be disruptive to development, and we&#39;ve had too many development disruptions already.  <br><br>Specifically:<br><br></div>1. The NEMSAppBuilder $FULL_MACHINE_ID used to find modulefiles and conf files has underscores on WCOSS Cray (wcoss_cray) but dots on the IBM parts of WCOSS (wcoss.phase1, wcoss.phase2).  This was done to match the strange mix of conventions the various apps were using when the NEMSAppBuilder was last updated.<br><br></div>2. The NEMSAppBuilder does not delete the configuration files before running NEMS/src/configure.  This can cause it to inadvertently use old configuration information if NEMS/src/configure fails.<br><br></div>It turns out, for several weeks now, the NEMSAppBuilder has not been able to build the NEMSfv3gfs on WCOSS phase 1 and phase 2 due to bug #1 listed above.  The reason nobody noticed this (including the nightly tests) is that the NEMSfv3gfs compile.sh was run first, for earlier compsets in the same test suite.  That compile.sh left behind valid modules.nems, externals.nems, and ESMFVersionDefine.h.  The NEMSAppBuilder was run next, to test the fv3_appbuilder compset.  It failed to run configure because it was looking for configure.fv3.wcoss.phase2 (or phase1) which did not exist.  However, the NEMSAppBuilder didn&#39;t delete the configuration information compile.sh left behind, so the build continued as if nothing had gone wrong (bug #2 listed above).<br><br></div>It is possible that all apps will need to make minor changes to their compsets and appbuilder files as a result of fixing these two bugs.  I&#39;m going to try this myself on the supported apps first and report the results.<br><br></div>Sincerely,<br></div>Sam Trahan<br></div>