# SMOKE v5 “output statement overflows record” when HFLUX ≳10¹⁴—any workaround without recompiling?

**URL:** <https://forum.cmascenter.org/t/smoke-v5-output-statement-overflows-record-when-hflux-10-any-workaround-without-recompiling/5901>\
**Category:** SMOKE\
**Created:** [July 7, 2025, 1:37pm UTC](https://forum.cmascenter.org/t/smoke-v5-output-statement-overflows-record-when-hflux-10-any-workaround-without-recompiling/5901 "2025-07-07T13:37:02Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![DS1](https://avatars.discourse-cdn.com/v4/letter/d/71e660/32.png) [@DS1](https://forum.cmascenter.org/u/DS1)\
**Post date:** [July 7, 2025, 1:37pm UTC](https://forum.cmascenter.org/t/smoke-v5-output-statement-overflows-record-when-hflux-10-any-workaround-without-recompiling/5901/1 "2025-07-07T13:37:02Z")

</div>

Hello everyone,

I’m running SMOKE v5.0 on a QFED→FF10 wildfire inventory. Some of my point-day HFLUX values are on the order of 10¹⁴. When SMOKE writes these rows, I get:

forrtl: severe (66): output statement overflows record, unit -5, file Internal Formatted Writeforrtl: severe (66): output statement overflows record, unit -5, file Internal Formatted Write

If I simply divide HFLUX by 10³ (so the longest formatted field stays ≤ 12 characters), SMOKE completes successfully. My plan is to then multiply the HFLUX back by 10³ downstream (e.g. in post-processing) to recover the original BTU/hr.

What I’d like to know:

1. Is there a better way?
2. Has anyone seen this overflow error in **smkmerge** (wrmrgrep)?
3. Would switching to scientific notation (and accepting a small loss of precision) be a reasonable workaround?
4. Is there any runtime or environment setting—ulimit, Fortran flag, etc.—to enlarge the internal write buffer or otherwise shorten the formatted output, _without_ rebuilding SMOKE?
5. If recompilation is unavoidable, what buffer size (character length) would you recommend in `wrmrgrep.f` to safely handle values up to ~10¹⁶ BTU/hr?

Any pointers, small patches, or example snippets would be greatly appreciated!

Thanks,  
Dave

---

<div class="post-metadata">

**Author:** ![james.beidler](https://avatars.discourse-cdn.com/v4/letter/j/6f9a4e/32.png) [@james.beidler](https://forum.cmascenter.org/u/james.beidler)\
**Post date:** [July 7, 2025, 2:26pm UTC](https://forum.cmascenter.org/t/smoke-v5-output-statement-overflows-record-when-hflux-10-any-workaround-without-recompiling/5901/2 "2025-07-07T14:26:44Z")

</div>

Hi,

Please use the latest version of SMOKE from github ([GitHub - CEMPD/SMOKE: Create emissions inputs for multiple air quality modeling systems with unmatched speed and flexibility](https://github.com/CEMPD/SMOKE)) that contains a field expansion to accommodate large HFLUX values ([Update maximum column header width for fields with values \> 16 charac… · CEMPD/SMOKE@39b8918 · GitHub](https://github.com/CEMPD/SMOKE/commit/39b8918b7fde2bb69b78685067c7e54bf024ad76)).

Additionally, how are you estimating heat flux for the QFED grid cells? Assuming an 8000 BTU/lb heat content, 10^16 BTU/hr works out to 625 million tons of woody material burned in an hour within a single 0.1x0.1 degree grid cell.