Simulation Error - Abnormal simulation results detected - Sim Guidelines

4 posts / 0 new
Last post

Hi Ethan,
Thank you for the reference to the Mass. Simulation Guidelines. There are some helpful eQUEST-specific tips and keyword expressions in there!
FYI - there is a newer version v2.3 released July 2020. Not sure how different it is.

William Bishop, PE, BEMP, BEAP, CEM, LEED AP
Senior Energy Engineer

[Pathfinder-EA-logo-2]T: (585) 698-1956 F: (585) 325-6005
bbishop at
134 South Fitzhugh Street
Rochester, NY 14608 [cid:image004.png at 01D68B53.B5B235B0] Ask me why Carbon Fee & Dividend may be right for you.

Bill Bishop's picture
Joined: 2012-02-25
Reputation: 7

Hi Bill,

Thanks for the FYI - I'm also not sure how much has changed because the system work-around appendix still includes the DOAS work-around commonly used in DOE 2.2.

Have you ever come across this ''abnormal simulation results'' error before?
Ethan Seaman
Sustainable Design Analyst
t: 617.520.9288

eseaman413's picture
Joined: 2019-05-07
Reputation: 0

I'm providing a response that I hope may serve as a template/reference for a few of you to pick up this "bug tracking" skillset, and hopefully pay it forward for someone else someday!

Anytime you see the pattern "msgbomb" and then some numbers in a SIM report, that's a potentially helpful clue for logic you can look for in the doe2 source files.
[cid:image005.png at 01D68C1F.0D533500]

To follow along, you'll need to pull down a copy of the doe 2.3 source files (here: I'm specifically referencing the build

In the file ...doe23/SRC503/SYS.lis... I find a single reference to your msgbomb code ("Call MsgBomb(2010)"):
[cid:image003.png at 01D68C11.A8ED3960]

* I believe we are looking at Fortran. I'm not "fluent," but playing around with eQuest and other programming languages for a few years renders this logic relatively legible... here's a step-through of my observations:
* This is part of a subroutine called "TrmSer" (repeated along the right)
* Note that comments in this language/format have lines with a "c" as the first character
* If you scroll up to where TrmSer (along the right) approaches zero, we find a set of comment lines explaining that this routine (and therefore your error) is associated with this simulation of a series VAV box:
[cid:image002.png at 01D68C10.8E243030]

* Most variables to be found in source subroutines are defined (for humans) in the companion source file EDTT.out:
* Some relevant excerpts helping with the above logic:

zn.CFMcd 1 0 AA(Jzn+476) Terminal flow, cold deck, cfm EDTCRD5729

zn.CFMind 1 0 AA(Jzn+480) Terminal flow, induced, cfm EDTCRD5733

zn.CFMt 1 0 AA(Jzn+482) Terminal flow, all sources, cfm EDTCRD5735

zn.dTfan 1 0 AA(Jzn+565) Fan temperature rise, F EDTCRD5809

zn.ModeTstat I 1 0 IA(Jzn+473) Thermostat control mode 0 deadband 1 passive EDTCRD5724

2 aux cool 3 terminal cool 4 overload EDTCRD5725

Heating is same but negative EDTCRD5726

zn;SizeTerminal I 1 0 IA(Jzn+385) Flag if terminal is unsized EDTCRD5653

zn.Tcd 1 0 AA(Jzn+515) Cold deck temperature, F EDTCRD5770

zn.Thd 1 0 AA(Jzn+517) Hot deck temperature, F EDTCRD5772

zn.Tsup 1 0 AA(Jzn+475) Supply T leaving terminal, entering zone, F EDTCRD5728


* It catches my eye that this particular set of IF/THEN logic may be exited early based on a flag which is determined by whether the terminal box is unsized.
* It may be possible to eliminate/avoid this error by either manually sizing some terminal boxes and/or allowing for auto-sizing (considering the path you're on when this error triggers).
* This could be the mechanism by which some have found this error "going away" by deleting and re-defining the system(s).
* The actual msgbomb error is called when there's a difference of at least 0.05 degrees F between
* the air leaving the terminal / entering the zone, , and
* the mixed temperature calculated by weighting cold deck / hot deck air, by airflow, then additionally considering fan heat.
* The latter is relatively self-explanatory, so this leads me to further understand the value . The preceding instance in the subroutine shows how this value is calculated before being used for comparison against the (mixed air + fan heat) temp:
[cid:image001.png at 01D68C16.BF3355B0]
* This line looks a lot like the old standby, Q = 1.08*CFM*dT, rearranged to solve for one of the temperatures
* Elsewhere within the TrmSer subroutine, I have confirmed my suspicions, and can better understand that is describing the temperature :
Qgross = ! terminal extraction TrmSer1527

BtuF = ! Supply heat transport factor TrmSer 22

* Where (from EDTT.OUT):

ah.Btuh/CFM-F 1 0 AA(Kah+207) Air heat transport, Btuh/CFM-F EDTCRD6197

zn.QtrmGross 1 0 AA(Jzn+577) Terminal extraction and diffuser, Btuh EDTCRD5821

zn.Tzone 1 0 AA(Jzn+508) Zone temperature, end of current hour EDTCRD5763

* So all told, I think I understand that the error thrown is a sanity check to ensure that the temperature of the air leaving the coils after gross heat extraction is relatively close (sanity check) to what you would expect after mixing airstream temps at the appropriate weighting, and accounting for fan heat.
* This leads me to suggest looking closely (for anything weird/unintuitive) at:
* Terminal fan inputs, perhaps somehow resulting in excess heat introduction?
* The temperatures associated with hot/cold airstreams entering the terminal box (as contextually fitting with the model inputs at hand)
* Is there zone or terminal coil/extraction capacity entered that's at-odds with the airflow sizing? If any of these aren't hard-entered, might need to provide these inputs.

Obviously this doesn't lead to a one-size fits all solution for everyone encountering this error (there are apparently multiple variables/inputs that could come into play), but it might be enough to distill a few dials to turn to find the solution. I hope this perspective is helpful!


[cid:image006.jpg at 01D68C21.70CA16B0]
Nick Caton, P.E., BEMP
Senior Energy Engineer
Energy and Sustainability Services
Energy Performance Contracting

913 . 564 . 6361
785 . 410 . 3317
nicholas.caton at
15200 Santa Fe Trail Drive
Suite 204
Lenexa, KS 66219

[cid:image008.png at 01D68C10.2FCC1E80]

Nicholas Caton2's picture
Joined: 2019-03-25
Reputation: 0


Thank you so much! I believe you've figured it out. I have zone cfm auto-sizing based on the system heat capacity and the ratio between OA and zone airflow. I'm going to dig into this through-out the week, and follow up with my solution once complete.

For anyone interested,

There's a FORTRAN manual which covers the language concepts here:

Ethan Seaman
Sustainable Design Analyst
t: 617.520.9288

eseaman413's picture
Joined: 2019-05-07
Reputation: 0