Modeling VRFs and Heat Pumps

[connorjcantrell]

Improve representation of VRF systems and Heat Pumps, drawing from #581 and integrating concepts from previous PRs:

• Update VRF classes update vrf classes #344
• Heat Pump / Chiller Plant Model Heat Pump / Chiller Plant Model #257

[connorjcantrell]

@gtfierro @jbkoh How could we model a heat pump which is a split system? These definitions work well for a packaged unit, such as the illustrated "Air_Source_Heat_Pump":

However, a split system would have both a Condensing Unit and an FCU. This, too, is a Heat Pump:

[connorjcantrell]

In some sense, a split system is more of a "Heat Pump System", where as a packaged unit is a "Heat Pump Equipment"

[connorjcantrell]

We do have "Heat_Pump_Condensing_Unit", perhaps "Heat_Pump" class could be modified to "Heat_Pump_Packaged_Unit" for clarification.

[MatthewSteen]

I think the distinction between a packaged and split system just the location/relationships. Similar to how an RTU is just an AHU that hasLocation roof.

Package System > feeds > Zone
Split System Condenser Unit > feeds > Evaporator_Unit (do we have this?) > feeds > Zone

[connorjcantrell]

@MatthewSteen In the split-system example above, this would be achieved by using the Heat_Pump_Condensing_Unit > feeds > FCU

In this case, do you agree that Heat_Pump should be "Packaged Heat Pump"?

https://www.trane.com/residential/en/products/packaged-systems/heat-pump-packaged-systems/

[connorjcantrell]

Renamed "Heat Pump" to "Packaged_Heat_Pump" and added air/water/ground source to all condensing unit classes. In doing so, we can represent the same level of detail for both Packaged and Split System variations.
cbcc5d4

[connorjcantrell]

@gtfierro @jbkoh While while "Expansion Valves" and "Metering Devices" are often used interchangeably, a clearer distinction is beneficial. Expansion valves, such as the Thermostatic Expansion Valve (TXV), encompass functionalities beyond traditional valves. A TXV, for instance, adjusts refrigerant flow automatically, guided by a sensing bulb that reacts to temperature changes.

Similarly, capillary tubes, another form of metering devices, control refrigerant flow through a fixed orifice and do so without moving parts, relying on the pressure differential.

With that being said, Electronic Expansion Valves (EXVs) are closer to traditional valves. Being as though these are designed specifically for metering refrigerant and often containing much more than just a valve, I would prefer to classify this outside of the Valve class, as "Metering Devices" more accurately reflects their unique functionalities in HVAC systems.

Alternatively, we could define a Metering Device class in addition to Expansion Valves. Expansion Valve could be a subclass to both Valve and Metering Device. Capillary Tube could exclusively be a subclass to Metering Device, whereas TXV and EXV can be a subclass of both Metering Device and Expansion Valve.

[connorjcantrell]

@gtfierro Is it necessary to specify that 'connectedTo' is a superclass to 'feeds' and 'isFedBy'?

Something like:

rdfs:subPropertyOf :feeds, :isFedBy ;

[gtfierro]

In my intended design, feeds and isFedBy would both be subproperties of connectedTo, thinking about it more. I'm not sure this is what we actually want to do. If we were to follow this design, then any use of the feeds relationship would also imply the existence of a connectedTo relationship.

This raises the essential question, which is "does connectedTo communicate a bidirectional relationship, or a relationship where the directionality is not known?" If its the former, then connectedTo should be a sibling of feeds and isFedBy because it is altogether different. If its the latter, then connectedTo should be a superproperty of feeds and isFedBy

[connorjcantrell]

does connectedTo communicate a bidirectional relationship, or a relationship where the directionality is not known?

I intended to use connectedTo to imply a bidirectional relationship. However, considering your point, 'connectedTo' doesn't explicitly convey directionality.

Alternatively, what about FeedsAndFedBy?

[gtfierro]

We probably want both:

• "feedsAndFedBy" (we need a better name) for bidirectional. We want this to work for equipment as well as for spaces/locations
• "connectedTo" for a super property of feeds, isFedby, and feedsAndFedBy that means "we don't know the direction"

[connorjcantrell]

Though I do prefer to use Metering Device, I have renamed "Metering Device" to "Throttling Device" to avoid confusion with Brick's Meter class. Throttling device can refer to any component that restricts or regulates the flow of a fluid. It's not specific to refrigeration systems and can apply to various types of mechanical and fluid systems. Open to feedback on this, as I would prefer to use Metering Device if we didn't have a naming conflict.

[gtfierro]

