Hello, I performed multi-level nesting. I encountered this error while running BCON. I tried adding a loop statement, but it still doesn’t work.
NCVGT: : NetCDF: Index exceeds dimension bound
netCDF error number -40
>>--->> WARNING in subroutine RDTFLAG
Error reading netCDF time step flag for CTM_CONC_1
M3WARN: DTBUF 1:00:00 Jan. 6, 2020 (2020006:010000)
NCVGT: : NetCDF: Index exceeds dimension bound
netCDF error number -40 Error reading variable "O3 " from file "CTM_CONC_1 "
netCDF error 0 reading file
Timesteps: LAST 2020006:000000; NEXT -0009999:******
>>--->> WARNING in subroutine M3_BCOUT:INTERP3
Error reading O3 from CTM_CONC_1
M3WARN: DTBUF 0:00:00 Jan. 6, 2020 (2020006:000000)
*** ERROR ABORT in subroutine M3_BCOUT
Could not read input CTM Conc file CTM_CONC_1
Date and time 0:00:00 Jan. 6, 2020 (2020006:000000)
looking at your log file, it seems that your setup is a bit unusual in that the MCIP files have a 2 hour time step and extend for many days while the CTM_CONC file has a 1 hour time step and is for a single day only.
I’ll have to have a closer look at the BCON code to see where things go wrong in this situation, but in the meantime, could you please perform a test in which you change the RUNLEN setting in your code from 240000 to 120000 to see what happens? Thank you!
Hello, after changing it to 120000, it ran successfully, but it only goes up to 12:00 on January 5, 2020, and doesn’t continue. Also, my CCTM_CONC files are one file per day, whereas previously there was only one file in total.
Having one CONC file per day is a very standard configuration so that’s not the cause of the problem. The non-standard 2-hour time step of the MCIP files is tripping up the code, but there’s probably a way to modify it to handle this situation. It’ll take us a bit to dig into it and propose a solution, we’ll try to have something for you within a week or so.
OK, thank you very much. If the issue lies in the two-hour time step, can I rerun MCIP to output data with a one-hour time step in order to make it compatible?
If your WRF output files have output every hour, then yes, you could and probably should rerun MCIP to create hourly meteorological input files for CCTM and BCON. But if you had WRF outputs only every two hours, you cannot create hourly files with MCIP.
I have confirmed that the BCON issue is caused by the combination of two-hourly MCIP files and an hourly CTM_CONC file, even when the optional run script variables SDATE, STIME, and RUNLEN variables are set to constrain the processing to a shorter period than the 15 days contained in the MCIP files to match the time period availabe in the CTM_CONC file. I have not yet found any error in the program logic, but have confirmed that function INTERP3 fails for the last time step available in the CTM_CONC file, somehow looking for 1:00:00 rather than 0:00:00 on January 6.
For your particular situation, I believe you can solve the issue by replacing the call to INTERP3 in subroutine M3_BCOUT with a call to READ3, by changing lines 393 - 394 in m3_bcout.F as follows and then recompiling BCON:
< IF ( .NOT. INTERP3( CTM_FL_NAME( N ), VNAME, PNAME, JDATE, JTIME,
< & NCOLS_IN*NROWS_IN*NLAYS_IN, CONCIN ) ) THEN
---
> IF ( .NOT. READ3( CTM_FL_NAME( N ), VNAME, ALLAYS3, JDATE, JTIME,
> & CONCIN ) ) THEN
This approach worked for me when I constructed and tested a case like yours with multi-day 2-hourly MCIP files and a single-day hourly CTM_CONC file and setting RUNLEN to 240000 in the run script. However, this code change would break things in a fairly common case where the MCIP files have hourly resolution and the coarse-grid concentration file (e.g. from a global CTM) has 3-hourly or 6-hourly resolution, so it’s not a change we will implement in the distributed code.
Hello, I regenerated hourly data using the MCIP module, but I still encounter errors when running BCON. I suspect that the loop statement may not be correctly calling the files for the second day. Could you please help me identify the cause? Thank you very much. RUNLEN to 240000 :success run_bcon9km.csh (6.1 KB) bcon9km-01.txt (14.5 KB)
setenv RUNLEN 240000 is the correct setting for your revised case in which you now have MCIP files with 361 1-hour time steps and a CTM_CONC file with 25 1-hour time steps.
Looking at your run script, you have the beginning of a loop over days
set START_DATE = "2020-01-05" #> beginning date (July 1, 2016)
set END_DATE = "2020-01-20" #> ending date (July 1, 2016)
set TODAYG = ${START_DATE}
set TODAYJ = `date -ud "${START_DATE}" +%Y%j` #> Convert YYYY-MM-DD to YYYYJJJ
set START_DAY = ${TODAYJ}
set STOP_DAY = `date -ud "${END_DATE}" +%Y%j` #> Convert YYYY-MM-DD to YYYYJJJ
while ($TODAYJ <= $STOP_DAY ) #>Compare dates in terms of YYYYJJJ
before setting up the input and output files and calling the executable
#> Executable call:
time $BLD/$EXEC
but you do not increment the day and close the loop after that call to the executable. That is why your program finishes successfully after processing the first day but the script then just exits due to the
exit()
command.
You will need to add something like this between the time $BLD/$EXEC and exit() commands, following the example from the CCTM run script:
#> Increment both Gregorian and Julian Days
set TODAYG = `date -ud "${TODAYG}+1days" +%Y-%m-%d` #> Add a day for tomorrow
set TODAYJ = `date -ud "${TODAYG}" +%Y%j` #> Convert YYYY-MM-DD to YYYYJJJ
end #Loop to the next Simulation Day
