[Equest-users] Maximum number of expression dependency
Nicholas Caton
Nicholas.Caton at schneider-electric.com
Tue Aug 7 15:45:54 PDT 2018
Hi Sharad,
Mmmm it has been a long while since I had cause to crack open an ice cold can of v3.64! Refreshing (I seriously kinda miss this Windows 95-era GUI sometimes)!
I first notice, and I’m sure you know well – this is a BIG, complex model. For sheer time-efficiency on initializing/loading/simulation, I have to suggest while you are still in wizards development serious consideration for developing the different parts of this model as separate projects, then combining their results/outputs later. It will certainly help your productivity and sanity upon encountering and resolving issues like this.
The advice you found below to my eyes is specifically suggesting to increase the maximum number of expression dependencies from the default of 8 (which I note is reflected in the above errors). The line highlighted below is where in your PD2 you can play with that variable:
[cid:image005.png at 01D42E6F.0F9ECD20]
On changing 8 to 10, I find most of the errors referencing a maximum number of dependencies go away, though you are still stuck with many hits for an error taking the following form:
*ERROR*****[KEYWORD] in [ZONE OR SCHEDULE] has Maximum number of
expression dependency lists (999992) exceeded.
*ERROR****************************************************************************************
This error appears isolated to all manner of zonal and scheduling input instances in a block towards the end of your INP. I’ve attached the associated BDL for others to review and consider.
I suspect this could mean the wizards are hitting another size-related limit associated with the generation of zonal “hard inputs” and associated scheduling due to sheer size of this project. Perhaps reducing the number of shells covered in one file (in combination with that MaxExpDeps trick) may allow everything to load smoothly. Worthy of exploration.
The other thing catching my eye, and I would highlight for the community’s input as I’m coming up short, is that the first errors remaining after the above tweak reference inputs like BRINE-LOOP, BRINE-FLOW, and RINK-RESPONSE. I’m not sure how such keywords would normally (or accidentally) get engaged from the wizards, but if this means something to you perhaps undoing those associated inputs may help the wizards build the model as well. It sounds like refrigeration voodoo… Did I miss that you were perhaps using a release of the refrigeration version of eQuest to develop this project?
~Nick
[cid:image003.png at 01D42E6E.2E92F450]
Nick Caton, P.E., BEMP
Senior Energy Engineer
Regional Energy Engineering Manager
Energy and Sustainability Services
Schneider Electric
D 913.564.6361
M 785.410.3317
F 913.564.6380
E nicholas.caton at schneider-electric.com<mailto:nicholas.caton at schneider-electric.com>
15200 Santa Fe Trail Drive
Suite 204
Lenexa, KS 66219
United States
[cid:image004.png at 01D42E6E.2E92F450]
From: Equest-users [mailto:equest-users-bounces at lists.onebuilding.org] On Behalf Of Sharad Kumar via Equest-users
Sent: Tuesday, August 07, 2018 9:22 AM
To: equest-users <equest-users at lists.onebuilding.org>
Subject: Re: [Equest-users] Maximum number of expression dependency
[External email: Use caution with links and attachments]
________________________________
Hi Yasin,
The same kind of problem i was able to see some time back.
The problem was due to exceeding of number of points in the Wizard mode Screen -2.
achieved in the footprint shape.
The problem can be resolved if you reduce the number of vertices in Footprint shape in the Wizard Screen -2 by some approximations.
In my case of eQUEST-3.65 the number of vertices made can not exceed the number of 120. Might be you are doing in some older version.
Just try to reduce the number of vertices count and then asses the result.
Thanks,
Sharad.Kumar
Freelancer (Energy Simulation)
+91-9102906597
India.
.........................................................................................................................................
---------- Forwarded message ----------
From: Yasin Khan <yasinkhn683 at gmail.com<mailto:yasinkhn683 at gmail.com>>
To: equest-users at lists.onebuilding.org<mailto:equest-users at lists.onebuilding.org>
Cc:
Bcc:
Date: Mon, 6 Aug 2018 15:39:11 +0530
Subject: [Equest-users] Maximum number of expression dependency
Hi,
I am having a problem in my eQUEST model. It shows error "Maximum number of expression dependency lists exceededs". I assume that this is related to the model size. Then I found that You have solved this problem by some some workaround (below):
1. Editing PD2 file with the following lines -
DetailedModelEdits = 1
ProjTreeType = ( 1, 1, 1, 1, 1, 1 )
ProjTreeID = ( 10240000, 10081500, 10280021, 10640002, 10480018,
10280020 )
ProjTreeLabel = ( "...", "...", "...", "...", "...", "..." )
MaxExpDeps = 10
I don't know where exactly I should insert these lines? I just put these in PD2 file in the first paragraph before the "..".
2. Blast all "C-" keywords in "eQ Data>\DOE-2\BDLDft.dat". I do't understand this. Shoul I delete just "C-" words in that file or attached words too. For exmaple
"C-Schedule" should be changed to just "Schedule" or I have to delete the complete word "C-SCHEDULE".
And there are another solution which looks so complex to do:
- BDL source code mods to increase the limit of exp dep lists,
- removal of some fraction of the expressions contained in your INP
file, and/or
- the addition of Set-Default statements in your INP file that replace
additional BDL default expressions with static values or symbolic
selections.
I don't know how to do it?
So can you please help me in this
--
Yasin Khan<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fpub%2Fyasin-khan%2F72%2F727%2F5b5&data=02%7C01%7Cnicholas.caton%40schneider-electric.com%7C543eb954f2f6410cdfff08d5fc7135d5%7C6e51e1adc54b4b39b5980ffe9ae68fef%7C0%7C0%7C636692485524024776&sdata=0h68rPPjY8eGmSsiqdck4KxUlOksdyqKiHYtPmF5KVc%3D&reserved=0>
Senior Energy Specialist
AEON IBDC
(M)+91 8561010626
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20180807/31170935/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 255 bytes
Desc: image003.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20180807/31170935/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 8477 bytes
Desc: image004.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20180807/31170935/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oledata.mso
Type: application/octet-stream
Size: 7135 bytes
Desc: oledata.mso
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20180807/31170935/attachment-0008.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 43908 bytes
Desc: image005.png
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20180807/31170935/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AIIMS-Hospital.BDL
Type: application/octet-stream
Size: 9485125 bytes
Desc: AIIMS-Hospital.BDL
URL: <http://lists.onebuilding.org/pipermail/equest-users-onebuilding.org/attachments/20180807/31170935/attachment-0009.obj>
More information about the Equest-users
mailing list