I used SMOKEv4.7 to process the EPA 2016 v1 emission. It run well until this week it kept crashing. I have recompiled the software and ask IT administrator to reboot the server. However, it still shows the following error:
forrtl: severe (66): output statement overflows record, unit -5, file Internal Formatted Write
Image PC Routine Line Source
movesmrg 00000000006135EB Unknown Unknown Unknown
movesmrg 000000000064DC4C Unknown Unknown Unknown
movesmrg 000000000050B6DB str2real_ 67 str2real.f
movesmrg 000000000042A7D9 rdrpdemfacs_ 510 rdrpdemfacs.f
movesmrg 0000000000407A5A MAIN__ 496 movesmrg.f
movesmrg 0000000000405522 Unknown Unknown Unknown
libc-2.17.so 00002ABFA5962555 __libc_start_main Unknown Unknown
movesmrg 0000000000405429 Unknown Unknown Unknown
1603.865u 7.040s 29:10.07 92.0% 0+0k 11782032+584io 1pf+0w
I didn’t see similar problem in the past year with SMOKE v4.7 and 2016 beta/v1 emissions. I can not figure out what could be the problem. change of server set-up? Any suggestions are welcome. Thanks
This is a buffer-overflow in an error message. It implies (1) that the string being passed into
STR2REAL() is not a correctly-formatted
REAL; and (2) the trimmed length (after trimming trailing blanks) is unreasonably long.
It probably implies an input-error.
What program are you running when the crash occurs? Can you provide a standard output or log file?
Are you able to rerun things that worked for you in the past?
Sorry about just giving the generalities earlier: reading the forum at breakfast, I did not have access to the SMOKE source…
Line 510 of rdrpdemfacs.f: he’s attempting to read an emissions-factor from some line in an emissions-factor file, but that emissions-factor field is not only badly formatted but also unreasonably long.
One way of diagnosing where this input-error happening is to go to “str2real.f” in the I/O API, change variable
MSG to something also unreasonably long (say,
CHARACTER*512), and re-build I/O API and SMOKE from there. Then we shouldn’t have a buffer-overflow, and the error-message in line 516 of rdrpdemfacs.f should report the line-number at which this badly-formatted input occurs.
Hmmm… That is interesting. The 2016 platform has been fully tested with SMOKE v4.7. Haven’t run into any input data issue. I believe that the length of emission factor columns in RPD lookup tables are less 50 characters.
I do agree with @cjcoats that you should compile the IOAPI with the changes (MSG = 512 characters) and give another try to find out whether it is coming from the badly formatted input file or not.
Also, you can check the RPD lookup table columns to find out any column length is > 50 chars.
BTW, I’ve just lengthened buffer-lengths substantially in the relevant I/O API routines str2.f*, and uploaded the changes to both the GitHub and CMAS I/O API download-pages. One hopes that will catch any such problems in the future…
Thank you all for the great suggestions. I agree with Dr. Baek that it is so strange because I have used the same code and input files for a long time without finding this problem. I guess there was some change or update of the server which could trigger this problem. I will download the latest I/O API and recompile the library and SMOKE per Coats’ suggestion. I will keep you updated.
I recompiled I/O API and SMOKE. It shows another error (please see the attached file). I think the format of one variable is still not right. It is so strange because all the inputs are from EPA v1 platform and not been touched. I tried to figure out where this one is, but I can not. Any comments?
movesmrg_RPD_onroad_may_2016fh_16j_20160501_12US2_cmaq_cb6.txt (90.1 KB)
Based on the error message, there is a format issue from this particular file:
I would suggest for you to go through the format carefully but before that, in case, please covert it to unix format by “dos2unix rateperdistance_smoke_aq_cb6_saprc_1Aug2019_2016v1platform-2016-20190718_13119_7.csv” and rerun the run script. If that does not fix the issue, I think you need to check and review this file carefully.
You might try redownloading the zip with those specific emission factor tables – perhaps it was corrupted somewhere along the way
Alison, you are correct. I downloaded the files and re-run the code without any problem. Seems like one line in the eftable is corrupted. Thanks for the suggestion.