Strange block pattern in T, PBLH when using chem_opt=202

[Krishna Kedia]

Hi all,

I am observing a strange block like pattern in my radiation variables like LWUPT and consequently similar block pattern in T and PBLH fields (screenshots attached). The finer grid pattern in LWUPT_box_error image corresponds to the nested domain.

I am using MOZART-MOSAIC 4-bin with Aq Phase Chem (chem_opt=202) (namelist attached) with NCEP FNL meteorology, CAMS-Global Anthropogenic and FINN2.5 fire emissions for domain over Europe. 

Similar error is not observed when the same setup is run with met only which implies something on the chemistry side of things is altering the radiation variables. 

Any insights on what could be going wrong will be greatly appreciated.

Thanking you

Krishna Kedia

PhD student

University of Hertfordshire, UK

[Gabriele Pfister]

Hi Krishna

this is strange and I wonder if there is some sort of memory issue. Have you tried running with one domain only? Which model version are you using?

Gabi

--

================================
Gabriele Pfister

Atmospheric Chemistry Observations & Modeling (ACOM) Lab

NSF National Center for Atmospheric Research (NCAR)

Email: pfi...@ucar.edu

Work Phone: +1 303 497 2915

Web: https://staff.ucar.edu/users/pfister

[Krishna Kedia]

Hi Gabi, 

I have tried multiple versions of WRF-Chem and using only 1 domain as well but it is unlikely to be a memory or version related issue. However, I suspect it could be related to this one modification I made as described below:

When I run WRF-Chem without any modifications to the source code and with the namelist attached previously, I encounter a segmentation fault at the real.exe stage itself with the traceback specifying the following error message (rsl.error.0000 attached): 
#3  0x2683319 in __module_input_chem_data_MOD_make_chem_profile
        at /beegfs/cair/kk21acq/wrfchem_new/WRF/chem/module_input_chem_data.f90:847

Based on a previous discussion in this forum (https://groups.google.com/a/ucar.edu/g/wrf-chem/c/m9xmwfl_iwY/m/HaPWPHLVAgAJ) the fault seems to be related to no profile mapping being defined for chem_opt=202 as is evident from the lines 391-392 in module_input_chem_data.F: 
case (MOZART_MOSAIC_4BIN_AQ_KPP)
     call wrf_debug("setup_profile_maps: nothing done for mozart_mosaic_4bin_aq_kpp")

To avoid encountering this fault I made the following changes to module_input_chem_data.F based on the same discussion thread (modified module_input_chem_data.F attached):

798     iref(:)    = 7 !default value 

799     iref(1:41) = (/12,19,2,2,1,3,4,9,8,5,5,32,6,6,6,30,30,10,26,13,11,6,6, &

800                  14,15,15,23,23,32,16,23,31,17,23,23,23,23,23,7,28,29/)

   

While the above changes result in resolution of segmentation fault and model simulation starts smoothly, I suspect that this modification could somehow be the cause of the block type pattern I am observing. Another reason to suspect this is when I try the RACM2 mechanism (chem_opt=109) with the above modifications in place, I do not observe the block type patterns anymore. 

Thus, I was wondering if there is a way to avoid segmentation faults due without making the above modifications to module_input_chem_data.F or if the modifications made need to be altered to suit the 202 chemistry option.

Thank you
Krishna

[Gabriele Pfister]

Hello Krishna

I am not sure why you had to make that change and I have never encountered the issue. I assume you the chemical IC and BC are specified in your wrfinput and wrfbdy? 

I looked at your modified subroutine but looking at the line numbers you refer to, this is what I have: 

Could you please clarify where you made the change? 

I also suggest changing debug_level in your namelist to a larger value (at least 12), maybe the rsl files include more information then about what happens. 

Gabi

[Krishna Kedia]

Hi Gabi,

I follow these steps to perform a WRF-Chem simulation (without making any changes to the source code):

1. Run real.exe with chem_opt = 0

2. Run anthro_emis to produce wrfchemi* files (using CAMS-GLOBAL Anthropogenic emissions)

3. Run fire_emis to produce wrffire* files (using FINNv2.5 fire emissions)

4. Run bio_emis to produce wrfbio* files (based on MEGAN)

5. Run wesely and exo_coldens to produce wrf_season* and exo_coldens_* files

6. Set chem_opt = 202 and run real.exe

At this stage I encounter the segmentation fault. As suggested, I ran it with debug_level = 12 and it shows the message: 

"At line 847 of file module_input_chem_data.f90
Fortran runtime error: Index '0' of dimension 4 of array 'stor' below lower bound of 1"

I have attached the rsl.error.0000 file for complete error and backtrace messages.

I then make the following changes to module_input_chem_data.F (correct file with changes made at line 798 attached) and clean and recompile the model.

After the above changes, I do not encounter the segmentation fault and error messages at step 6 and real.exe finishes smoothly. I then set the initial and boundary conditions using mozbc utility and run wrf.exe.

The model simulation starts smoothly too however, I encounter the strange block pattern beginning from the first output file.

I think the array stor needs to be looked at further and adjusted to avoid the error but I could be wrong. Any suggestions to resolve this would be of great help!

Thank you

Krishna

[Gabriele Pfister]

Hello Krishna

is there a specific reason why you use idealized chemical IC and BC rather than from a global model? If not, here is what I would suggest: 

- run real.exe without chemistry 

- use mozbc to add chemical IC and BC to your wrfinput and wrfbdy (see our tools page)

- run wrf.exe with chemistry

Gabi

[Krishna Kedia]

Hi Gabi,

Thanks a lot for your suggestion. I was inadvertently asking the model to use IC BC from idealised profiles when I was running real.exe after setting the chemistry option and thus encountering the segmentation fault. Skipping that step and setting ICBC using the global model and then running wrf.exe with the desired chemistry option resulted in the simulation starting smoothly without having to make any changes to model code. Thanks again for your help.

Krishna