`maximumFractionofOutdoorAirSchedule` lower than `minimumOutdoorAirFlowRate` on `Controller:OutdoorAir` object

Open
#421 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Stale
Tech stack
ruby
Domain
backend

Research direction

Start with the ComStock model generation for the restaurant PSZ Controller:OutdoorAir object and compare its minimum outdoor air flow with the maximum-fraction schedule. Then inspect the referenced openstudio-standards Standards.AirLoopHVAC.rb lines 3886-3894 to trace where the 70% limit is set. Done means identifying whether the conflicting values are intentional or correcting their interaction.

Written by the indexing model from the issue text.

Description

I was debugging a model and found this weird. below is my "theory":

  • it was comstock's full service restaurant model that has PSZs in dining

  • this below is one of the PSZ's controller outdoor air obj:

Controller:OutdoorAir,
  Zone FullServiceRestaurant Dining A  - Story ground PSZ-AC OA System Controller, !- Name
  Zone FullServiceRestaurant Dining A  - Story ground PSZ-AC Relief Air Node, !- Relief Air Outlet Node Name
  Zone FullServiceRestaurant Dining A  - Story ground PSZ-AC Supply Inlet Node, !- Return Air Node Name
  Zone FullServiceRestaurant Dining A  - Story ground PSZ-AC Mixed Air Node, !- Mixed Air Node Name
  Zone FullServiceRestaurant Dining A  - Story ground PSZ-AC Outdoor Air Node, !- Actuator Node Name
  0.87058909070243,                       !- Minimum Outdoor Air Flow Rate {m3/s}
  1.05252208609867,                       !- Maximum Outdoor Air Flow Rate {m3/s}
  NoEconomizer,                           !- Economizer Control Type
  ModulateFlow,                           !- Economizer Control Action Type
  28,                                     !- Economizer Maximum Limit Dry-Bulb Temperature {C}
  64000,                                  !- Economizer Maximum Limit Enthalpy {J/kg}
  ,                                       !- Economizer Maximum Limit Dewpoint Temperature {C}
  ,                                       !- Electronic Enthalpy Limit Curve Name
  ,                                       !- Economizer Minimum Limit Dry-Bulb Temperature {C}
  LockoutWithCompressor,                  !- Lockout Type
  FixedMinimum,                           !- Minimum Limit Type
  Zone FullServiceRestaurant Dining A  - Story ground PSZ-AC_night_ventcycle_schedule, !- Minimum Outdoor Air Schedule Name
  ,                                       !- Minimum Fraction of Outdoor Air Schedule Name
  ems_Zone_FullServiceRestaurant_Dining_A____Story_ground_PSZ_AC_maxOASch, !- Maximum Fraction of Outdoor Air Schedule Name
  Controller Mechanical Ventilation 1,    !- Mechanical Ventilation Controller Name
  ,                                       !- Time of Day Economizer Control Schedule Name
  No,                                     !- High Humidity Control
  ,                                       !- Humidistat Control Zone Name
  1,                                      !- High Humidity Outdoor Air Flow Ratio
  Yes,                                    !- Control High Indoor Humidity Based on Outdoor Humidity Ratio
  BypassWhenWithinEconomizerLimits,       !- Heat Recovery Bypass Control Type
  InterlockedWithMechanicalCooling;       !- Economizer Operation Staging
  • so from above, min OA flow rate is 0.87058909070243 m3/s. and in terms of fraction, this is 82% from max flow

  • and in the same object, there's a max fraction of OA schedule field showing a schedule called ems_Zone_FullServiceRestaurant_Dining_A____Story_ground_PSZ_AC_maxOASch

  • if I look further into this schedule, I see 0.7 (70%) as the maximum OA fraction value:

Image
  • so what this means is that, maximum OA fraction (70%) is lower than minimum OA fraction (82%).

  • and in the simulation results, 70% OA was drawn and 82% was never reached.

  • and I was thinking maybe,

    • we added like super high OA requirement for this dining which is like 82% as MIN
    • but standards has it's own implementation of 70% as MAX (probs coming from here)
    • so two are maybe not chiming well
Dominant language
Ruby
Stars
54
Forks
28
Avg merge
3d 23h
Merged PRs (30d)
5

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from NatLabRockies/ComStock

All issues in NatLabRockies/ComStock

Similar issues

More Ruby issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.