# CGRID output not properly generated **URL:** \ **Category:** CMAQ\ **Created:** [September 11, 2018, 1:35pm UTC](https://forum.cmascenter.org/t/cgrid-output-not-properly-generated/278 "2018-09-11T13:35:35Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![LGS](https://avatars.discourse-cdn.com/v4/letter/l/839c29/32.png) [@LGS](https://forum.cmascenter.org/u/LGS)\ **Post date:** [September 11, 2018, 1:35pm UTC](https://forum.cmascenter.org/t/cgrid-output-not-properly-generated/278/1 "2018-09-11T13:35:35Z")
CGRID is not properly generated by a single day CCTM simulation using CMAQv5.0.2. Its size is way too small (32) compared to that of other outputs (ACONC, CONC, etc.) and cannot be opened to visualize its content using either ncdump or Verdi. What may be the cause? ---
**Author:** ![lizadams\_3](https://avatars.discourse-cdn.com/v4/letter/l/e79b87/32.png) [@lizadams\_3](https://forum.cmascenter.org/u/lizadams_3)\ **Post date:** [September 11, 2018, 3:47pm UTC](https://forum.cmascenter.org/t/cgrid-output-not-properly-generated/278/2 "2018-09-11T15:47:02Z")
> [@LGS](#): > > CGRID Do you have any WARNING or ERROR messages in your log file that relate to the CGRID file? ---
**Author:** ![LGS](https://avatars.discourse-cdn.com/v4/letter/l/839c29/32.png) [@LGS](https://forum.cmascenter.org/u/LGS)\ **Post date:** [September 11, 2018, 5:06pm UTC](https://forum.cmascenter.org/t/cgrid-output-not-properly-generated/278/3 "2018-09-11T17:06:12Z")
This is the error at the end of the run.cctm log file: \*\*\* ERROR ABORT in subroutine WR\_CGRID on PE 000 Could not open S\_CGRID file Date and time 0:00:00 Nov 2, 2011 (2011306:000000) application called MPI\_Abort(MPI\_COMM\_WORLD, 538976288) - process 0 0.078u 0.171s 10:43:03.08 0.0% 0+0k 0+0io 0pf+0w date Tue Sep 11 00:18:52 CDT 2018 exit ---
**Author:** ![lizadams](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@lizadams](https://forum.cmascenter.org/u/lizadams)\ **Post date:** [September 11, 2018, 7:00pm UTC](https://forum.cmascenter.org/t/cgrid-output-not-properly-generated/278/4 "2018-09-11T19:00:41Z")
The CGRID file is referred to as a circular restart file, in that it’s updated at the end of every output time step with the full range of pollutants/layers. With the CGRID file only containing a single time step it is a relatively small file. Do you know how many timesteps were written out by the model before you obtained this error? To help diagnose what is going on, before you run again, remove the CGRID file, and all output files or create a new output directory. Restart CMAQ again and then look for an ERROR in both the run.cctm log file and the per processor CTM\_LOG files if you are running on multiple processors. It may be that the CGRID file that was created is only writing the header before failing. You can see what is in a the header of the file using the command: > ncdump -h ---
**Author:** ![LGS](https://avatars.discourse-cdn.com/v4/letter/l/839c29/32.png) [@LGS](https://forum.cmascenter.org/u/LGS)\ **Post date:** [September 11, 2018, 7:58pm UTC](https://forum.cmascenter.org/t/cgrid-output-not-properly-generated/278/5 "2018-09-11T19:58:27Z")
(1) Regarding the time steps written out by the model, they are 24 or 25, depending on the output file: CONC: TSTEP=UNLIMITED; // (24 currently) ACONC: TSTEP=UNLIMITED; // (25 currently) DRYDEP: TSTEP=UNLIMITED; // (24 currently) WETDEP: TSTEP=UNLIMITED; // (24 currently) (2) Looking for errors in CTM log files: In one of them, I noticed a “failure” message that may be related to the “time step”: “EBI Euler convergence failure Reducing EBI time step because of convergence failure for cell (104, 12, 2) Back-up number 1” (3) Checking the content of the CGRID file using ncdump -h, indeed only the heather was created by the model run: netcdf CCTM\_D502a\_Linux2\_x86\_64gcc.CGRID { } Could (2) be the case of CGRID model failure? ---
**Author:** ![lizadams](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@lizadams](https://forum.cmascenter.org/u/lizadams)\ **Post date:** [September 11, 2018, 8:27pm UTC](https://forum.cmascenter.org/t/cgrid-output-not-properly-generated/278/6 "2018-09-11T20:27:45Z")
Yes, (2) could be the problem, but I would expect an error statement in one of the log files. Can you try using the following command and report back if you found an error. > grep -i ERROR CTM\_LOG\* You can also try to reduce the max synchronization time step (CTM\_MAXSYNC in the CCTM run script), which is a conventional way to configure finer grid nests. > setenv CTM\_MAXSYNC 300 Do you have the CTM\_CKSUM environment variable set to yes? > setenv CTM\_CKSUM Y This should output the total (checksum) of all gas, aerosol, and nonreactive species after each science process. Sometimes you can see a species class blow up or become NaN, which can help pinpoint where and when the problem is. ---
**Author:** ![LGS](https://avatars.discourse-cdn.com/v4/letter/l/839c29/32.png) [@LGS](https://forum.cmascenter.org/u/LGS)\ **Post date:** [September 12, 2018, 2:21pm UTC](https://forum.cmascenter.org/t/cgrid-output-not-properly-generated/278/7 "2018-09-12T14:21:24Z")
There were no ERROR messages in the CTM.log files. The only ERROR was the one in the run.cctm.log file that I reported in the first place. Meanwhile and before your last suggestions, I ran another simulation with slight changes in the run.cctm script, such as: setenv CONC\_SPCS “O3 NO ANO3I ANO3J NO2 FORM ISOP ANH4J ASO4I ASO4J” #Before, the number of species was higher setenv ACONC\_BLEV\_ELEV “1 20” # Before this was “1 22” and I think that the ERROR reported in the first place was related to this because I have tried in the past and “1 20” was the maximum limit at which the model did not fail. The setenv CTM\_CKSUM was set to Y in both previous and current model runs. The setenv CTM\_MAXSYNC was set to 720 in both previous and current model runs. In the current simulation, no ERROR message was present in either the run.cctm.log or the CTM.log files. The CGRID was more completely generated and has a larger size compared to previous run (2,978,180,132 _versus_ 32) but the time step written is 1. Also, the warning/failure in (2) above was still present in one of the CTM.log files but the model run did not stop because of it and all the CTM.log files show this message at the end: —\>\> Normal Completion of program DRIVER on PE 015 \<\<— Date and time 0:00:00 Nov 2, 2011 (2011306:000000) ``` >>----> Program completed successfully <----<< ``` _Question_: Why is the CGRID written for a single time step? Is it the output at the end of the last hour of the day? I need the CGRID file to start a 24-h Lagrangian (PinG) simulation (CCTM-APT) and I do not know how this would work if the CGRID file has only 1 time step in it. ---
**Author:** ![lizadams](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@lizadams](https://forum.cmascenter.org/u/lizadams)\ **Post date:** [September 12, 2018, 2:42pm UTC](https://forum.cmascenter.org/t/cgrid-output-not-properly-generated/278/8 "2018-09-12T14:42:59Z")
The CGRID is updated at the end of every output time step, over-writing the previous timestep. It contains a full range of pollutants and layers. It is what you need to start (provide the initial condition) for a new model simulation and will work fine for CMAQ-APT. ---
**Author:** ![LGS](https://avatars.discourse-cdn.com/v4/letter/l/839c29/32.png) [@LGS](https://forum.cmascenter.org/u/LGS)\ **Post date:** [September 12, 2018, 2:56pm UTC](https://forum.cmascenter.org/t/cgrid-output-not-properly-generated/278/9 "2018-09-12T14:56:48Z")
Thank you for clarifying the CGRID. In this case, the CGRID file should be run for the previous day of the intended 24-h Lagrangian simulation or for the same day? ---
**Author:** ![lizadams](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@lizadams](https://forum.cmascenter.org/u/lizadams)\ **Post date:** [September 12, 2018, 3:35pm UTC](https://forum.cmascenter.org/t/cgrid-output-not-properly-generated/278/10 "2018-09-12T15:35:53Z")
The timestamp information is available in the CGRID file that you created. Use this command to print out the 16 lines after (-A) the line that matches ‘global attributes’. > ncdump -h CCTM\_D502a\_Linux2\_x86\_64gcc.CGRID | grep -A 16 ‘global attributes’ Review the SDATE and STIME values. It is my understanding that the start date listed in the CGRID file will be the last hour of the model run that you did, which will be the first hour of the next day. If this is correct, then the CMAQ should be run for the previous day of the intended simulation. For example: if the CGRID file contains the values > ``` > :SDATE = 2011182 ; > :STIME = 0 ; > > ``` Then the run script for your 24-h Lagrangian simulation should be modified to set the following values for START\_DATE: > #\> Set Start and End Days for looping > setenv NEW\_START TRUE #\> Set to FALSE for model restart > set START\_DATE = “2011-07-01” #\> beginning date (July 1, 2011) > set END\_DATE = “2011-07-01” #\> ending date (July 14, 2011) Note: you can use the following command to determine the gregorian calendar value that matches the julian date in the CGRID file. > gregdate 2011182 Output: > Friday, July 1, 2011 > Daylight Savings Time in effect. ---
**Author:** ![LGS](https://avatars.discourse-cdn.com/v4/letter/l/839c29/32.png) [@LGS](https://forum.cmascenter.org/u/LGS)\ **Post date:** [September 12, 2018, 4:26pm UTC](https://forum.cmascenter.org/t/cgrid-output-not-properly-generated/278/11 "2018-09-12T16:26:41Z")
That is also my understanding. In my CGRID: :STDATE = 2011306 ; :STIME = 0 ; However, my Lagrangian simulation has a start date of 2011305. This means that I should run CCTM for 2011304 in order to get the CGRID output at the end of 2011304, which becomes the initial condition for the 2011305 Lagrangian simulation. So, the STDATE in CGRID should be 2011305. I tried using the “gregdate” command on my tcsh but I get the “Command not found” message. Is there an alternative command for “gregdate” on tcsh? ---
**Author:** ![lizadams](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@lizadams](https://forum.cmascenter.org/u/lizadams)\ **Post date:** [September 12, 2018, 4:43pm UTC](https://forum.cmascenter.org/t/cgrid-output-not-properly-generated/278/12 "2018-09-12T16:43:50Z")
gregdate is a m3tools executable that is typically installed and built with the ioapi library. You will likely need to add this directory to your path in your .cshrc once you find it’s location on your machine. For example, I have the following command in my .cshrc > set path = ($path /nas/longleaf/home/lizadams/ioapi-3.2/Linux2\_x86\_64gfortmpi ) As this is the location of the gregdate command > ls /nas/longleaf/home/lizadams/ioapi-3.2/Linux2\_x86\_64gfortmpi/gregdate ---
**Author:** ![LGS](https://avatars.discourse-cdn.com/v4/letter/l/839c29/32.png) [@LGS](https://forum.cmascenter.org/u/LGS)\ **Post date:** [September 12, 2018, 5:29pm UTC](https://forum.cmascenter.org/t/cgrid-output-not-properly-generated/278/13 "2018-09-12T17:29:49Z")
I could make it work by running the gregdate executable from the ioapi directory where it was installed. Thank you so much for your very helpful guidance! ---
**Author:** ![zyj.jess](https://avatars.discourse-cdn.com/v4/letter/z/8dc957/32.png) [@zyj.jess](https://forum.cmascenter.org/u/zyj.jess)\ **Post date:** [July 22, 2019, 10:49pm UTC](https://forum.cmascenter.org/t/cgrid-output-not-properly-generated/278/14 "2019-07-22T22:49:42Z")
Hi, all; I have also experiencing this issue with writing CGRID outputs. This issue crashed my simulation a lot of times. Sometimes, it showed up after a while of running. This time, it showed up at the very beginning. However, sometimes, with the same settings, I don’t have any problem with it at all. I am very confused by this issue now. There is no error message in the log files except the one shown below. ![18%20PM](https://canada1.discourse-cdn.com/flex027/uploads/cmas/original/1X/ced95208df7b0ecb1768c3fc2dd1dadffa51f2ec.jpeg) I tried to change settings according to the suggestion previously posted, however, that does not seem to work. Could you point me to anything I can do to avoid this issue with CGRID? Thank you very much! Yijia ---
**Author:** ![cgnolte](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.cmascenter.org/cgnolte/32/53_2.png) [@cgnolte](https://forum.cmascenter.org/u/cgnolte)\ **Post date:** [July 23, 2019, 12:23pm UTC](https://forum.cmascenter.org/t/cgrid-output-not-properly-generated/278/15 "2019-07-23T12:23:40Z")
Yijia, The situation you are describing is very different from the subject of this thread. If you post a follow-up question, please start a new thread. Try recompiling the model in debug mode. This can be done by uncommenting set Debug\_CCTM in bldit\_cctm.csh. When you do so, then if a crash occurs you usually get more information as to what the problem is and what line in the code the model is executing at the time. ---
**Author:** ![cjcoats](https://avatars.discourse-cdn.com/v4/letter/c/ac8455/32.png) [@cjcoats](https://forum.cmascenter.org/u/cjcoats)\ **Post date:** [July 23, 2019, 2:01pm UTC](https://forum.cmascenter.org/t/cgrid-output-not-properly-generated/278/16 "2019-07-23T14:01:41Z")
“Illegal instruction” says that the executable was compiled for a more-davanced CPU model than the one you are running on. Recall that each new generation of Intel or AMD processors adds new instructions that make programs potentially run faster/better, provided the programs are comiled to use these instructions; the down-side is that earlier-generation processors will fail in exactly the way you are seeing. You need to re-compile your entire model (including libraries) for the processor you’re runnng on. (Search for -`Xhost` in the output for _man ifort_ or “-march” in the output for _man gcc._…) ---
**Author:** ![cjcoats](https://avatars.discourse-cdn.com/v4/letter/c/ac8455/32.png) [@cjcoats](https://forum.cmascenter.org/u/cjcoats)\ **Post date:** [July 23, 2019, 2:02pm UTC](https://forum.cmascenter.org/t/cgrid-output-not-properly-generated/278/17 "2019-07-23T14:02:37Z")
…or else that you have disk- or memory-corruption that is corrupting good instructions into bad ones (quite unlikely, but conceivable)