After compiling the MPAS core_atmosphere, a stream_list.atmosphere.output file should be generated that contains a routine set of output variables. However, at present, the stream_list.atmosphere.output file that is being generated only contains aerosol-related fields from src/core_atmosphere/physics/registry.chemistry.xml:
e_bb_out
e_dust_out
aero_emis_for_enhmix
swdnb
swdnbc
aod3d_smoke
aod3d
aod550
vis
ddvel
drydep_flux
wetdep_resolved
hwp
frp_out
fre_out
hfx_bb
qfx_bb
PM2_5
PM10
max_bb_plume
min_bb_plume
coef_bb_dc
fire_hist
fire_peak_hr
fire_type
This issue primarily affects users not leveraging a workflow where these assets are stored as fixed files.
In trying to trace back why, I find that the src/core_atmosphere/Makefile includes the following code:
core_input_gen:
if [ ! -e default_inputs ]; then mkdir default_inputs; fi
( cd default_inputs; $(NL_GEN) ../Registry_processed.xml namelist.atmosphere in_defaults=true )
( cd default_inputs; $(ST_GEN) ../Registry_processed.xml streams.atmosphere stream_list.atmosphere. listed in_defaults=true)
I'm inferring that this means that the processed Registry is what is being used to generate these files. This comes from a directive just above that one in the Makefile:
core_reg:
$(CPP) $(CPPFLAGS) $(CPPINCLUDES) $(PHYSICS) Registry.xml > Registry_processed.xml
This gets triggered by the src/Makefile dycore target, which itself is called by the mpas target, which itself is called by the all target. I'm wondering if the Registry.xml that this directive is operating on for some reason only contains the aerosol-related portion of the Registry?
I was able to confirm that compiling the last hash before the initial SMOKE submodule implementation (9ce949e, v8.3.0-1.17) generates the correct stream_list.atmosphere.output based on the full model Registry.xml but that compiling the hash associated with the initial SMOKE submodule implementation (3cb859c, v8.3.0-2.0) does not. @haiqinli and @jordanschnell - could one of you please look into this?
After compiling the MPAS core_atmosphere, a stream_list.atmosphere.output file should be generated that contains a routine set of output variables. However, at present, the stream_list.atmosphere.output file that is being generated only contains aerosol-related fields from src/core_atmosphere/physics/registry.chemistry.xml:
This issue primarily affects users not leveraging a workflow where these assets are stored as fixed files.
In trying to trace back why, I find that the src/core_atmosphere/Makefile includes the following code:
core_input_gen:if [ ! -e default_inputs ]; then mkdir default_inputs; fi( cd default_inputs; $(NL_GEN) ../Registry_processed.xml namelist.atmosphere in_defaults=true )( cd default_inputs; $(ST_GEN) ../Registry_processed.xml streams.atmosphere stream_list.atmosphere. listed in_defaults=true)I'm inferring that this means that the processed Registry is what is being used to generate these files. This comes from a directive just above that one in the Makefile:
core_reg:$(CPP) $(CPPFLAGS) $(CPPINCLUDES) $(PHYSICS) Registry.xml > Registry_processed.xmlThis gets triggered by the src/Makefile dycore target, which itself is called by the mpas target, which itself is called by the all target. I'm wondering if the Registry.xml that this directive is operating on for some reason only contains the aerosol-related portion of the Registry?
I was able to confirm that compiling the last hash before the initial SMOKE submodule implementation (9ce949e, v8.3.0-1.17) generates the correct stream_list.atmosphere.output based on the full model Registry.xml but that compiling the hash associated with the initial SMOKE submodule implementation (3cb859c, v8.3.0-2.0) does not. @haiqinli and @jordanschnell - could one of you please look into this?