Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

Plumerise bug

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

neel14

Member
Hi,
There is a possible bug with biomass_burn_opt=2 when used with chem_opt=202, It gives very high sulfate concentrations near model top above active biomass burning locations. This is present in 4.1.3 and 4.2.1 (other versions I haven't checked).
On turning off biomass burning emissions, the high concentrations vanishes.
Would like suggestions to solve this problem.

Thanks.
 
Hi,

Are you seeing elevated concentrations of any other species? The plumerise calculations should operate/transport all species the same way. To me that suggests a problem with chemistry or the emissions.

Can you verify the magnitude of your SO2 fire emissions is within a reasonable value?
Is this problem occurring in the presence of clouds? (try setting cldchem_onoff = 0)

Jordan
 
Hi,
I am not seeing elevated conc. in any other species except sulfate. I have attached the so2 emission outputs and sulfate concentration near model top.
I am using the finn emissions with 1:1 mapping for so2,not making any modifications. Even so I think only sulfate plume reaching 13-14 km above msl, there's some issue. Some users using v3.9.1.1 are reporting of not having this issue, so it may be applicable to >= v4.0. These plumes are starting from around 1.2 km, nothing below that to about 14 km, I wonder if such big plumes are possible.

This issue is probably leading to another issue, I get very high sw optical depth warning above the high sulfate locations when biomass_burn_opt=2 is used. This issue and the above issue is there even with chem_opt=201, where cloud chem is not used,so I don't think this is a cloudchem issue. I have checked so4_cw0* variables, they are 0 at similar levels(Attachment)

Neeldip
 

Attachments

  • so2.PNG
    so2.PNG
    90.1 KB · Views: 4,389
  • so4.PNG
    so4.PNG
    108.1 KB · Views: 4,389
  • s04_cw02.PNG
    s04_cw02.PNG
    79 KB · Views: 4,389
Very interesting - I assume the other sulfate bins are also elevated?

I've looked at the routines that add biomass burning emissions for Mosaic (module_mosaic_addemiss.F), and may have found something -

In the fire select loop, this is defined: aem_so4 = bburn_mosaic_f(n)*ebu(i,k,j,p_ebu_sulf)
However, "sulf" is not a defined fire emission for BIOMASSB_MOZC in registry.chem, so who knows what this is getting set to. Indeed, no sulfate emissions are defined, just SO2. I think the easiest thing to try is to set aem_so4 = 0, similarly to how aem_nh4, aem_na, aem_cl, etc are set and recompile. You can put a print statement that writes out the value is was being set to before you set it to zero so we can see if this is the issue.

If your fire emissions contain a field for ebu_in_sulf, you can also try this:
1. Add ebu_in_sulf, and ebu_sulf to registry.chem under the biomass_burn_opt==2 package.
2. In module_plumerise1.F, add a line to add the sulf ebu_in to the ebu array.
3. ./clean -a and recompile

Jordan
 
jordanschnell said:
Very interesting - I assume the other sulfate bins are also elevated?

There's some amount of *a03 but a01 and a04 are negligible.

jordanschnell said:
In the fire select loop, this is defined: aem_so4 = bburn_mosaic_f(n)*ebu(i,k,j,p_ebu_sulf)
However, "sulf" is not a defined fire emission for BIOMASSB_MOZC in registry.chem, so who knows what this is getting set to. Indeed, no sulfate emissions are defined, just SO2. I think the easiest thing to try is to set aem_so4 = 0, similarly to how aem_nh4, aem_na, aem_cl, etc are set and recompile. You can put a print statement that writes out the value is was being set to before you set it to zero so we can see if this is the issue.

If your fire emissions contain a field for ebu_in_sulf, you can also try this:
1. Add ebu_in_sulf, and ebu_sulf to registry.chem under the biomass_burn_opt==2 package.
2. In module_plumerise1.F, add a line to add the sulf ebu_in to the ebu array.
3. ./clean -a and recompile

I will try and let you know.

Neeldip
 

Attachments

  • s04_a03.PNG
    s04_a03.PNG
    106.3 KB · Views: 4,366
Hi,
The test seem to be a success. I am not getting either the elevated concentration nor the large sw optical warning now.
I had set aem_so4 = 0.
I also had added a print option, but from rsl.out.0000 file all aem_so4 values are 0 :shock: Don't know whats going on.

Thanks a lot for your help :)

