lightning broken in WRF Chem after v4.0

[davegill]

In the Registry.EM_COMMON, the lightning method option (ICCG_METHOD) was put into the source in the physics directory almost 7 years ago by Jimy:

c83d404d9 Registry/Registry.EM_COMMON (Jimy Dudhia      2013-01-25 23:38:03 +0000 2904) rconfig  integer    iccg_method              namelist,physics   max_domains    0       -   "iccg_method"               "IC:CG partitioning method" 

In registry.chem, the lightning method option (ICCG_METHOD) was put into the source in the chem directory 10 years ago by Steve Peckham:

b3ef563ff (Steven Peckham 2009-11-20 23:24:26 +0000 3767) rconfig   integer     iccg_method         namelist,chem        max_domains        1       rh      "iccg_method"        ""    ""

So, this has ALWAYS been wrong (we should not have two locations for the namelist definition of the variables). What has changed is that Registry.EM and Registry.EM_CHEM were modified to use a new file: registry.em_shared_collection. This new file reorganized the order of the registry files that were included into what becomes the master registry from which WRF is built.

What we need to do is decide which way we want to support this option. I would vote for Registry.EM_COMMON and the physics namelist, if we would likely run into build troubles without the use of WRF Chem. However, if iccg_method is ENTIRELY and ONLY EVER run when chemistry is active, then I vote for keeping this option declaration only in registry.chem in the chem namelist record.

It looks like there are additional namelist options associated with ICCG_METHOD (ICCG_PRESCRIBED_NUM and ICCG_PRESCRIBED_DEN) and a couple of 2d arrays associated with ICCG_METHOD (ICCG_IN_NUM and ICCG_IN_DEN). Since these other ICCG* variables are ONLY in the Registry.EM_COMMON, that should be part of our calculus.

Per Mary Barth:

In my opinion, the namelist variables associated with calculating lightning flashes (iccg_method, lightning_start_seconds, etc, etc) should be in the &physics section.

There are some papers that do just use WRF and run lightning diagnostics to analyze storm parameter - lightning correlations. And there are other papers that use the lightning diagnostics to get lightning-NOx in the chemistry. However, since there is a lot of tuning with this latter effort, it is common for the modeler to set chem_opt=0 and tune the lightning predictions to something close to observations. So, even before calculating the NOx emissions, there are several runs with just testing the lightning.

I also think the namelist variables associated with calculating lightning flashes should be in only one place, ensuring consistency no matter how WRF or WRF-Chem is run.

[dudhia]

I also vote for physics if it can be used without Chem, Jimy

On Tue, Nov 26, 2019 at 7:39 AM Dave Gill notifications@github.com wrote:

In the Registry.EM_COMMON, the lightning method option (ICCG_METHOD) was put into the source in the physics directory almost 7 years ago by Jimy:

c83d404d9 Registry/Registry.EM_COMMON (Jimy Dudhia 2013-01-25 23:38:03 +0000 2904) rconfig integer iccg_method namelist,physics max_domains 0 - "iccg_method" "IC:CG partitioning method"

In registry.chem, the lightning method option (ICCG_METHOD) was put into the source in the chem directory 10 years ago by Steve Peckham:

b3ef563ff (Steven Peckham 2009-11-20 23:24:26 +0000 3767) rconfig integer iccg_method namelist,chem max_domains 1 rh "iccg_method" "" ""

So, this has ALWAYS been wrong (we should not have two locations for the namelist definition of the variables). What has changed is that Registry.EM and Registry.EM_CHEM were modified to use a new file: registry.em_shared_collection. This new file reorganized the order of the registry files that were included into what becomes the master registry from which WRF is built.

What we need to do is decide which way we want to support this option. I would vote for Registry.EM_COMMON and the physics namelist, if we would likely run into build troubles without the use of WRF Chem. However, if iccg_method is ENTIRELY and ONLY EVER run when chemistry is active, then I vote for keeping this option declaration only in registry.chem in the chem namelist record.

It looks like there are additional namelist options associated with ICCG_METHOD (ICCG_PRESCRIBED_NUM and ICCG_PRESCRIBED_DEN) and a couple of 2d arrays associated with ICCG_METHOD (ICCG_IN_NUM and ICCG_IN_DEN). Since these other ICCG* variables are ONLY in the Registry.EM_COMMON, that should be part of our calculus.

Per Mary Barth:

In my opinion, the namelist variables associated with calculating lightning flashes (iccg_method, lightning_start_seconds, etc, etc) should be in the &physics section.

There are some papers that do just use WRF and run lightning diagnostics to analyze storm parameter - lightning correlations. And there are other papers that use the lightning diagnostics to get lightning-NOx in the chemistry. However, since there is a lot of tuning with this latter effort, it is common for the modeler to set chem_opt=0 and tune the lightning predictions to something close to observations. So, even before calculating the NOx emissions, there are several runs with just testing the lightning.

I also think the namelist variables associated with calculating lightning flashes should be in only one place, ensuring consistency no matter how WRF or WRF-Chem is run.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/wrf-model/WRF/issues/1021?email_source=notifications&email_token=AEIZ77HCT2ZOFSLBDAJSQNLQVRO2JA5CNFSM4JRQH7LKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H36YGAA, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIZ77BO3N2F2LOSXRHONQLQVRO2JANCNFSM4JRQH7LA .

[zxdawn]

@davegill This is my suggestion:

As mentioned by Mary, these should be put into &physics:

lightning_option
iccg_method
iccg_prescribed_num
iccg_prescribed_den
cldtop_adjustment
lightning_dt   
lightning_start_seconds 
flashrate_factor
cell_count_method

And other options should be kept in &chem. That is the method we always use for simulating lightning. It's illustrated at Page 65 - 68 in the User Guide of WRF-Chem.

[davegill]

@zxdawn Thanks for identifying all of the required fields for us.

[zxdawn]

@davegill You're welcome. As mentioned in #983, there's a bug in one method of simulating lightning. If that's possible, you can fix it and test them together.

[zxdawn]

@davegill I'm trying to fix the issue now. But, I checked registry.chem in master and develop branch. I couldn't find method option iccg_method. When I download the released file such as V4.1.4, the registry.chem actually has that variable.

registry.chem in releasev4.1.4 branch has 3667 lines, but that tar.gz file downloaded from release page has 4174 lines.

Could you show me which file should I edit?

[davegill]

@zxdawn Xin,

1. Use the wrf-model/WRF fork and the develop branch.

2. The develop branch has iccg_method in both the physics and the chem namelist records. This should actually be an acceptable solution, right? The value of iccg_method is zero for non-chem runs (the default in the Registry.EM_COMMON), and the value can be assigned as usual in the chem namelist record when building WRF Chem.

[zxdawn]

@davegill Thanks! As you mentioned before, we need to take care of the order of the registry. So, I think we need to delete these lines in registry.chem, Because these options should be used in both phys and chem. BTW, Registry.COMMON has already had part of these options. These deleted lines I mentioned above shouldn't be used at all because these are quite old names which are not called by WRF-Chem.

These useful options in WRF-Chem is at the end of registry.chem.

I will test the solution mentioned above and give you the reponse :)