After running the CCTM, I got this error message in the log file. Could you please help me in resolving the issue?
Thank you in advance for any help you can provide,
Reza
This says that date&time 2012154:010000 is not a TFLAG-pair in the file (which then says that this date&time was never successfully written to the file).
First, check the log-output from OPEN3 to make sure environment-variable MET_CRO_3D refers to the file you think it does; then do the command
ncdump -v TFLAG $MET_CRO_3D
and see whether the pair 2012154:010000 occurs. If not, then either (a) this is not the right MET_CRO_3D file; or else (b) this was not a correctly-generated MET_CRO_3D file (and where did it come from, by the way?); or (c) there is some problem outside my scope of expertise with subroutine retrieve_time_de or its callees.
1 Like
Thank you for the suggestion. I did the command and get this result:
So where did this file come from? Not MCIP (which is supposed to be how you produce MET_CRO_3D files), I’m sure…
Actually, these files come from MCIP process. I passed MCIP without the error message.
@tlspero
Hello Ms. Tanya,
If you remember, you helped me to solve the problem with MCIP outputs a week ago. There is no error message in MCIP log files and the message “NORMAL TERMINATION” does exist. Nevertheless, I get following error message during the CCTM step:
@rrezaei83 –
As noted by @cjcoats, the error message indicates that the requested time period is not found in the METCRO3D file. If the METCRO3D file was created by MCIP, then the TFLAG should reflect actual times. What I suspect has happened is that you have accidentally linked your GRIDCRO2D file to the environment variable for $MET_CRO_3D in your script. Please double-check your script to ensure that you have the correct file linked to $MET_CRO_3D.
–Tanya
Thank you for responding. I double-checked the environmental variables and found no issues with the script. I repeated the MCIP process, and then looked at the TFLG of the MET_CRO_3D files. . The result has changed as follows (the beginning and end of FLAG):
However, I get the same error message in the CCTM log.
@rrezaei83 –
The error message is slightly different now, and it applies to the next day. The environment variable for MET_CRO_3D needs to be updated to include the data for 01 UTC 3 Jun 2012. (The original error applied to 01 UTC 2 Jun 2012.) I suggest this is likely a scripting issue, but you’re on the right track.
–Tanya
1 Like
Thank you, Ms. Tanya. I’ll make the necessary changes.
@tlspero
Hi Ms. Tanya,
I have another question about the aforementioned problem. To my understanding, the MCIP process produces daily meteorological outputs, with each file containing data from 00:00:00 of the current day to 00:00:00 of the following day (25-hours data). So, why does the CCTM try to read the MCIP data associated with the time 01:00:00 of the next day in my case?
In your CCTM run script, what are the settings of CTM_STDATE, CTM_STTIME, CTM_RUNLEN, and CTM_TSTEP? These values determine which range of dates and times the CCTM will attempt to read from the MCIP files.
@hogrefe.christian
Thank you for your reply.
CTM_STDATE is the first day of the month, however, the MCIP outputs of the last day of the previous month are given.
CTM_STTIME is 00:00:00.
CTM_RUNLEN is 30 days, and CTM_TSTEP is 1-hour.
That is the problem. In this setup, the CCTM will try to perform a single run for an entire month, with individual time steps in the output files spaced by 25 hours (i.e. the files would have a first output time step hour 0 of day 1, a second output time step hour 1 of day 2, etc.). If that’s what you actually wanted, all your input files (including MCIP and emissions) would have to contain the required data to cover such a month-long run.
Assuming that you really want to run day-by-day and would like to have hourly values in your daily output files, you would want to set CTM_RUNLEN to 240000 (24 hours, 0 minutes, 0 seconds) and CTM_TSTEP to 10000 (1 hour, 0 minutes, 0 seconds). For the first day when CTM_STDATE is the first day of the month, this would give you CCTM output for that first day. When looping over days to run CMAQ for the other days in your month, you would then increment CTM_STDATE by one day at a time.
By “CTM_TSTEP = 25-hours” I mean there are 25-time steps in each MCIP file. As you mentioned, the MCIP data are hourly. The TSTEP of CCTM is 1-hour, also.
O.k., so it sounds like you set CTM_TSTEP to 10000 which would be correct. But if you set CTM_RUNLEN to 7200000 (you wrote 30 days, but didn’t show the actual CTM_RUNLEN setting in your script), your CCTM simulation would try to run for the entire month at once, so with your current input files that contain only 25 hours of data, it would crash at the beginning of the second day which appears to be what’s happening.
The solution is to change CTM_RUNLEN to 240000 and then use a loop in the run script to change CTM_STDATE and perform individual 24 hour CCTM simulations for each day.
I apologize for any misunderstandings. I may use some terms incorrectly because I am new to the field.
I run MCIP and CCTM processes monthly in a loop. Each file contains 25-hours of data. Actually, the MCIP process generates daily (25-hours) data. Moreover, there is no error message in the MCIP log file. But, I get an error in the CCTM process, however, the process generates the outputs.
Could you please post your CCTM run script and full run script log file so we can have a closer look at your settings? Thanks!
Dear Christian, your suggestion worked. After setting NSTEPS = 240000, the error was resolved. I appreciate your help.