Adding variables to registry.chem in WRF-Chem v4.4.1 caused unreasonable simulation results

[schu21]

Hello,

I am trying to add some variables to chem array for a specific chemical package (chem_opt=132) using WRF-Chem v4.4.1. The issue is that when I add more variables the simulated meteoroloy (T2, U10, V10) become unreasonable (see attached figures: add all variables that I need; without adding variables; add part of the variables that I need). Many other output are also changed. All the simulations can finish without any error in the rsl files (see attached namelist.input).

The strage thing is that this issue did NOT come out when I tried the same way in WRF-Chem v3.7.1. I am wondering if this issue is related to any change in the new model version? How the modification of registry cause such great impact on the simulation results? Is there any way to idendity the reason for this issue?

Here is an exapmle for the modification of the registry.chem that I made:

state real lvsog ikjftb chem 1 - i0{12}rhusdf=(bdy_interp:dt) "lvsog" "LV SOG" "ppmv"
package cb05_sorg_vbs_aq_kpp chem_opt==132 - chem:no2,no,o,o3,...,lvsog


Any help would be greatly appreciated!

Suqian

 

[jordanschnell]

Hi Suqian,

Are you saying that you get these differences with ONLY changes to the registry and no other code changes?

Also, note that the location in the package also matters due to how aerosols and gases are separated (see the subrouitine get_last_gas in module_chem_share.F). Basically, if you add a gas, it needs to come before nh3 (for chem_opt = 132).

Jordan

 

[schu21]

Hi Suqian,

Are you saying that you get these differences with ONLY changes to the registry and no other code changes?

Also, note that the location in the package also matters due to how aerosols and gases are separated (see the subrouitine get_last_gas in module_chem_share.F). Basically, if you add a gas, it needs to come before nh3 (for chem_opt = 132).

Jordan

Hi Jordan,

Thanks for your quick reply!

(1) Yes I got these differences with ONLY changes to the registry and no other code changes.

(2) Thanks for reminding the location for the variables. Could you please expalin what is the physical reason behind this rule? Does the rule of adding the gas before nh3 only work for chem_opt=132 or also the other options (e.g. 131)?

(3) I think the modication of registry.chem should be fine because it did work for the version 3.7.1. Otherwise, how to expalin the different situations between the different version?

Suqian

 

[schu21]

Hi Suqian,

Are you saying that you get these differences with ONLY changes to the registry and no other code changes?

Also, note that the location in the package also matters due to how aerosols and gases are separated (see the subrouitine get_last_gas in module_chem_share.F). Basically, if you add a gas, it needs to come before nh3 (for chem_opt = 132).

Jordan

Hi Jordan,

I tried to move the gas before nh3 and it still did not work. I also tested other versions and the differences (with ONLY changes to the registry and no other code changes) also exist in WRF-Chem v4.0 and 4.4.2 but not in v3.7.1 and v3.9.1

It seems that this issue only exist in version 4 but not exist in version 3. Do you have any idea what have caused this difference? Is there any way, or anyone can help to idendity the reason for this issue?

Look forward to your reply!

Thanks,
Suqian

 

[jordanschnell]

Hi Suqian,

Please send me your original and modified registry file(s).

Likely you are producing way to much of an aerosol, which is then modifying your met fields through aer_ra_feedback.

Jordan

 

[schu21]

Hi Jordan,

