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

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

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?

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:

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

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

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 unique 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):

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:

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 will return the same integer (1971):

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:

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:

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

The string is “NO”
The command is a “WINDOW”
The keyword is “DIFFUSING-GLASS”

Note each of these is using quotation marks in the working 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:

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

Top