How is it possible to introduce more Landuse class?

[MarcelloCasula]

Dear all,

I have a new and more appropriate land use classification and I want to introduce it in the wrf simulation to check if there is an in improvement of results, this new classification comprise a larger number of landuse classes, just 2 more classes respect to the 27 USGS ones. I'm dealing with the 4.2 version and using noahmp. Considering that the class 28 is reserved to inner water bodies, so it is not available, there are two free number of land use, 29 and 30, so I would like to exploit this two free class to introduce the new ones. I modified the MPTABLE.TBL (NVEG = 27 => NVEG = 30) adding all the values for the new classes 28, 29, 30, considering for the class 28 the same values used for the class 16 that describe a generic water bodies. Then I also modified the module_sf_noahmplsm.F in order to consider a larger number of landuse class.
"INTEGER, PRIVATE, PARAMETER :: MVT = 27" becames
"INTEGER, PRIVATE, PARAMETER :: MVT = 30".
Anyway recompiling and running wrf I get the error :
Program received signal SIGFPE, Arithmetic exception.
0x0000555559459c2e in module_shcu_grims::fthex (t=301.160004, pk=0.398619711)
at module_shcu_grims.f90:1149
1149 fthex=t*pd**(-rocp)*exp(expo).

Does anyone have been working with such problem?
Any tips will be really appreciated

Marcello

 

[Ming Chen]

I am perplexed why some changes in NoahMP can cause problems in shallow convection unless the values from NoahMP that feed to shallow convection are physically wrong.
I will discuss with our experts and first make sure your changes of NoahMP are reasonable.

 

[MarcelloCasula]

Here is also the MPTABLE.TBL so you can have a look also to the values I used for the new classes.
I was able to upload the MPTABLE.TBL only changing the axtention from .TBL to .F.
thanks
Marcello

 

[MarcelloCasula]

Dear Ming Chen, is there any news about the problem with the new land use class?
was you able to contact your experts?
Thanks
Marcello

 

[Ming Chen]

Marcello,
I didn't have the feedback from our expert. Usually they help with issues related to standard WRF codes and data, but for changes made by users (and such changes could be in various formats and in many different styles), it is hard to investigate each individual cases due to limited human power we have.

I would suggest that you compile WRF in debug mode (./configure -D), then rerun this case. Then you find exactly when and where the model failed first. This information could be helpful for you to identify what variables/values are unreasonable in your modified MPTABLE.TBL.

 

[MarcelloCasula]

Dear Ming Chen,

looking more carefully inside the problem I solved by myself the issue, hoping that someone else could take some advantage. Code modification and the new MPTABLE.TBL were ok, the problem relied on a incorrect input file deriving from geogrid.exe process. Now the system is running like a charm.

 

[Ming Chen]

Marcello,
Thank you very much for the update. Would you please clarify what issues exist in geogrid?

 

[MarcelloCasula]

Dear Ming Chen,
for my test i used an input binary file involving more than 30 LU class, therefore for some class there was not value of initialization in MPTABLE: it is not required anything else involving code or MPTABLE.TBL changing but what I have uploaded in the previous messages,

 

[Ming Chen]

Thank you for the update.