Thanks for your suggestion. I have get them out and here are the files.
GRIDDESC.log.txt (203 Bytes)
metcro3d_ncdump.log.txt (10.2 KB)
makefile.log.txt (31.4 KB)
Based on your suggestion, I find that maybe I need to rerun my mcip to give a value for TSTEP. I am not sure whether it is right.
@hogrefe.christian and I looked at the outputs you provided and nothing immediately stands out. Given the complexity of the errors you are seeing I suggest a few things:
-
Could you describe exactly what you are trying to simulate, or science question you are trying to answer? Depending on this, there are certain options that may or may not make sense. Please be as descriptive as possible (include model version, etc), so we can understand the full picture.
-
Testing the same scripts/code with a different compiler can often be helpful, so if you access to this option I’d recommend doing that.
-
Uploading your runscript, meteorology inputs from MCIP, initial condition and boundary condition to the CMAS DATA WAREHOUSE google drive incoming folder so we can test your scenario internally. See README-CMAS_User_Forum - Google Docs for additional information. A single day of input is sufficient for debugging.
Hi Fahim.
- Actually I am new to CMAQ model, I want to do a small domain simulation around this area because we have some measured data around LAMONT, OK. I want to check the new particle formation process among different vertical layers in the area. We will also consider wet deposition.
- I have an old hp z840 workstation which is also powerful enough with 128 cores. I am begining to try the simulation on it. But also it is based on GCC compiler. I hope it can work. Because our HPC is a powerpc which has a different architechture so I think the try is worthy. And our university hpc only has gcc and xl as compilers offered. So if I want to try intel compiler and pgi, I need to communicate with administrator or build in my own workstation.
- I have updated the file. The name is 20190802_mid.tar.gz
Thanks for your help!
Hi, Fahim. I found that I used wrong wrfoutput file. The file is around Florida. I am afraid that some of the boundary is out of United States and that maybe the problem? I will try with new wrfoutput today.
Yours,
Chen
Thanks for uploading the data for your case. After some testing with @hogrefe.christian we were able to reproduce your error and think that the issue stems from your domain definition.
As @hogrefe.christian noted:
“CCTM can automatically horizontally window gridded files like CGRID or emissions (in your case, EQUATES input files with 299 rows and 459 columns) to a smaller domain (like your subdomain with 125 rows and 125 columns), as long as they share the same projection and the subdomain is fully contained in the larger domain.”
However, there is one additional caveat in the following statement: “the subdomain is fully contained in the larger domain”. This statement assumes that your smaller domain is a least some whole number multiple of the larger domain on all sides.
Figuratively, this is what that means:
In the domain configuration you provide in your GRIDDESC:
GRID_NAME = ‘2019_08d1’
XORIG = 138000.000
YORIG = -1338000.000
Notice the larger domain grid configuration:
GRID_NAME = ‘12US1’
XORIG = -2556000.0
YORIG = -1728000.
This suggests that the GRID ‘2019_08d1’ is exactly 224.5 grid cells in the X direction and 32.5 in the Y direction, which is not a proper domain definition (off by 0.5*dx) to use if you want to window the EQUATES emissions inputs. Doing so, is causing memory allocation issues and hard to find non-trivial errors in the code.
In this case, you have a couple of options:
-
Re-run WPS and WRF to re-define your domain to be half a grid cell more or less than what you provide in ‘2019_08d1’. You’ve expressed capability in doing so, so I suggest you pursue this route.
-
If you are adamant about keeping your domain definition, than you must re-grid all the emissions inputs to match your domain definition. This option is much harder, but certainly can be done.
Please let us know if this fixed your issue, if so we appreciate your help in finding a case where the current implementation of CMAQ doesn’t safely catch this specific invalid setup and leads to hard to find errors. We will work to update our documentation and model code in future releases!
Thanks!
4 Likes
Thanks for your reply. I am trying to rerun my WPS and WRF. I think I am lacking enough understanding for the relationship between namelist.wps and GRIDDESC. I think this problem is being solved. If I have more problem, I will make a new post. I am really thanks for your help and patience.
1 Like
I want to make sure. In my understanding that for my GRIDDESC [138000-(-2556000)]/12000 = 224.5 cells. So if i want to get a right one. 138000+/- 0.5*dx will be right cause I will get 224 ot 225 cells. Is that right?
1 Like
Yes. The difference between the x (y) origin of your domain as defined in your GRIDDESC file and the x (y) origin of the 12US1 domain (on which the gridded emission input files you’d like to use are defined) must be an integer multiple of the dx (dy) grid spacing, i.e. 12,000 m.
2 Likes
Thank you! I learned a lot from this.