Mismatch between namelist and wrf input files for dimension NUM_LAND_CAT

[Zoo]

Dear all,

I'm having this problem with WRF3.3 (a specific task that should be down with this old version), and I collocated WPS3.8.

The problem I faced is similar to this: Real.exe claims NUM_LAND_CAT = 0 but untrue
I run WPS and get met_em_d* files without errors, and ./real.exe with no issue, and can verify that NUM_LAND_CAT = 21 both in these files and in my WRF namelist.input and namelist.output (attached). But when I run real.exe it crashes with the below error, which is duplicated in a couple of my rsl.out files.

Also, I changed the "real_em.F" as provided in the forum, but it didn't work.

I suppose it might be the mismatch between version 3.3 and 3.8, but don't know how to verify this.
P.S. I attached the namelist.wps, namelist.input, rsl.error.0000. And in the WRF run directory, I used the command "ls -ls >& ls.txt", which is attached as well.

Thanks for your help in advance!
Zoo


Timing for Writing wrfout_d01_2021-07-19_06:00:00 for domain 1: 127.39010 elapsed seconds.
d01 2021-07-19_06:00:00 MMINLU error on input
----------------- ERROR -------------------
namelist : NUM_LAND_CAT = 21
input files : NUM_LAND_CAT = 24 (from geogrid selections).
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 587
Mismatch between namelist and wrf input files for dimension NUM_LAND_CAT
-------------------------------------------
Abort(1) on node 0 (rank 0 in comm 0): application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0

 

[Ming Chen]

Please set NUM_LAND_CAT = 24 in your namelist.input, then try again.

 

[Zoo]

I really appreciate your help!

The question is I reset the NUM_LAND_CAT = 24, then the error becomes (while ./real.exe):
----------------- ERROR -------------------
namelist : NUM_LAND_CAT = 24
input files : NUM_LAND_CAT = 21 (from geogrid selections).
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE: <stdin> LINE: 587
Mismatch between namelist and wrf input files for dimension NUM_LAND_CAT


It seems they always mismatch no matter I change, and I don't know why.
Here are the namelist.input and rsl.error.0000. Thanks a lot!

 

[Ming Chen]

Are you running the case with the same met_em files? In your first post, the error message clearly indicates that NUM_LAND_CAT = 24 in your met_em files. However, in your 2nd post, NUM_LAND_CAT = 21 in your met_em file. This is really perplexing.

Now let's make sure what the number is. Suppose you have a met_em file, e.g., met_em.d01.2022-09-11_00.nc, please aissue the command:

ncdump -h met_em.d01.2022-09-11_00.nc | grep NUM_LAND_CAT

It will give you the result like: :NUM_LAND_CAT = 21 or :NUM_LAND_CAT = 24

This is the number you should specify in your namelist.input.

 

[Zoo]

Thank you for your reply!
I tried the command you mentioned, and I got:
ncdump -h met_em.d01.2021-07-19_18:00:00.nc | grep NUM_LAND_CAT
:NUM_LAND_CAT = 21 ;

This goes back to the very beginning when the error said input files : NUM_LAND_CAT = 24 (from geogrid selections).
It's confusing.

I found someone got the same problems here: Mismatch between namelist and wrf input files for dimension NUM_LAND_CAT , but he didn't finish this thread.

Thank you again!

 

[Ming Chen]

In your namelist.wps, you use the 'default' option to run geogrid, which indicates that you use MODIS land use data. In this case, NUM_LAND_CAT = 21 is correct. This is also what you saw in your met_em files.
However, the error message seems to indicate that NUM_LAND_CAT is not the same in all the met_em file.
Can you delete all met_em, then rerun metgrid.exe, and then try again?
Please let me know whether it can fix your issue.

 

[Zoo]

I really appreciate your help！

First I use the command: ncdump -h met* | grep NUM_LAND_CAT to check every met_em file, and they are all consistent in 21, that's weird.
Then I did the steps you mentioned, delete all met_em and rerun the metgrid.exe then it was solved!

Thanks a lot for your kind help!

Best regards,
Zoo

 

[Ming Chen]

Thanks for letting me know. it is great that it works!