Question-and-Answer Resource for the Building Energy Modeling Community
Get started with the Help page
Ask Your Question

Revision history [back]

We are actively trying to make sure the feature gap between OS and E+ is almost negligible. That doesn't mean that we will expose every E+ object one for one in OpenStudio, but we are monitoring the feature set of E+ and trying to make sure that we capture the features via at least one modeling path. Sometimes we deliberately avoid adding certain E+ input objects because they are functionally duplicative to existing objects. OS has the benefit of hindsight in this regard. OS also eliminates some objects through abstractions in an attempt to remove redundancy in the input, make model creation easier, and OpenStudio's code easier to maintain internally. The classic example I use to make this point is the E+ Branch object, which does not exist in OS, but is created on translation to E+. There are plenty of other examples of this kind of abstraction. We try to have a light touch so there is some transparency with E+, but it is more art than science with clearly defined rules. In general HVAC components themselves (fans, coils, terminals, etc.) will mirror E+ almost verbatim, but connecting objects (ie. Branch, BranchList, Connector), and container objects (ie. coil system dx cooling) do not. We are plunging into this process object by object, asking what does this E+ input object offer and does its feature set already exist somewhere else. We are getting pretty near the end of this process with respect to HVAC, but E+ is a moving target because there is a healthy stream of continuous improvements to E+.

In general the path for accessing E+ features that are either not yet covered by the OS Model or (hopefully very rare) abstracted out, is OpenStudio's EnergyPlus Measure. Using an EnergyPlus Measure lets you access the entire set of EnergyPlus input objects in their entirety. You can read more about EnergyPlus Measures here.

I detect that this particular question is motivated by your related question here You are looking for access to the CoilSystem:Cooling:DX object to gain access to advanced dehumidification modes. The problem is that the coil system is one of those objects that OpenStudio abstracted away and generates as circumstances require during creation of the idf file. In E+, coil objects can't go directly on AirLoopHVAC systems, but instead have to be placed in a controlling container such as CoilSystem. OS just says, hey I'm not going to make you put coils inside this container, I'll take care of that for you. I think this is generally helpful but this is one area where we have probably abstracted away a feature( the advanced dehumidification mode). Like I said over here the AirLoopHVACUnitarySystem which is supported in OS can be used similarly as a coil wrapper, but I admit I have not personally used it to replicate advanced dehumidification and it may not be possible. So the simplest answer is use an EnergyPlus Measure to grab the CoilSystem object that OS created and tweak the input fields. I will try to work up an example of how exactly to do this so it is more concrete for you.

Longer term I still think abstracting out coil system was a pretty decent design decision. What I think we need to do is factor out the control type field from the coil system and push it into the OS coil types for which that field applies. This path would have the added benefit of making it clear which coil types the field applies to. This would be a rare departure from E+ that we would need to document.

We are actively trying to make sure the feature gap between OS and E+ is almost negligible. That doesn't mean that we will expose every E+ object one for one in OpenStudio, but we are monitoring the feature set of E+ and trying to make sure that we capture the features via at least one modeling path. Sometimes we deliberately avoid adding certain E+ input objects because they are functionally duplicative to existing objects. OS has the benefit of hindsight in this regard. OS also eliminates some objects through abstractions in an attempt to remove redundancy in the input, make model creation easier, and OpenStudio's code easier to maintain internally. The classic example I use to make this point is the E+ Branch object, which does not exist in OS, but is created on translation to E+. There are plenty of other examples of this kind of abstraction. We try to have a light touch so there is some transparency with E+, but it is more art than science with clearly defined rules. In general HVAC components themselves (fans, coils, terminals, etc.) will mirror E+ almost verbatim, but connecting objects (ie. Branch, BranchList, Connector), and container objects (ie. coil system dx cooling) do not. We are plunging into this process object by object, asking what does this E+ input object offer and does its feature set already exist somewhere else. We are getting pretty near the end of this process with respect to HVAC, but E+ is a moving target because there is a healthy stream of continuous improvements to E+.

In general the path for accessing E+ features that are either not yet covered by the OS Model or (hopefully very rare) abstracted out, is OpenStudio's EnergyPlus Measure. Using an EnergyPlus Measure lets you access the entire set of EnergyPlus input objects in their entirety. You can read more about EnergyPlus Measures here.

I detect that this particular question is motivated by your related question here You are looking for access to the CoilSystem:Cooling:DX object to gain access to advanced dehumidification modes. The problem is that the coil system is one of those objects that OpenStudio abstracted away and generates as circumstances require during creation of the idf file. In E+, coil objects can't go directly on AirLoopHVAC systems, but instead have to be placed in a controlling container such as CoilSystem. OS just says, hey I'm not going to make you put coils inside this container, I'll take care of that for you. I think this is generally helpful but this is one area where we have probably abstracted away a feature( the advanced dehumidification mode). Like I said over here the AirLoopHVACUnitarySystem which is supported in OS can be used similarly as a coil wrapper, but I admit I have not personally used it to replicate advanced dehumidification and it may not be possible. So the simplest answer is use an EnergyPlus Measure to grab the CoilSystem object that OS created and tweak the input fields. I will try to work up an example of how exactly to do this so it is more concrete for you.

Longer term I still think abstracting out coil system was a pretty decent design decision. What I think we need to do is factor out the control type field from the coil system and push it into the OS coil types for which that field applies. This path would have the added benefit of making it clear which coil types the field applies to. This would be a rare departure from E+ that we would need to document.

Update:

Here is a link to an EnergyPlus Measure that changes the "Dehumidification Control Type" field (field 7 if you count from 0) of the coil system object to "MultiMode". Here is the highlight of what the Measure is doing. You input the dx coil name of interest as an argument to the measure and using naming convention the Measure finds the corresponding coil system in the generated idf file and changes it.

  # define what happens when the measure is run
  def run(workspace, runner, user_arguments)
    super(workspace, runner, user_arguments)

    # use the built-in error checking 
    if !runner.validateUserArguments(arguments(workspace), user_arguments)
      return false
    end

    # assign the user inputs to variables
    coil_name = runner.getStringArgumentValue("coil_name", user_arguments)

    coil_system = workspace.getObjectByTypeAndName("CoilSystem:Cooling:DX".to_IddObjectType,coil_name + " CoilSystem")
    if not coil_system.empty?
      coil_system.get.setString(7,"Multimode")
    end

    return true

  end