WRF v4.5.1 auxinput15 external AOD always read as zero (aer_opt=2)

[Yue Meng]

Hello,

I am using WRF-ARW v4.5.1 (non-WRF-Chem) with RRTMG radiation and trying to prescribe external aerosol optical depth (AOD) via auxinput15:
aer_opt = 2
aer_aod550_opt = 2
aer_angexp_opt = 3,
aer_ssa_opt = 3,
aer_asy_opt = 3,
aer_type = 1,
ra_sw_physics = 4
ra_lw_physics = 4

Auxinput settings:
io_form_auxinput15 = 2
auxinput15_inname = "wrfaerinp_d<domain>_<date>"
auxinput15_interval = 60
frames_per_auxinput15 = 1

The auxinput15 files (e.g. wrfaerinp_d01_YYYY-MM-DD_HH:00:00) contain non-zero AOD5502D / TAOD5502D, with correct grid size and valid Times. This is verified by ncdump and Python.

At runtime, WRF opens the files successfully, but always reports:
aer_aod550_opt=2: AOD@550 nm read from auxinput (min= 0.000 max= 0.000)
As a result, SWDOWN and T2 are bitwise identical between baseline and strongly perturbed AOD experiments.

Question:

• Is external AOD via auxinput15 actually supported in standard WRF-ARW, or is this functionality only intended to work fully in WRF-Chem?
• Are additional variables required in auxinput15 beyond AOD5502D / TAOD5502D?

Thanks in advance for any clarification.

 

[kwerner]

Hi, This option should work with standard WRF-ARW. Do you mind attaching your full namelist.input file, as well as your error/out log(s)? If you have multiple rsl.* files, package them into a single .tar or zipped file and attach here. Thanks!

 

[Yue Meng]

Thanks for the reply!

I will attach:

• the full namelist.input,
• the rsl.out.* and rsl.error.* logs,
• and one example wrfaerinp_d01_2015-05-21_01:00:00 file.

I hope this helps identify whether there is any issue with the auxinput15 format or metadata. I am including the wrfaerinp file because WRF reports that it successfully opens the auxinput15 stream, but the logged AOD values are always zero, even though the file itself contains non-zero AOD.

I also found a previous WRF forum post (see here) describing exactly the same behavior (the auxinput15 file is opened, but the AOD is read as zero). The issue in that post was eventually resolved, but the solution was not described.

 

[kwerner]

Thanks for attaching those. The rsl* files you attached don't show the prints you mentioned (aer_aod550_opt=2: AOD@550 nm read from auxinput (min= 0.000 max= 0.000)). Were you seeing that message in your rsl* files previously? the rsl* files also show that the simulation didn't complete. Does this simulation actually run to completion? If not, you should try using more processors and see if that makes any difference. Try using something like 64 processors. If that fails, package all of the rsl* files into a single *.tar or zipped file and attach that.

 

[Yue Meng]

Hi Kwerner,


Thanks for your reply and suggestions.

I have re-run the full 2-day simulation to completion using 32 MPI tasks (which is the maximum available to me). The rsl.out.0000 file now clearly shows repeated messages such as:‘aer_aod550_opt=2: AOD@550 nm read from auxinput (min=0.000 max=0.000)’ appearing throughout the integration (dozens of times).
This behavior persists even though ncdump confirms that AOD5502D / TAOD5502D in the auxinput15 files contain non-zero values.

Due to the WRF forum attachment size limit, I am only able to attach the rsl.out.0000 and rsl.error.0000 files here. Please let me know if any additional information would be helpful.


Best regards,
Yue

 

[kwerner]

Yue,
Thanks for trying that and for sharing those rsl files. It's unclear to me why this is happening and I'd like to test it out, myself. Do you mind sharing the files I would need to run wrf (wrfbdy_d01, wrfaerinp_d01, wrfinput_d01)? As you know, those files will be too large to attach here, so see the home page of this forum for instructions on sharing large files. Thanks!

 

[Yue Meng]

Hi Kwerner,

Thanks very much for taking a look at this and for offering to test it on your side.

I’ve uploaded the required files (wrfbdy_d01, wrfinput_d01, wrfaerinp_d01*) as a single archive named Yue_wrf.zip to the Box storage. Please let me know if you have any trouble accessing the file or if additional information is needed.

Thanks again for your help.

Best wishes,
Yue

 

[kwerner]

Hi Yue,
Just letting you know I haven't forgotten about you. I'm having trouble getting it to run at all on my system. I keep getting a message that it's not able to find the right time in the file wrfaerinp_d01 at the "01" hour. It seems like the model is looking for all the times to be in a single file. I'm still working to figure it out, but wanted to ask if you experienced any similar issues when running, and if so, did you have to do something, in particular, to get past that?

 

[Yue Meng]

Hi Yue,
Just letting you know I haven't forgotten about you. I'm having trouble getting it to run at all on my system. I keep getting a message that it's not able to find the right time in the file wrfaerinp_d01 at the "01" hour. It seems like the model is looking for all the times to be in a single file. I'm still working to figure it out, but wanted to ask if you experienced any similar issues when running, and if so, did you have to do something, in particular, to get past that?

Hi Kwerner,

Thanks for the update — that is very helpful.

Yes, in my case the auxinput15 files are organized as one file per time, e.g.:
wrfaerinp_d01_2015-05-21_00:00:00,
wrfaerinp_d01_2015-05-21_01:00:00, etc., each with Time = 1.

I did not see a fatal error about missing the 01:00 time, but I am using "force_use_old_data = .true." in namelist.input, which may be allowing the run to proceed even if the time matching for auxinput15 is not fully successful.

Given your observation, I suspect that WRF may actually expect all auxinput15 times to be stored in a single NetCDF file with an unlimited Time dimension, rather than split across multiple files. This could explain why the files are opened, but the AOD values are read as zero in my runs.

I have not yet tried merging all times into a single auxinput15 file, but I can attempt this if you think that is the intended workflow.

Thanks again for looking into this.

Best wishes,
Yue