User Expression Window Width, Height as Function of Glass-Type

3 posts / 0 new
Last post

Hi All

Hoping this day find you all safe at home and healthy!

Having a LEED review head-ache. I need to change the way eQuest evaluates the assembly U-value for the proposed building.

I have 12 window types with variations in glazing, dimensions and # of mullions. The way I see it now easiest to assign each window type as a "Glass-Type" and then do an expression for height, width and frame width for each type.

Is there a way to do Height as function of Glass-Type..... the following is not working for me.

switch(#L("GLASS-TYPE"))
case "GT1" : 12
case "GT3" : 8
case "GT4" : 4
default : #@##!!
ENDSWITCH

The problem is that default : is required and all cases end up being the default.

Any Ideas?

Thanks
Melissa

Melissa Crowe, LEED AP, BEMP
Senior Mechanical/Energy Engineer

161 Worcester Road, Suite 305
Framingham, MA 01701
O: 508.647.9200 x1225
C: 978.204.2559
cmta.com

Melissa
Melissa Page Crowe's picture
Joined: 2011-09-30
Reputation: 1

You've got this, and you've stumbled into a great question!

The issue here, as you might imagine, is that this piece of your switch statement: #L(GLASS-TYPE") is not returning any of the text strings you are using for your cases ("GT1", "GT3", etc.). Let's explore this.

This dummy model has 3 glass types defined:

[cid:image001.png at 01D60DE5.622F7EC0]

What happens if I enter #L(GLASS-TYPE") in for something like the height input?

[cid:image002.png at 01D60DE5.DFB289A0]

Hmm. What happens if I leave that expression in place but change the glass type?

[cid:image003.png at 01D60DE5.DFB289A0]

Neat! (please, hold your applause!!!)

What we're seeing here is that each glass type (and in fact, every component of your model) has a unque number mapped to it. This number is called the symbol index.

Before going deeper, let's apply this to a switch statement to confirm understanding (yep, this works as expected if you toggle the glass type dropdown):

[cid:image010.png at 01D60E37.C2905F80]

This is frankly what most doe-2 defaults look like in my experience, but we can incrementally improve end-user readability by inserting some comments. These have no effect on the function of the expression, but I feel it's a good practice for leaving yourself/others a breadcrumb trail whenever a custom expression isn't totally intuitive:

[cid:image004.png at 01D60E38.7A4136E0]

I think this is as close as I can get to your original intended form, using a switch statement, but we aren't machines and it would be *nice* to use strings per your query. We can (sorta) get there!

The symbol index is a mysterious thing that even today I wonder at sometimes (I may not be qualified to teach this), but if you take away one thing from this post, know that the main trick to bridging the gap between "textual inputs" and "index numbers of things" in your expressions is to use the #SI() or #SymbolIndex() wrapper.

An expression like this wil return the same integer (1971):

[cid:image007.png at 01D60DEA.D2397EA0]

A lot is going on here. To unpack, let's first take a look at a local example from the same input screen. Through the expression definition dialog, I can load up the doe-2 default expression that results in the default (green) "No" input for the "Diffusing:" dropdown. Let's take a look:

[cid:image005.png at 01D60DE7.E26CB5B0]

This expression is looking to the selection made/defaulted for the locaql WINDOW-TYPE to determine whether to default to either "YES" or "NO" for the keyword "DIFFUSING-GLASS." Notice this #SI wrapper is used in every place you'd normally/intuitively name something with a string like "NO" or "YES." In doe-2 reference manual terms, this pattern is described as follows:

[cid:image008.png at 01D60DF4.7C04D0C0]

To help remember/understand this pattern of "string, command, keyword" let's observe what the previous example input looks like in an INP file:

[cid:image006.png at 01D60DE8.4824E6C0]

The string is "NO"

The command is a "WINDOW"

The keyword is "DIFFUSING-GLASS"

Note each of these is using quotation marks in the wokring examples illustrated. I forget those a lot, personally.

So... armed with this knowledge, we can assemble an example/template resembling your actual request using if/then statements:

[cid:image009.png at 01D60E34.515AED10]

Not as clean as a switch statement, but gets the job done. My preference would probably lie with using integers per the previous example, using comments to help my human brain interpret each case.

I don't know if it's possible to arrive at something quite like your original intent however, with textual representations of symbols like "GT1" used for the case arguments. While I have seen and used many cases of switch statements based on C-ACTIVITY-DESC using 4-character string blocks for the case options, I think that might be a special snowflake exception to the rule in the help files: the thing following "case" should be an integer. Maybe I'm missing something on this front, in which case I hope someone will take the time/effort to educate me/us!

Hope this is hepful!

~Nick

------------------------------------------------------

Nick Caton, P.E., BEMP

Senior Energy Engineer

Energy and Sustainability Services

Schneider Electric

D 913 . 564 . 6361

M 785 . 410 . 3317

E nicholas.caton at se.com

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

Hi Melissa,
I hope you are doing well!
Try this instead, where the case number corresponds with the number order in which they appear in the input file:

switch(#SV(#L("GLASS-TYPE")))
case 1 : 12 $ GT1
case 2 : 8 $ GT3
case 3 : 4 $ GT4
default : 10
endswitch

LLOP.
~Bill

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