Weird error by DOE2.2

5 posts / 0 new
Last post

Hello group.

I see to have a weird problem with my DOE2.2, and I can't find de way to
solve it.

Out of the blue, DOE2.2 started to print the following "format dump header"
(or a similar one) on (almost) each report page (LV or LS, PV or PS, SV or
SS). Below is a sample from the BEPS report.

***************************************
REPORT- BEPS Building Energy Performance
WEATHER FILE- Montreal Internation
----------------------------------------------------------------------------
-----------------------------------------------------
PRT3 failure @ 88010, IOSTAT: 62 Report: 34 Format: 1 Iuniq: 837
Kommnd: 1 Nwrit: 80
Format Dump:
(/

' TASK MISC SPACE SPACE HEAT
PUMPS',
' VENT REFRIG HT PUMP DOMEST EXT'/

' LIGHTS LIGHTS EQUIP HEATING COOLING REJECT &
AUX',
' FANS DISPLAY SUPPLEM HOT WTR USAGE TOTAL'/

' ------- ------- ------- ------- ------- -------
-------',
' ------- ------- ------- ------- ------- --------')

EM1 ELECTRICITY
MBTU 327.2 0.0 321.0 625.9 420.6 36.5 232.9
556.2 0.0 0.0 0.0 129.9 2650.1

FM1 NATURAL-GAS
MBTU 0.0 0.0 0.0 559.9 0.0 0.0 0.0
0.0 0.0 0.0 283.5 0.0 843.4
PRT3 failure @ 88006, IOSTAT: 62 Report: 34 Format: 3 Iuniq: 837
Kommnd: 1 Nwrit: 15
Format Dump:
(' ======= ======= ======= ======= ======= =======
=======',
' ======= ======= ======= ======= ======= ========'//

5x, 2A4, -6P 12F9.1,F10.1)

TOTAL SITE ENERGY 3493.54 MBTU 45.8 KBTU/SQFT-YR
GROSS-AREA 45.8 KBTU/SQFT-YR NET-AREA
TOTAL SOURCE ENERGY 8793.82 MBTU 115.2 KBTU/SQFT-YR
GROSS-AREA 115.2 KBTU/SQFT-YR NET-AREA

PERCENT OF HOURS ANY SYSTEM ZONE OUTSIDE OF THROTTLING
RANGE = 1.62
PERCENT OF HOURS ANY PLANT LOAD NOT SATISFIED
= 0.00
HOURS ANY ZONE ABOVE COOLING THROTTLING RANGE
= 81
HOURS ANY ZONE BELOW HEATING THROTTLING RANGE
= 61

NOTE: ENERGY IS APPORTIONED HOURLY TO ALL END-USE
CATEGORIES.

***************************************

It doesn't seem to be related to the warnings / errors / "curve out of
bounds" warnings / etc. I may get when running a model.

At first, I thought it was because I was having problem with my new model
definition (something wrong with some parameters). But I have this "format
dump" header even with other models which were printing out correctly a few
days ago.

I uninstalled eQUEST and tried with another version of the software,
thinking I might have a corrupted installation; no change.
I tried with a different version of eQUEST; no change.

Any ideas? It's making reading the reports difficult, but I fear more it may
be hiding something more serious.

Regards,

Fr?d?ric Genest, ing.

FredGenest's picture
Offline
Joined: 2015-08-21
Reputation: 0

Hello Frederic,

Equest is usually pretty stable unless you fiddle with it too much. Don't forget it is a FORTRAN program that has fixed limits on the numbers of various entities, for example zones, walls, windows, etc. (i.e., see the manual).

Or another example that can cause unexpected outputs can be caused by entering a building into Equest, saving the file and then reopening and re-running the file.

For example, saving the Equest input file and re-editing the building prior to running is usually a stable operation if you stay within boundaries.

However, running a building in Equest, saving and editing the input file, then running again in Equest can cause indigestion for Equest, requiring the file to be run in DOE-2.2 after manually editing the Equest input file to make it work. Specifics on this feature can be obtained by JJH & Associates, or your local Equest super-user.

Jeff

