I am running SMOKE on Derecho (NCAR cluster) but got the following error at the merge step.
“*** ERROR ABORT in subroutine SETOUTDATE
Inconsistent start time in input files”
I compiled IOAPI-3.2 and SMOKE 4.7 with the GFortran compiler and was merging emissions. The pre-merged emissions are generated before with an Intel compiler. The start time in all the premerged-emission files are consistent.
As your log says, there is an inconsistency in the files: the OCEAN file is for 2005 whereas the rest of the files are for 2017. This is a problem…
On the other hand,the time step sequence checks for the input files to MRGGRID are unreasonably strict: they should check that the files contain the data for the run’s requested time step sequence, rather than insisting that the files contain exactly this time step sequence. FWIW.
@cjcoats, it’s been a while since I used mrggrid, but shouldn’t MRG_DIFF_DAYS which is set to Y allow the tool to merge across different dates, as long as the times line up? I think that’s a pretty standard way of using this tool, with some emission sectors being only processed for representative days and others processed for each individual day. If so, the problem might indeed be with an overly restrictive consistency check on the times? I’m a bit out of my element here, though.
No, it’s not about the ocean emissions. I got the same error message after turning ocean emission off.
I succeed in memerging exactly the same files on the Cheyenne cluster. So I was wondering the merge executable (GFortran compiled) is not compatible with pre-merged emissions (Generated by Intel-compiled SMOKE)
@hogrefe.christian is correct, MRG_DIFF_DAYS allows different dates to be merged and mrggrid is routinely used this way specifically with the ocean Cl file. There should be some additional output in the logs directly after the offending input file (“ERROR: Start time 000000 in file A…”) but it isn’t showing up.
@Phillip Are your m3tools compiled with GFortran? You could try reading and then dumping back out the files using m3xtract to see if that makes any difference. Can you share your run script and mrggrid FILELIST?
Yes, I compiled IOAPI and SMOKE with GFortran compiler, so m3tools are compiled with GFortran.
I didn’t get the “m3xtract” part and could you explain a little bit more?
I attached the run script and FIELIST.
BTW, Which script should I put the “MRG_DIFF_DAYS” option?
According to the mrggrid log that you shared MRG_DIFF_DAYS is already set to TRUE, so you are good on that front.
I see PTNONIPM in your filelist but not in your mrggrid log. Can you do a “ncdump -v TFLAG” on the ptnonipm gridded emissions file referenced by the PTNONIPM variable? You are looking for the STIME to be set to “0” in the global attributes and a 0 time in the first timestep of the TFLAG variable. If it is anything else that is likely the root of the problem.
Don’t worry about trying anything with m3tools until you verify the PTNONIPM time info.
BTW, I/O API M3Tools program M3STAT is often the easiest way to do this sort of check (by default, it reports statistics for each time step of each variable of the file…)
Thanks for checking, that’s too bad it wasn’t the simplest explanation.
There is a version of SMOKE 4.7 compiled with Intel Fortran available as part of the 2017gb package. Would you mind trying to use the mrggrid packaged in this zip file to see if it fixes the issue?
I did. It showed the following. That’s why I compiled it with GFortran.
“Please verify that both the operating system and the processor support Intel(R) X87, CMOV, MMX, FXSAVE, SSE, SSE2, SSE3, SSSE3, SSE4_1, SSE4_2, MOVBE, POPCNT, F16C, AVX, FMA, BMI, LZCNT and AVX2 instructions.”
If it was exactly this error:
“*** ERROR ABORT in subroutine SETOUTDATE
Inconsistent start time in input files”
Did you try the SMOKE 5.0 package posted above?
There is a related issue and bug fix posted to GitHub that you can try if you want to compile from source:
