eamxx: Error not obvious when trying to run certain compsets that require 72 vertical levels

[ndkeen]

This issue is courtesy to those who will run into this error and be confused of cause. We currently use 128 vertical levels by default, but there are still some compsets that are dependent on 72 levels. Launch script would need to change this, or if using a test, use the eamxx-L72 modifier.

Should we allow these compsets to run with 128 vert levels? Or perhaps fail much sooner (at setup) with better error message? Or is this fine behavior for now.

For example, with SMS_D_Ln22.conusx4v1pg2_r05_oECv3.F2010-SCREAMv1-noAero, error is below.
Would need SMS_D_Ln22.conusx4v1pg2_r05_oECv3.F2010-SCREAMv1-noAero.pm-cpu_intel.emaxx-L72

 0: PIO: FATAL ERROR: Aborting... FATAL ERROR: No such file or directory (file = UNSET) (/global/cfs/cdirs/e3sm/ndk/repos/c31-nov6/externals/scorpio/src/clib/pioc_support.cpp: 5446)
  0: PIO: WARNING: Opening file (UNSET) with iotype=1 (PIO_IOTYPE_PNETCDF) failed (ierr=-220, Specified netCDF file does not exist.). Retrying with iotype=PIO_IOTYPE_NETCDF
  0: Obtained 10 stack frames.
  0: /pscratch/sd/n/ndk/e3sm_scratch/pm-cpu/c31-nov6/ERS_Ln22.conusx4v1pg2_r05_oECv3.F2010-SCREAMv1-noAero.pm-cpu_intel.eamxx-bfbhash.gh6834/bld/e3sm.exe() [0x398207d]
  0: /pscratch/sd/n/ndk/e3sm_scratch/pm-cpu/c31-nov6/ERS_Ln22.conusx4v1pg2_r05_oECv3.F2010-SCREAMv1-noAero.pm-cpu_intel.eamxx-bfbhash.gh6834/bld/e3sm.exe() [0x39822be]
  0: /pscratch/sd/n/ndk/e3sm_scratch/pm-cpu/c31-nov6/ERS_Ln22.conusx4v1pg2_r05_oECv3.F2010-SCREAMv1-noAero.pm-cpu_intel.eamxx-bfbhash.gh6834/bld/e3sm.exe() [0x398244f]
  0: /pscratch/sd/n/ndk/e3sm_scratch/pm-cpu/c31-nov6/ERS_Ln22.conusx4v1pg2_r05_oECv3.F2010-SCREAMv1-noAero.pm-cpu_intel.eamxx-bfbhash.gh6834/bld/e3sm.exe() [0x398bb6c]
  0: /pscratch/sd/n/ndk/e3sm_scratch/pm-cpu/c31-nov6/ERS_Ln22.conusx4v1pg2_r05_oECv3.F2010-SCREAMv1-noAero.pm-cpu_intel.eamxx-bfbhash.gh6834/bld/e3sm.exe() [0x398c375]
  0: /pscratch/sd/n/ndk/e3sm_scratch/pm-cpu/c31-nov6/ERS_Ln22.conusx4v1pg2_r05_oECv3.F2010-SCREAMv1-noAero.pm-cpu_intel.eamxx-bfbhash.gh6834/bld/e3sm.exe() [0x2693522]
  0: /pscratch/sd/n/ndk/e3sm_scratch/pm-cpu/c31-nov6/ERS_Ln22.conusx4v1pg2_r05_oECv3.F2010-SCREAMv1-noAero.pm-cpu_intel.eamxx-bfbhash.gh6834/bld/e3sm.exe() [0x247cbc8]
  0: /pscratch/sd/n/ndk/e3sm_scratch/pm-cpu/c31-nov6/ERS_Ln22.conusx4v1pg2_r05_oECv3.F2010-SCREAMv1-noAero.pm-cpu_intel.eamxx-bfbhash.gh6834/bld/e3sm.exe() [0x2479025]
  0: /pscratch/sd/n/ndk/e3sm_scratch/pm-cpu/c31-nov6/ERS_Ln22.conusx4v1pg2_r05_oECv3.F2010-SCREAMv1-noAero.pm-cpu_intel.eamxx-bfbhash.gh6834/bld/e3sm.exe() [0x24798e2]
  0: /pscratch/sd/n/ndk/e3sm_scratch/pm-cpu/c31-nov6/ERS_Ln22.conusx4v1pg2_r05_oECv3.F2010-SCREAMv1-noAero.pm-cpu_intel.eamxx-bfbhash.gh6834/bld/e3sm.exe() [0x155d932]
  0: MPICH ERROR [Rank 0] [job id 45068857.0] [Mon Nov 10 14:59:17 2025] [nid007139] - Abort(-1) (rank 0 in comm 0): application called MPI_Abort(MPI_COMM_WORLD, -1) - process 0
  0: 
  0: aborting job:
  0: application called MPI_Abort(MPI_COMM_WORLD, -1) - process 0
  0:  WARNING! prim_init_model_f90 was not called yet (or prim_finalize_f90 was alrea
  0:  dy called)
  0:   We assume this is happening because an exception was thrown during initializat
  0:  ion,
  0:   and we're destroying objects as part of the stack unwinding.
  0: double free or corruption (!prev)
  0: forrtl: error (76): Abort trap signal
  0: Image              PC                Routine            Line        Source             
  0: libpthread-2.31.s  000014BC4B2AC910  Unknown               Unknown  Unknown

[bartgol]

I think this is b/c of the missing IC file specification in our namelist default for the conus grid and 128 lev, right? I think there are two possible courtesy checks we could do

• runtime: print a more informing error message. When detecting that a filename is "" or "UNSET" or some other invalid string, we should not even bother trying to create a reader, but instead print an error, with more context.
• setup: we could think of issuing an error if this is an initial run and there is no valid IC file in the input params. Notice that this is technically not an error, as the user may (wildly) decide to set ALL input fields to some constant value, in which case the driver will not even attempt to open the IC file. Of course, this is a wild scenario, so we could consider always enforcing that initial_conditions::filename is a valid string.