8=!? 8=)? :=)? 8=)? ;=)? 8=)? 8=(? 8=)? 8=()? 8=)? 8=|? 8=)? :=')? 8=) 8=?
Jeff S. Haberl, Ph.D.,P.E.inactive,FASHRAE,FIBPSA,......jhaberl at tamu.edu
Professor........................................................................Office Ph: 979-845-6507
Department of Architecture............................................Lab Ph:979-845-6065
Energy Systems Laboratory...........................................FAX: 979-862-2457
Texas A&M University...................................................77843-3581
College Station, Texas, USA, 77843.............................http://esl.tamu.edu
8=/? 8=)? :=)? 8=)? ;=)? 8=)? 8=()? 8=)? :=)? 8=)? 8=!? 8=)? 8=? 8=) 8=0

Jeff Haberl2's picture
Offline
Joined: 2011-10-02
Reputation: 200

Hi again.

A temporary fix that seems to be working for me is to close eQUEST, clean the project folder of everything except *.pd2 and *.inp files, and restart the computer. Cleaning RAM and forcing the DLLs to reload seems to clean up the problem. But it reappears after a while (letting the computer runs for too long counts toward that too). May not work everytime, but seems reliable enough for now.

Can?t wait for the permanent fix though.

Frederic.

De : Jeff Hirsch [mailto:james.j.hirsch at gmail.com]
Envoy? : 7 f?vrier 2016 17:28
? : Fr?d?ric Genest ; equest-users at lists.onebuilding.org
Objet : Re: [Equest-users] Weird error by DOE2.2

This is a known problem caused by the an unexpected interaction between the Intel compiler runtime library linked into the DLL versions of DOE used in eQUEST and the DOE-2 report generator code used to produce the .sim file. A fix has been implemented into the next release of the DOE-2 DLL?s linked into 3.65; this new 3.65 release is almost through internal testing and is expected to be available in the next month. The problem is not experienced in the exe versions of stand-alone DOE-2. There is no workaround except sometimes selecting a reduced or alternative list of output reports may get around the problem. This problem only impacts the .sim files produced by DLL versions of DOE-2 and does not impact the binary DOE-2 results files used to product eQUEST graphics of other reports.

Details of the problem (only useful for developers): The Intel runtime system reads past the end of the output format for a report and gets confused finding parts of other formats for other reports in later portions of the array, and issues the error. So the error is not caused by the actual line of data being written to the report but rather other not visible information that was not expected to be seen by the runtime system. The fix is to ensure that the character array where the report format is stored when passed to the runtime library is blank filled after or ends at the end of the report format being processed so that the runtime system stops processing when the format ends rather than continues processing after the format ends until it finds the end of the array passed.

_____

Jeff Hirsch
James J. Hirsch & Associates
12185 Presilla Road - Camarillo, CA 93012-9243 USA
phone: (805) 553-9000 mobile: (805) 532-1045 fax: (805) 532-2401
email: James.J.Hirsch at gmail.com

FredGenest's picture
Offline
Joined: 2015-08-21
Reputation: 0

I generally resort to uninstalling eQuest, rebooting the computer then re-installing eQuest. It happens every 3 months or so.

[cid:image003.png at 01D09C46.E75BA0D0]
Christopher Jones, P.Eng.
Senior Engineer

WSP Canada Inc.
2300 Yonge Street, Suite 2300
Toronto, ON M4P 1E4
T +1 416-644-4226
F +1 416-487-9766
C +1 416-697-0056

www.wspgroup.com

Jones, Christopher's picture
Joined: 2015-06-11
Reputation: 0

I tried that too.. But my problem appears every few days (even hours sometimes).

Salutations, / Regards,

De : Jones, Christopher [mailto:Christopher.r.Jones at wspgroup.com]
Envoy? : 11 f?vrier 2016 13:40
? : Fr?d?ric Genest ; 'Jeff Hirsch' ; equest-users at lists.onebuilding.org
Objet : RE: [Equest-users] Weird error by DOE2.2

I generally resort to uninstalling eQuest, rebooting the computer then re-installing eQuest. It happens every 3 months or so.

Christopher Jones, P.Eng.
Senior Engineer

WSP Canada Inc.

2300 Yonge Street, Suite 2300

Toronto, ON M4P 1E4
T +1 416-644-4226

F +1 416-487-9766

C +1 416-697-0056

www.wspgroup.com

FredGenest's picture
Offline
Joined: 2015-08-21
Reputation: 0