rsl.out.* files are very big. I can upload that if you want.
 

Attachments

  • so4_a02.PNG
    so4_a02.PNG
    86.5 KB · Views: 4,358
Hi Neeldip,

Great to hear that this is working - It's likely aem_so4 is all zero in rsl.out.0000 because there are no bb emissions on that tile (i.e., how WRF decomposes the domain). Can you please do a grep on all of the rsl.out.* files to see if this was the issue? If so, I'd like to submit a pull request to get this fixed for the next release. Thank you!

Jordan
 
Hi Jordan,
There are non zero values for aem_so4 in other tiles. I have attached the grep output for search string "1".
rsl.out.* files are around 120 gb, hence can't output for all non-zero strings.
I wonder where these values are coming from. Would be interesting to know. Please let me know if you find out.
Also do let me know if you need any more info.

Best
Neeldip
 

Attachments

  • 1.txt
    46.4 MB · Views: 71
Hi,

I was wondering if this bug has been addressed yet via git pull as mentioned by Jordan?
I am getting a similar error and similar warning with version 4.1 and biomass burn opt =2 and I wonder if I can recompile using the fixed code?
Alternatively, what would be the best way to fix this bug?
Can anybody advise, please?

Thanks a lot,
Lin
 
Hi all,

I'm going to double check with some folks that are mozart/mosaic code developers to make sure this fix is correct as it may be desired to have sulfate emissions. That said, in the preparation of your fire emissions, for what species are the ebu_in* fields generated?

@neeldip - as for where the values are coming from, you can try printing the value p_ebu_in_sulf and p_ebu_sulf, but the are likely = 1, and the ebu array should be initialized to zero before being filled with pointers > 1. Not positive though.

@linlu, for now it seems that you can just set aem_so4 = 0 in the biomass burning block to avoid the issue. I'll comment again soon with updates/plans.

Jordan
 
jordanschnell said:
for what species are the ebu_in* fields generated?

For me,these:

co,no,so2,bigalk,bigene,c2h4,c2h5oh,c2h6,c3h8,c3h6,ch2o,ch3cho,ch3coch3,ch3oh,mek,toluene,nh3,no2,open,c10h16,gly,acetol,isop,macr,mvk,ch3cooh,cres,glyald,mgly,oc,bc,pm25,pm10
 
Hi Jordan,

I am using version 4.2 and I have also tested versions 4.1 and 3.9.1. I am experiencing the same error as Lin and Neeldip for chem 201.
I get 'large total sw optical depth' warnings over certain locations in my domain and I get large so4_a04 plumes starting at level 19 and going up to the model top.
Additionally, I followed both the debug options you suggested, recompiled the model and none of them seemed to solve the error for me.
However, I do not get such warnings and plumes when I use the MOZART-4 data for boundary and initial conditions. I only get this error when I use CAM-chem data for IC and BC.

Could you please suggest any possible debugging options for this error or any update from the developers? I would like to use CAM Chem data for my simulation.

Best, Prerita
 
Hi Prerita,

I've spoken with the developers and it seems sulf biomass burning emissions are not meant to be included in biomass_burn_opt = 2, but the mosaic add_emiss routines are expecting it. It is interesting that you get different results with different IC/BCs, especially since it doesn't seem to be occurring at the boundaries (are the plumes in the input file?)

So you tried the option in setting aem_so4 = 0?

Optionally, you can just change this line in module_mosaic_add_emiss.F (NOT the .f90 file), from this:

aem_so4 = bburn_mosaic_f(n)*ebu(i,k,j,p_ebu_sulf)

To this:

IF ( p_ebu_sulf .gt. 1) aem_so4 = bburn_mosaic_f(n)*ebu(i,k,j,p_ebu_sulf)

And recompile.

Jordan
 
Hi Jordan,

Thanks for your reply.