I'm not familiar with the area, but this substitution seems fine for me. We could also go "Metering Device" and then add shackle rules to either Meter class or this class that detect when it's being used incorrectly.

[MatthewSteen]

I'm not either, but in general I always recommend/want terms to be rooted in a standard (ASHRAE, ISO, etc.). Does Throttling Device come from somewhere?

I see Throttling Valve in ASHRAE terminology (although it's not a standard nor are their standards required to use these).

Throttling Valve

valve used to restrict (throttle) the flow of fluid.

[connorjcantrell]

@gtfierro Ok, great to hear. In that case, I would prefer to call it "Metering Device". @MatthewSteen I was careful not to use the name "valve", due to the various metering devices used in practice, though I do agree that Throttling Device is a bit broad. If you're curious to learn more about metering devices, this is an informative article:
https://www.skillcatapp.com/post/a-complete-guide-to-metering-devices-fixed-modulating.

With the addition of metering device, Brick now has the ability to represent a complete refrigeration cycle using the following classes:

• Compressor
• Reversing Valve (if Heat Pump)
• Metering Device
• Evaporator Coil
• Condenser Coil

[MatthewSteen]

I strongly suggest basing the terminology on existing definitions/terms that are as close to canonical as possible so we're not "inventing" our own or basing them on a website. There are a lot of interchangeable terms used in industry but I think Brick should be using "authoritative" sources when it comes to its class names whenever possible.

I may have missed it, but what's the problem with using Throttling_Valve per ASHRAE terms instead of Metering_Device? If we use Throttling_Valve, then it fits nicely under the parent Valve class like Reversing_Valve.

If Throttling Device is too broad, why isn't Metering Device, which seems a bit general for this application (VRF)? I think "metering" implies measuring something like an electric or gas meter, which aligns with Brick's Meter class and ASHRAE terms.

metering

instruments that measure electric voltage, current, power, etc.

ASHRAE terms does have this entry, which seems to conflict a bit with its definition of metering.

refrigerant metering device

device that controls the flow of liquid refrigerant to an evaporator.

[connorjcantrell]

Agreed that reusing ASHRAE terms is ideal. Between the two, I would prefer "Refrigerant Metering Device".

Throttling_Valve is also a good alternative. However, Throttling Valve would only be able to represent modulating metering devices and would not be able to represent fixed metering devices.

[MatthewSteen]

I think we should be basing Brick's class names on an authoritative/canonical source (such as AHRI, ANSI, ASHRAE, ISO, IEE, etc.), not https://www.skillcatapp.com/.

[connorjcantrell]

100% agreed, I shared the article with you to explain the differences between fixed and modulating metering devices and how throttling valve does not encompass all metering devices.

I have renamed the class to refrigerant metering device per ASHRAE's definition:
https://terminology.ashrae.org/?entry=refrigerant%20metering%20device

[MatthewSteen]

A general comment here. Does it make sense for this PR to focus on just VRFs rather than trying to complete the larger/more complex Heat Pump issue?

Also, the Haystack Labs Working Group spent quite a bit of time developing the concept of Systems, which for the most part come from existing standards. The VRF concepts came from a separate VRF Systems Working Group.

https://project-haystack.org/doc/appendix/system

[connorjcantrell]

Thanks @MatthewSteen,

Does it make sense for this PR to focus on just VRFs rather than trying to complete the larger/more complex Heat Pump issue?

Yes, I am addressing both VRFs and Heat Pumps in this PR.

Regarding the alignment with Haystack's VRF concepts, here are the equivalent classes:

vrf-outdoorUnit -> Condensing_Unit
vrf-outdoorUnit-coolingOnly -> Cooling_Only_Condensing_Unit
vrf-outdoorUnit-heatPump -> Heat_Pump_Condensing_Unit
vrf-outdoorUnit-heatRecovery -> Heat_Recovery_Condensing_Unit
vrf-indoorUnit -> Fan_Coil_Unit
vrf-indoorUnit-fcu -> also Fan_Coil_Unit
branchSelector -> Branch_Selector
vrf-refrig-plant: Haystacks defines this as "Multiple outdoor units can be connected, and the refrigerant plant covers all the connected outdoor units". In Brick, this can be achieved by connecting multiple Condensing Unit's under the same VRF_System

Within the Haystack thread, Leroy Simms stated the following:

I am in favor of all the general concept presented, my only concern would be the indoorUnit and outdoorUnit tags. In my opinion the outdoorUnit tag could be misleading in certain situations.

I, along with others, agree with this perspective, and have chosen not to introduce Outdoor and Indoor for this reason.

Please let me know if you have any concerns with the implementation/ alignment. Thanks!