I have this error
If you set “setenv NEW_START FALSE” then the CMAQ will try to obtain the CGRID file to re-start the simulation. However, this error message will show up once the CGRID file is not found. Thus, if you are initializing a new simulation, try to set “setenv NEW_START TRUE” and make sure the ICON file is correctly located.
I changed START_NEW to TRUE but I got the same problem.
I am sure that setup ICON location correctly
Still can make few output files
Please upload the CTM_LOG files for check.
BLCS_DDM_1km_test.e4692097.txt (125.9 KB)
BLCS_DDM_1km_test.4692097.txt (396.0 KB)
CTM_LOG_089 - Copy.v52_DDM_gcc_BLCS_DDM_1km_20161218.txt (4.1 KB)
As you can see, you ask the model to start simulations on Dec. 18, 2016. Then the model tries to read the files corresponding to Dec. 18, 2016. However, the model doesn’t find it then it crashed. Also, note that the output that you mentioned above is for Dec. 17, 2016 rather than Dec. 18, 2016.
You can upload your run.cctm.csh file for further check.
This is my run script.
run_cctm_BLCS_DDM_1km_1s.csh (35.1 KB)
Line 58:
Replace “set START_NEW = FALSE” by “set START_NEW = TRUE” then the above error should disappear.
BTW, please keep in mind set START_NEW = FALSE is for model restart. If you are initializing a new model run, you should do “set START_NEW = TRUE” because you don’t have the CROID file for restart.
It turned off with this error…
This is a code error.
By their very nature, REAL and DOUBLE PRECISION computations are subject to round-off error and consequently should never be tested for equality. Such tests should have an error-tolerance appropriate to the nature of the computation that produced them.
And pragmatically, cell-sizes (although DOUBLE PRECISION) frequently come from met-models that treat them as (single precision) REALs. Consequently, the test in advstep.F line 304
IF ( XCELL3D .NE. XCELL_GD .OR. YCELL3D .NE. YCELL_GD ) THEN
should be replaced by a test like the DBLERR test in I/O API grdchk3.f, which is carefully tuned to ensure that it return TRUE if the numbers are unequal if the computation was performed in single precision even on perverse floating-point hardware like IBM OS/360:
DBLERR( P, Q ) = ( (P - Q)**2 .GT. 1.0D-10*( P*P + Q*Q + 1.0D-5 ) )
[Frankly, CMAQ should be using this routine for its grid-checks instead of its own reinvent-the-wheel-badly home-grown checks.]
I would suggest you “ncdump -h bconfile.nc” then compare the global attributes with your emission file and MCIP outputs to see whether there are discrepancies existed.
This is Bcon
This is Emission data
FTYPE, CDATE, CTIME, WDATE, WTIME, NLAYS, NVARS, VGTYP, VGTOP, VGLVLS those are different between two files
What should I match?
As the original error-message said, there is a problem with XCELL and YCELL. The 6 significant digits are enough to be sure that the intent is for a 1 1/3 KM cell size, but that probably doesn’t exactly match what CMAQ is getting from its GRIDDESC file.
Again, the original test in advstep.F line 304 is egregiously bad code, and should be replaced by a test such as the one I suggested.
BTW, I have seen cases where we have the following
A = 1.0/3.0 B = 0.3333333 READ 6, Cwith input 0.3333333 for the READ
and A,B,C all turned out unequal. And this is perfectly legal for the compiler to do.
1 Like