Yes, I changed aem_so4 in module_mosaic_addemiss.F and set it to = 0.0
I also tested your previous suggestion - Adding the ebu_in_sulf, and ebu_sulf to registry.chem under the biomass_burn_opt==2 package and adding a line to add the sulf ebu_in to the ebu array in module_plumerise1.F. But these two didn't solve the issue.

I now modified the module_mosaic_addemiss.F code as you suggested in your latest post for aem_so4.
I'm afraid this didn't change anything either. To confirm I attach here the snippet of the code I modified and then recompiled (V4.2). Does this seem okay?
I also attach the visual of so4_ao4 concentration near the model top at two levels.

Thanks, Prerita
 

Attachments

  • module_mosaic_addemiss.F.png
    module_mosaic_addemiss.F.png
    47.5 KB · Views: 4,017
  • SO4_ao4_23.PNG
    SO4_ao4_23.PNG
    66.9 KB · Views: 4,015
  • SO4_ao4_25.PNG
    SO4_ao4_25.PNG
    64.7 KB · Views: 4,015
HI Prerita,

That is troubling - Just to make sure, after you change the registry, you need to do a "./clean -a" and then recompile. If you only change a .F, then you don't need to do a clean. However, if it is not fixed with you setting aem_so4 = 0, then I don't think this is the same issue that @neel14 was experiencing.

Does the CAM-Chem data look suspicious in any way for so4/so2?
Does the problem occur when you turn off bb emissions?
After you made the Registry change is ebu_in_sulf in the wrfinput_d01 file all zeros?

Jordan
 
Hi Jordan,

Thanks for the response.
Indeed I did a ./clean -a after making changes in the registry and before recompiling.
To confirm the questions you asked about input/ouput-
The CAM-Chem data looks fine for so4/so2.
The same issue exists when I turn off the bb emissions (i.e. setting biomass_burn_opt = 0).
ebu_in_sulf in the wrfinput file is zero.

I also see the similar SO4 plumes in wrfinput_d01 file when I use CAM-Chem data for providing IC BC.

I wonder if there is anything wrong in my set-up and/or input files. Can I share the namelist and emission inp files here for you to take a look if you think there might be some error in those and hence the cause of bug?

I am continuing my runs with MOZART-4 data for now.
Please do update/suggest any further points you come across.

Best, Prerita
 
Hi Prerita,

You said "the CAM-Chem data looks fine for so4/so2" but that "I also see the similar SO4 plumes in wrfinput_d01 file when I use CAM-Chem data for providing IC BC." Do you mean the raw CAM-Chem data looks fine but the wrfinput_d01 file has issues when processing the CAM-Chem data? If that's the case, what are you using to ingest the CAM-Chem data into wrfinput_d01 -- real.exe?

Feel free to share any files here or via google drive.

Jordan
 
Hi Jordan,

Do you mean the raw CAM-Chem data looks fine but the wrfinput_d01 file has issues when processing the CAM-Chem data?

Yes. The raw CAM Chem data looks fine and wrfinput file shows the erroneous so4_a04 plumes near the model top.

I use mozbc to ingest CAM chem data for IC and BC. I also attach here the CAM-Chem.inp, fire.inp and my namelist.input files.

Please let me if you spot anything that doesn't look right.


Thanks,
Prerita
 

Attachments

  • CAM_CHEM_inp.txt
    3.3 KB · Views: 40
  • namelis (1).input
    7.5 KB · Views: 33
  • fire_inp.txt
    875 bytes · Views: 30
Hi Prerita,

I don't see anything obvious, but I am not familiar with the details of mozbc. The equation for so4_a04 doesn't look to have issues and since it is showing up at elevated levels in the wrfinput file, my first guess would be that it is related to interpolation, but it doesn't show up for other species so that is probably not the case. Is there an output file from mozbc?

Jordan
 
Hi Jordan,

Mozbc maps space and time-varying species concentrations from input data (Mozart/CAM-Chem) datasets to WRF concentrations for initial condition and boundary conditions. I believe mozbc utility interpolates the input datasets in space (bilinearly in longitude, longitude and linearly in pressure), but not in time onto the initial condition file and boundary conditions from the real.exe generated files.

Best, Prerita
 
Top