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

Fan System Operating Schedule #1441

Open
JacksonJ-KC opened this issue Jul 31, 2024 · 4 comments
Open

Fan System Operating Schedule #1441

JacksonJ-KC opened this issue Jul 31, 2024 · 4 comments
Assignees
Labels
bug Something isn't working question Further information is requested section4

Comments

@JacksonJ-KC
Copy link
Collaborator

In the function get_aggregated_zone_hvac_fan_operating_schedule() we assume that the schedule only includes 0 or 1. Any value that is not 1 gets rewritten as 0. I would think that fan schedules in most simulation tools will be either 0 or 1 but I am not sure that it will always be the case. There is no note in the schema that says the schedule values must be 0 or 1.

@JacksonJ-KC
Copy link
Collaborator Author

In rule 4-11 when we compare the fan operating schedules between the baseline and proposed, a schedule that looks like [0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9] will be marked as matching a schedule that looks like [0, 0, 0, 0, 0, 0, 0]

@KarenWGard
Copy link
Collaborator

In EnergyPlus, for a fan operating schedule, any values greater than 0, will be treated as ON. Only 0 values are treated as off, so [0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9] would operate like: [1, 1, 1, 1, 1, 1, 1] in EnergyPlus

@JacksonJ-KC - how is this treated in eQuest?

Does anyone know how it's treated in IES or other platforms?

Regardless of whether the function gets changed, we should clarify the note in the schema about how this entry is used.

@JacksonJ-KC
Copy link
Collaborator Author

This assumption where any values greater than 0 get reassigned to 1 makes more sense to me and I think would address the issue we are seeing in Rule 4-11.

eQUEST fan schedules can be somewhat complicated. They use ON/OFF/FLAG schedule types which means the values are either 0, 1, -1, or -999. -999 has special meaning depending on the system type and depending which version of DOE-2 is being used. The eQUEST RPD generator may try to interpret the FLAG values and assign either a 0 or a 1. (TBD)

DOE-2 help text pasted below as FYI:

FAN-SCHEDULE
Takes the U-name of a schedule (TYPE=ON/OFF/FLAG) that indicates when the system's fans (supply, return, and exhaust) are on or off. If not entered the program assumes the fans are always available when needed. The schedule values have the following meaning (but see further below for dedicated outdoor air systems):

· If the value is 1, the fans are on.

· If the value is 0, the fans are off but may be turned on by NIGHT-CYCLE-CTRL if zone temperatures warrant it.

· If the value is -1, the fans are not permitted to be on for any reason.

· DOE-2.2 feature not currently implemented in DOE-2.3 A value of -999 defines an optimum start period of up to six hours. During this period the fan start time is delayed until the fan run time matches that needed to meet the desired zone temperatures. Notice that this decision is made on an hourly basis, whereas in the real world it is made on much smaller increments (ten minutes or less). For the hourly calculation, the number of hours needed to bring each zone on the system up or down to its set point is estimated. If the number of such hours for the majority of the zones is equal to or greater than the number of hours remaining in the start period, the fans are turned on. The target zone temperatures used in the calculation are the heating and cooling set point temperatures given in HEAT-TEMP-SCH and COOL-TEMP-SCH that correspond to the first hour following the scheduled optimum start period.

Notes on optimum start simulation:

DOE-2.2 feature not currently implemented in DOE-2.3

  1. The optimum start period must be less than or equal to six hours.
    
  2. The fan must be scheduled on using the value 1 for the first hour following the optimum start period.
    
  3. An optimum start period must be defined within a contiguous set of hours. Therefore, the optimum start period cannot begin before 1:00 am. For example, the following is not valid:
       (1,4) (-999)  (5,18) (1)  (19,22) (0)  (23,24) (-999)
    
  4. Zones with Trombe walls should not be used with optimum start.
    
  5. Optimum start will not work well on systems serving zones that are not evenly balanced with respect to their start up duration. 
    
  6. If the system is under-sized, or cannot supply sufficient air at its minimum or maximum supply temperature, the start time will be delayed too long and there will be excessive hours reported with loads not met. A VAV system with a low MIN-FLOW-RATIO and a thermostat type that is not REVERSE-ACTION fits this description.
    
  7. Results for run periods of just a few days will be poorer those for longer run periods since the program attempts to learn (simulating feedback) to improve on its estimating abilities.
    
  8. During hours of the optimum start period in which the fan has not been started, the system will behave as if the fan schedule that hour were (0). Thus, the fan can cycle on during this period if NIGHT-CYCLE-CTRL is used.
    
  9. For air-to-air heat pumps, where the primary interest is minimizing the use of electric resistance heating during start-up, it is suggested that the set point temperature be ramped upward. This should start with the first hour during a normal fan start period.
    

Operation of the fans in a dedicated outdoor air system (DOAS) is defined differently than for other system types:

· If the fan schedule is not defined, or has a value of -999., the DOAS fans operate whenever one or more of the served systems has a fan schedule value of 1. The DOAS fans do not operate if the of the served systems are activated via NIGHT-CYCLE-CTRL or optimum start.

· If the value is 0, the DOAS fans are off; regardless of the fan settings of the served systems. If a served system is operating when the DOAS fans are off, then no outdoor air is delivered.

· If the value is 1, the fans are enabled. If the DOAS supplies air directly to the zones of a served system, outdoor air will be delivered to the zones even when the fan of the served system is scheduled off. If the DOAS is attached to the mixed air section of a served system, outdoor air will be delivered any time the fans of the served system are enabled; including during NIGHT-CYCLE-CTRL activation or optimum start.

· If the value is -1, the meaning is the same as a value of 0; the DOAS is off

@JacksonJ-KC JacksonJ-KC added the bug Something isn't working label Jul 31, 2024
@KarenWGard
Copy link
Collaborator

KarenWGard commented Jul 31, 2024

Hi Jackson - I realized I oversimplified re: EnergyPlus - in EnergyPlus, the fans themselves have schedules, where a 0 value means they are forced off, and anything greater than zero, fans are allowed (but not forced) on. Fans can be controlled by a system-level fan schedule (0 value means cycling and 1 means forced on), but can also be controlled to meet the airflow of the system, which EnergyPlus calculates based on loads, minimum airflow, minimum outdoor airflow, etc. There is also AvailabilityManagerNightCycle, which can override the fan's forced-off schedule in order to meet a heating and / or cooling load from any of the zones served, or based on a load from a specified control zone. It can get complicated to coordinate everything.

In conclusion... I think we have agreement between at least two tools that anything greater than zero is equivalent to 1 (truthy). This is how the function get_zone_eflh treats the FanSystem.operation_schedule. I think we need to leave it up to the translators created by each tool to deal with the complexity, but I am in agreement that get_aggregated_zone_hvac_fan_operating_schedule() should be updated.

The notes on operation_schedule need to be updated for clarification. As this is the FanSystem operation schedule, I think that a value that is >0 should mean that the fan is scheduled ON (not cycling). A value that is <= 0 should mean that the fan that is either forced off, or allowed to cycle on to meet loads.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working question Further information is requested section4
Projects
None yet
Development

No branches or pull requests

6 participants