Thanks for your reply! I have attached the original and modified registry.chem files. Both are txt files otherwise I couldn`t upload them.

I turn on aer_ra_feedback because I need to look at the aerosol-cloud interaction, and I am using aer_op_opt = 3 to avoid the huge rsl.out files. The other simulation results (e.g. gas concentrations of SO2, NH3, ...) were also changed but this might be caused by the change in meteorology such as wind.

Could you please explain about "producing way to much of an aerosol"? Do you mean I am adding too many variables to the chem array?

Thanks,
Suqian

Hi Suqian,

Please send me your original and modified registry file(s).

Likely you are producing way to much of an aerosol, which is then modifying your met fields through aer_ra_feedback.

Jordan

 

[schu21]

Hi Suqian,

Please send me your original and modified registry file(s).

Likely you are producing way to much of an aerosol, which is then modifying your met fields through aer_ra_feedback.

Jordan

Hi Jordan,

Just update the simulation results with other chemistry options for your convenience.

The additional variables were added to registry.chem for the package of chem_opt=131 and chem_opt=2, and the simulations were run with the corresponding chem_opt, respectively. The results with chem_opt=131 are similar to those with chem_opt=132, which are not reasonable after modifying registry.chem. While the results with chem_opt=2 does not have this issue.

I am not sure why this issue only happend to some certain chemical mechanisms in WRF-Chem v4+. Please let me know if you have any idea about it.

Thanks,
Suqian

 

[schu21]

Hi Suqian,

Please send me your original and modified registry file(s).

Likely you are producing way to much of an aerosol, which is then modifying your met fields through aer_ra_feedback.

Jordan

Hi Jordan,

Have you had a chance to test the registry.chem files? It would be great if you could provide me with a update on this issue.

Thanks,
Suqian

 

[jordanschnell]

Hi Siquan,

Currently you have 4 different packages defined for chem_opt = 132. You need to delete the apm_* packages or put them as a unique number, then "./clean -a" and recompile.

Jordan

 

[schu21]

Hi Siquan,

Currently you have 4 different packages defined for chem_opt = 132. You need to delete the apm_* packages or put them as a unique number, then "./clean -a" and recompile.

Jordan

Hi Jordan,

Thanks for your reply! I tried to only keep the additional variables in chem array for chem_opt=132 but it did not work. Have you tested the model with my registry.chem file? If yes, did you get the same issue?

As is mentioned in my previous replies, adding the self-defined variables to the package of chem_opt=131 also had the same issue as chem_opt=132, which did not exist in chem_opt=2. This only happened in WRF-Chem v4+ but in v3. Based on the testing results, my guess is that this issue could be related to some changes from v3 to v4.

I would greatly appreciated it if you or anyone could help with the two key questions for my issue:
(1) Why and how adding variables to registry.chem without any other change have caused the unrealistic meteorology? You mentioned that it could be aer_ra_feedback, but I am confused about the process that how registry.chem made the change to the simulation.
(2) Why this issue happen for chem_opt=132 and 131 in v4?

Thank you,

Best regards,
Suqian

 

[jordanschnell]

Hi Siquan,
With how you have the registry, I can't be sure that it will work as I don't know how the model will attempt to allocate the memory with multiple chem_opt=132 packages defined. My suggestion is to put the new variables ONLY inside the existing chem_opt = 132 package. You said it "didn't work" when you tried this - does that mean a failed simulation or failed compile? It should look something like:


package cb05_sorg_vbs_aq_kpp chem_opt==132 - chem:no2, ..., nh4apmcw; tempout:tpout01,... ; transvar:trvar01,...,trvar10; apmsize:apmsz01, ..., apmsz36

(1) If your simulated aerosol field is very different and you have aer_ra_feedback on, your meteorological simulations will be different. Compare PM2_5_DRY between the simulations. I can't be sure your registry changes are not causing problems elsewhere. Please follow the guidance above. You could also just set aer_ra_feedback = 0 to see if the meteorological changes persist.
(2) I don't know. You can compare the code for those mechanisms between the versions, but I would not go down that rabbit-hole until you can guarantee your registry changes are not impacting the code.

Jordan

 

[schu21]

Hi Siquan,
With how you have the registry, I can't be sure that it will work as I don't know how the model will attempt to allocate the memory with multiple chem_opt=132 packages defined. My suggestion is to put the new variables ONLY inside the existing chem_opt = 132 package. You said it "didn't work" when you tried this - does that mean a failed simulation or failed compile? It should look something like:


package cb05_sorg_vbs_aq_kpp chem_opt==132 - chem:no2, ..., nh4apmcw; tempout:tpout01,... ; transvar:trvar01,...,trvar10; apmsize:apmsz01, ..., apmsz36

(1) If your simulated aerosol field is very different and you have aer_ra_feedback on, your meteorological simulations will be different. Compare PM2_5_DRY between the simulations. I can't be sure your registry changes are not causing problems elsewhere. Please follow the guidance above. You could also just set aer_ra_feedback = 0 to see if the meteorological changes persist.
(2) I don't know. You can compare the code for those mechanisms between the versions, but I would not go down that rabbit-hole until you can guarantee your registry changes are not impacting the code.

Jordan

Hi Jordan@jordanschnell

I appreciate your suggestions. I just corrected my previous reply.

(1) "didn't work" in my previous reply means a failed simulation, that is, the meteorology becomes unrealitic after only adding variables in regitry.chem. What I did is keeping one package for chem_opt=132:

package cb05_sorg_vbs_aq_kpp chem_opt==132 - chem:no2, ..., nh4apmcw;

and removing others (the corresponding state lines were also removed). In this way, I can just test a portion of the additional variables and make it simpler...

(2) I tried to put all the new variables ONLY inside the existing chem_opt = 132 package, the issue on unreasonable meteorology still exist.

(3) I tried to turn off aerosol-radiation interactions (aer_ra_feedback=0) and the issue on unreasonable meteorology still exist.

(4) Attached figures are PM2_5_DRY from the simulation using modified registry.chem with ARI turned on or off. They are actually pretty close.

As I mentioned in previous posts, I have tried all the model versions and none of version 4 worked if I add variables to chem array in the registry.chem. I also tried to not add the new variables to chem array but this did not make sense, since the size of the chem array in the registry.chem would change the parameter "num_chem" which is used to run the model. That is to say, the variables that the chem array contains not only change the model output but also change the simulation process. Therefore, I have to make sure the basic results (e.g. meteorology) with the modified registry are reasonable before making any further modification of the code. I am wondering what method I can try to find out what have caused the problem?

Thank you,
Suqian