E: User Expression for Infiltration Neutral Zone Height

2 posts / 0 new
Last post

Great question Melissa!

For clarity - your screen snip and description leads me to believed we're discussing the following DOE-2 Default expression - let me know if that's off:
[cid:image003.png at 01D5FC51.7CEC5030]
This switch statement checks the local input for the Infiltration Method (INF-METHOD, "Crack" per the above example), and then will return "n/a" in the interface if anything is selected other than case 2, which happens to be "Crack." As a fun aside, there are many cases in the doe-2 defaults and with custom expressions by my peers where there are no notes in place to help someone figure out what each case is intended to be. A strategy I will often employ to "reverse engineer in place" involves modifying such an expression like this:
[cid:image005.png at 01D5FC51.7CEC5030]
After these edits, you can toggle the thing being referenced in the first line of the switch statement (INF-METHOD in this case) to observe the outcome in the same view. For efficiency I'd typically keep a copy of the original expression on the side to paste back in later.

As for your actual question... I would think the expression through in a few steps. The answer to your question will vary based on how the model was constructed (spefically whether FLOORs are used, so I'm presenting a series of observations to lead me to the right spot for a model which happens to be generated using the latest DD wizards.

First, let's assert what we're looking for out of this expression. You've already done this for us, but for immediate reference:

((Parent("Z")-0)+Local("Height")/2)*-1+(BH/2 - BG)

Where:
BH = Building Height
BG = Total of Below Grade FL to FL Height

I would just approach this from left to right. First up is to figure out which inputs to reference to determine the absolute (from ground level) height of the SPACE. You have already nailed it descriptively as "Parent("Z")," but not everybody's model will land there as the correct answer, and I'd like to answer for those in the classroom who aren't yet able to intuit stuff like this, so let's show how we determine that:

* We're working on an expression for infiltration, which is categorically a SPACE input. We'll therefore start our search for inputs of interest with the local SPACE. Skimming the inputs available for a 2nd story space in my wizard dummy model, I observe the local Z input is zero (same case for all of my spaces), so that input can't be used to derive the absolute height (Z) of the space...

[cid:image010.png at 01D5FC51.7CEC5030]

* I do however observe a floor-to-ceiling height which may come in handy later. Aside: I have seen models where the local SPACE Z inputs reflect absolute height relative to the ground, but I don't think you'll encounter that with any models borne from eQuest wizards in recent years.
* So, we go one level up in the component tree, to investigate the parent FLOOR:

[cid:image011.png at 01D5FC51.7CEC5030]

* The Floor Z value (highlighted yellow) is verifiably the absolute height we are looking for. I've also highlighted values in blue for the floor to floor and floor to ceiling heights, which with wizard-borne models are used to automate the SPACE height and vertical SURFACE height inputs for every component underneath the floor in the Component Tree (by default, until you override with manual inputs). One or both of those may be of interest down the line.
* For building the expression, we need to know exactly what these inputs look like in the INP file. There are a few ways to verify this (including looking directly at the INP), but I will typically first right click the input field and observe either the reference manual entry or "View Default/Range..." in the context menu:

[cid:image012.png at 01D5FC51.7CEC5030]

* Considering exact capitalization/spelling are important, I'm jotting down the 3 inputs of interest can be expressed from a child SPACE as
* #P("Z")
* #P("FLOOR-HEIGHT")
* #P("SPACE-HEIGHT")
* So, back at my space, I can firstly test the above inputs to make sure they produce the expected numbers and not error (they do)
[cid:image013.png at 01D5FC51.7CEC5030]

* Then, I can construct some math to work out the absolute height of the middle of the conditioned space

[cid:image014.png at 01D5FC51.7CEC5030]

* The rest of the expression you have there is looking to express this elevation in relation to a neutral pressure level (NPL) = BH/2 - BG. While the NPL should be a constant for within any given building/model, I don't think it's possible to automate that math from within a SPACE expression short of developing and utilizing global parameters containing values for BH & BG. Very much a procedural possibility, but outside the realm of what most users would handle on a regular basis. I would advise just doing the (simple) math on the side, and plan to manually punch the NPL into your custom expression with every project:
[cid:image015.png at 01D5FC51.7CEC5030]

* Note I'm being deliberate here in ensuring centerlines above the NPL are expressed as a negative distance, whereas centerlines below the NPL will express as positive, in line with the associated reference manual entry for NEUTRAL-ZONE-HT:

[cid:image016.png at 01D5FC51.7CEC5030]

* If you wish to retain the behavior of the original switch statement (displaying as 'n/a' when anything other than "Crack" is selected, you could patch your math into the associated switch case like this:

[cid:image017.png at 01D5FC51.7CEC5030]

That pretty much wraps it up, though I should address that while I didn't use #P("FLOOR-HEIGHT") for this example, that may actually be the value some would want to use depending on the context. If your conditioned space volume is pretty well exposed to infiltration/exfiltration from the full floor to floor exposure, as is generally the case when glazing extends above a drop ceiling line, and arguably in many more cases where the ceiling plenum isn't really isolated much from the conditioned volume or return air path, then you might really consider substituting the FLOOR-HEIGHT to bump the centerline of the local space up a bit.

I'd also mention to be mindful about applying an expression like this everywhere in a model... I haven't done enough stack effect modeling personally to make a recommendation, but you might consider/investigate whether the simulated infiltration volumes are accurate in aggregate when applying something like this to core spaces (that do not feature perimeter exposures).

~Nick

[cid:image018.jpg at 01D5FC51.7CEC5030]
Nick Caton, P.E., BEMP
Senior Energy Engineer
Energy and Sustainability Services
Energy Performance Contracting
D
M
E

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

[cid:image006.png at 01D5FC46.F1E69B30]

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

Nick

Yes You are addressing my question in rather wonderful detail. Oh my! this belong in the infiltration chapter in a text book/ reference I'd love to have at my elbow all day! You really should write and publish an eQuest Real Book! I like the sleuthing method of to find the switch case reference as well as the break it down approach for the referenced parameters.

Models using crack method don't have infiltration in the Core spaces as you define the infiltration coefficients only for the walls and windows so there is no problem setting this default.

Gratiz Mille

Melissa

Melissa Crowe, LEED AP, BEMP
508-647-9200 ext. 1225

Melissa

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