Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forward Translator Issues for UnitarySystemPerformance:Multispeed #5277

Closed
ChristopherCaradonna opened this issue Oct 22, 2024 · 1 comment · Fixed by #5278
Closed

Forward Translator Issues for UnitarySystemPerformance:Multispeed #5277

ChristopherCaradonna opened this issue Oct 22, 2024 · 1 comment · Fixed by #5278

Comments

@ChristopherCaradonna
Copy link

Issue overview

I am seeing a few issues with the forward translator for the UnitarySystemPerformance:Multispeed object. Some cause simulation failure, while others impact the intended operation of the system.

Current Behavior

(1) The Heating (or Cooling) Speed Supply Air Flow Ratio X fields seem to appear only to the highest speed of cooling, rather than the highest speed of cooling or heating. This can result in speed levels being excluded from operation. The coil objects contain all appropriate speed data - the issue appears contained to the UnitarySystemPerformance:Multispeed object.

Example where Number of Speeds for Cooling > Number of Speeds for Heating
image

Example where Number of Speeds for Heating > Number of Speeds for Cooling
image

(2) When there are more cooling speed levels than heating speed levels, the Heating Speed Supply Air Flow Ratio X fields for the speed levels above the number of speeds for heating are left blank, causing simulation failure. According to the documentation, these fields for speeds higher than the "number of speeds" should still be articulated. (See image above where Number of Speeds for Cooling > Number of Speeds for Heating).

Expected Behavior

The number of Heating (or Cooling) Speed Supply Air Flow Ratio X fields should match the higher of the Number of Speeds for Heating and Number of Speeds for Cooling. And any speed level above the Number of Speeds for Heating/Cooling should be populated with a 1.

Steps to Reproduce

  1. Define an OpenStudio that uses multispeed heating and cooling coils in a unitary system. One instance should have more cooling stages, and the other should have more heating stages.
  2. Run the model or forward translator to get the resulting IDF.
  3. Examine the UnitarySystemPerformance:Multispeed objects to see the described behavior.

Example OSM and resulting IDF when Num Speeds Heating > Num Speeds Cooling:
in_MoreHeatingSpeeds.osm.txt
in_MoreHeatingSpeeds.idf.txt

Example OSM and resulting IDF when Num Speeds Cooling > Num Speeds Heating:
in_MoreCoolingSpeeds.osm.txt
in_MoreCoolingSpeeds.idf.txt

Possible Solution

I don't know if this is the issue, but the code below shows the maxStages variable getting set first by heating and then the same variable name set by cooling before being used in the for loop that follows. Because cooling is set second, that could explain why the number of Speed Supply Air Flow Ratio X fields seems to follow the number of speeds for cooling.

https://github.com/NREL/OpenStudio/blob/develop/src/energyplus/ForwardTranslator/ForwardTranslateAirLoopHVACUnitarySystem.cpp#L483-L532

Details

Environment

Some additional details about your environment for this issue (if relevant):

  • Platform (Operating system, version): Windows
  • Version of OpenStudio (if using an intermediate build, include SHA): OpenStudio 3.8.0

Context

These errors limit a user's ability to model multispeed systems with different numbers of heating/cooling speeds. Getting this to work properly requires edits to the IDF, which is not realistic for many applications. We are using these objects for modeling measure scenarios in ComStock.

@ChristopherCaradonna ChristopherCaradonna added the Triage Issue needs to be assessed and labeled, further information on reported might be needed label Oct 22, 2024
@joseph-robertson
Copy link
Collaborator

I wonder if there's any overlap here with #4964 ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment