Make all method names snake_case so that there is no chance that they are accidentally overwriting C++ methods.

Close sql file after the sizing run completes. Probably implement in utilities/simulation.rb

From @khaddad:

Inside file https://github.com/NREL/openstudio-standards/blob/master/openstudio-standards/lib/openstudio-standards/standards/Standards.Fan.rb there is method ‘fan_power’

Inside this method there is this code for setting the flow rate:

    dsn_air_flow_m3_per_s = if to_FanZoneExhaust.empty?
                              if autosizedMaximumFlowRate.is_initialized
                                autosizedMaximumFlowRate.get
                              else
                                maximumFlowRate.get
                              end
                            else
                              maximumFlowRate.get
                            end

Using one of the unit tests we have, I notice that ‘autosizedMaximumFlowRate’ does return a value even though ‘maximumFlowRate’ has been initialized. Perhaps this code should be rearranged to this:

    dsn_air_flow_m3_per_s = if to_FanZoneExhaust.empty?
                              if maximumFlowRate.is_initialized
                                maximumFlowRate.get
                              else
                                autosizedMaximumFlowRate.get
                              end
                            else
                              maximumFlowRate.get
                            end

Testing PRM measure against an actual project.

EnergyPlus reports:

PRM measure output shows (for the proposed model):
"The WWRs are: NonRes: 57%, Res: 0%."

WWR code should return same results as EnergyPlus report (calculation here).

Not sure if this is actually an OpenStudio issue, but in the Standards.CoilCoolingDXSingleSpeed, it's trying the find the heating type. See here

 if air_loop.supplyComponents('Coil:Heating:Gas'.to_IddObjectType).size > 0
    heating_type = 'All Other'

With an air_loop actually having not one but two gas coils, it clearly fails

 [1] (main)>  air_loop.supplyComponents('Coil:Heating:Gas'.to_IddObjectType)
 => []

Whereas this works:

[2] (main)>   air_loop.supplyComponents('OS_Coil_Heating_Gas'.to_IddObjectType)
 => [#<OpenStudio::Model::ModelObject:0x0000001b204e80 @__swigtype__="_p_openstudio__model__ModelObject">, #<OpenStudio::Model::ModelObject:0x0000001b204e30 @__swigtype__="_p_openstudio__model__ModelObject">]

Seems the multiplier is fine, but the mid and top floor is just positioned lower than it should be. Minor issue, but would be nice to fix at some point.
https://unmethours.com/question/18033/why-is-large-office-prototype-building-so-short/

It's missing Stairwells, Office, Community Room, Electrical/Mechanical, Exercise Room (Gym) etc. I don't think these should be classified as non residential.

The standards generate buildings that lack building stories.
Since the OSLib_HVAC libraries rely on building story assignments to create air loops, any measure using the OSLib_HVAC libraries (including AEDG measures) won't generate air loops when run.

It seems like you've already made a method to add building stories in the Prototype.Model.rb code:

def assign_building_story(building_type, building_vintage, climate_zone, building_story_map)
    building_story_map.each do |building_story_name, space_names|
    ...

... but haven't yet made the building_story_map objects as part of each Prototype.<building_type>.rb file. This seems like this would be pretty quick. Was there a reason why this wasn't working?

Surface construction set 'Default Surface Constructions 2' contains floors that are incompatible with ceilings in the same set. Should check for this on export.

When looking through the code (which is rather big and hard to wrap your head around), it's often confusing to see different naming conventions for the same thing. example:

• building_vintage
• standard
• template

all refer to the same thing (eg '90.1-2007')

Maybe unifying the convention would be a good idea.

Applies to 2007, 2010, and 2013. There should probably be a method in Standards.PlantLoop to accout for purchased heat and/or chilled water.

G3.1.1.1 Purchased Heat. For systems using purchased
hot water or steam, the heating source shall be modeled as
purchased hot water or steam in both the proposed and baseline building designs. Hot water or steam costs shall be basedon actual utility rates, and on-site boilers, electric heat, andfurnaces shall not be modeled in the baseline building design.G3.1.1.2 Purchased Chilled Water. For systems usingpurchased chilled water, the cooling source shall be modeledas purchased chilled water in both the proposed and baselinebuilding designs. Purchased chilled water costs shall be basedon actual utility rates, and on-site chillers and direct expansion equipment shall not be modeled in the baseline buildingdesign.

This is a major issue as of right now, every availability manager defaults to Always On Discrete, leading to very high energy consumption (and very high savings henceforth)

Per Appendix G:

G3.1.2.4 Fan System Operation. Supply and return fans shall operate continuously whenever spaces are occupied and shall be cycled to meet heating and cooling loads during unoccupied hours.

This means that the availability schedule for the air loops should, in a lot of cases, not be always 1. If you have occupied spaces at night (typical example: office), then they should already be set for the given airloops in the proposed model so we should like copy and carry these over. You'd assign an availability schedule to the AirLoopHVAC (that in turn will create an AvailabilityManager:NightCycle on forward translation to IDF), with a value of 1 during the day and 0 at night. Let's call it Office HVAC Operation Schedule

G3.1.2.5 Ventilation. Minimum outdoor air ventilation rates shall be the same for the proposed and baseline building designs.
Exception: When modeling demand-control ventilation in the proposed design when its use is not required by Section 6.4.3.8.

To take my office example from above, chances that the intent of the proposed design would be to have the outdoor air fraction turned to 0 during night time, unless the economizer (if there's one) is activated to provide free cooling. How I've been doing this in the proposed is to assign the same schedule - Office HVAC Operation Schedule - to the Maximum Fraction of Outdoor Air Schedule in the loop's Controller:OutdoorAir. Thought it seems that assigning it to the Minimum Outdoor Air Schedule Name is how it's done in the DOE Commercial Buildings...
In the case of the baseline automation measure, the Minimum Outdoor Air Schedule Name seems to be set to always 1 for the airloops' Controller:OutdoorAir.

https://github.com/NREL/openstudio-standards/blob/baseline_automation/openstudio-standards/lib/openstudio-standards/standards/Standards.Pump.rb#L36

Eplus actually assumes an impeller efficiency of 0.78 to determine the total efficiency
See the engineer reference guide for Pump Sizing

Rated_Power_Use = Rated_Volume_Flow_Rate * Rated_Pump_Head / Total_Efficiency
Rated_Power_Use / Rated_Volume_Flow_Rate =  Rated_Pump_Head / Total_Efficiency
Total_Efficiency = Motor_Efficiency * Impeler_Efficiency

With a 100 tons chiller I ended up with a Constant primary variable secondary pumping instead of having a constant primary constant secondary (riding the pump curve)

From prototype_inputs.json, unit heater static pressure is set at 0.2. Example here.

In the code it's currently used as is, in Pascals. That's ridiculously low.

A quick look at manufacturer litterature reveals that unit heaters are operation at 0.2 inches of water column, or roughly 50 Pa. See this trane catalog, page 6

I understand this file is to reflect the commercial building prototypes, and I haven't looked to see if this was the same in the original files or in the creation of this JSON, but I think this is wrong.

I'm getting warnings for all my PSZ-AC DX cooling coils. Here it is for one of them, with DisplayExtraWarnings

** Warning ** SizeDXCoil Coil:Cooling:DX:SingleSpeed ZONE1 PSZ-AC 1SPD DX AC CLG COIL 24KBTU/HR 13.0SEER
**   ~~~   ** ...Gross Rated Total Cooling Capacity [W] will be limited by the minimum rated volume flow per rated total capacity ratio.
**   ~~~   ** ...DX coil volume flow rate (m3/s ) = 0.277777
**   ~~~   ** ...Requested capacity (W ) = 8774.387
**   ~~~   ** ...Requested flow/capacity ratio (m3/s/W ) = 3.165E-005
**   ~~~   ** ...Minimum flow/capacity ratio (m3/s/W ) = 4.027E-005
**   ~~~   ** ...Adjusted capacity ( W ) = 6897.883
** Warning ** The Standard Ratings is calculated for Coil:Cooling:DX:SingleSpeed = ZONE1 PSZ-AC 1SPD DX AC CLG COIL 24KBTU/HR 13.0SEER but not at the AHRI test condition due to curve out of bound.
**   ~~~   **  Review the Standard Ratings calculations in the Engineering Reference for this coil type. Also, use Output:Diagnostics, DisplayExtraWarnings for further guidance.
**   ~~~   ** CheckCurveLimitsForStandardRatings: The max and/or min limits specified in the corresponding curve objects
**   ~~~   **  do not include the AHRI test conditions required to calculate one or more of the Standard Rating values.
**   ~~~   ** Coil:Cooling:DX:SingleSpeed=ZONE1 PSZ-AC 1SPD DX AC CLG COIL 24KBTU/HR 13.0SEER:  Seasonal Energy Efficiency Ratio (SEER) calculated is not at the AHRI test condition.
**   ~~~   **  Check limits in Part Load Fraction Correlation Curve, Curve Type = CUBIC, Curve Name = COILCLGDXEIRRATIO_FQFRAC 4
**   ~~~   ** Coil:Cooling:DX:SingleSpeed=ZONE1 PSZ-AC 1SPD DX AC CLG COIL 24KBTU/HR 13.0SEER:  Integrated Energy Efficiency Ratio (IEER) calculated is not at the AHRI test condition.
**   ~~~   **  Check limits in Total Cooling Capacity Function of Temperature Curve, Curve Type = BIQUADRATIC, Curve Name = COILCLGDXQRATIO_FTWBTOADBSI 8
**   ~~~   **  Check limits in EIR Function of Temperature Curve, Curve Type = BIQUADRATIC, Curve Name = COILCLGDXEIRRATIO_FTWBTOADBSI 8

Baseline System Types 9 and 10 were not added to the major version of the ASHRAE 90.1 standard until 2010, yet the PRM measure is adding them when the standard version is 2004 or 2007.

Since it applies to other baselines and can potentially hit the limit for path length (260 characters for Windows). Suggest something more generic and shorter such as create_baseline_model.

The Lockout Type for the Controller:OutdoorAir object is being set to "NoLockout" for non-integrated economizers here. This means that when the unit is in heating mode the outdoor air damper is not at its minimum position like it should be for correct economizer control. This results in excessive heating energy use. Setting this line to "LockoutWithHeating" should fix the problem.

OpenStudio sets 'Standards Construction Types' based on 'Intended Surface Type' inputs here. The openstudio_standards measure looks up baseline construction properties based on these inputs. However, the available options in OpenStudio do not cover all of the cases defined in the standards data. For example, OpenStudio has no Standards Construction Type options for Intended Surface Type = ExteriorWindow, but the standards spreadsheet defines window constructions based on Standards Construction Types = "Metal Framing (all other)", "Nonmetal Framing (all)", etc. There are multiple other discrepancies for different surface types.

If the OpenStudio measure tags are to be used for the standards information lookup, the available options should match the lookup values in the standards data.

No 'Laboratory' space type exists for Standard 90.1-2007 in OpenStudio_Standards_space_types.json. I think, at least as far as loads are concerned, the 2007 Lab space is essentially the same as the 2004 Lab space.

Example for Air Conditioners, 135-240 kBTU/h, electric resistance, in 90.1-2007 Table 6.8.1.A

9.7 EER (before 1/1/2010)
11.0 EER (After 1/1/2010)

In 2010 you also have a difference between before 2012 and after.

System 6's are currently not created:

It seems that ComponentSizes is currently not being maintained. See here

G3.1.3.4 Hot-Water Supply Temperature Reset (Systems
1, 5, and 7). Hot-water supply temperature shall be reset
based on outdoor dry-bulb temperature using the following
schedule: 180°F at 20°F and below, 150°F at 50°F and above,
and ramped linearly between 180°F and 150°F at temperatures
between 20°F and 50°F.

G3.1.3.12 Supply Air Temperature Reset (Systems 5 through 8).
The air temperature for cooling shall be reset higher by 5°F under the minimum cooling load conditions.

Seems to fail across all climate zones, but only for 2004 vintage.

Need to set the economizer type in Standards.AirLoopHVAC. The economizer type is determined but never set (the temperature/enthalpy limits are).

Around https://github.com/NREL/openstudio-standards/blob/master/openstudio-standards/lib/openstudio-standards/standards/Standards.AirLoopHVAC.rb#L1231

Add

# Set the Economizer Type
 oa_control.setEconomizerControlType(economizer_type)

I'll do a PR once I'm done working on my current project (for which I've modified a lot of code to suit my own needs)

I'd like to implement PTHP standards for the baseline automation. Just like PTAC, PTHP has a heating efficiency requirement that is dependent on capacity.

Looking at the OpenStudio Standards Google Spreadsheet, first I'm a bit confused of the distinction between "Heat Pumps Heating" and "Heat Pumps" tabs, but I'd suppose Heat Pumps is the cooling side of the HP, and the "Heat Pumps Heating" is the heating side?

Anyways, similarly to what has been done I'd propose something along the lines:

• Adding another subcategory called "PTHP" to the "Heat Pumps" tab
• Adding a subcategory "PTHP" to the "Heat Pumps Heating" tab, and two other columns "PTHP_COP_Coefficient_1" and PTHP_COP_Coefficient_2.

What do you think?

1. Maybe make these attributes of OpenStudio::Model::Model
2. Pick either vintage or template and make consistent

From @jmarrec:

All programs for Multifamily buildings (LEED MFHR, NYSERDA MPP) that I've modeled for determine the LPD for apartment by looking up the Building Area LPD for "Multifamily". So 0.7 W/ft^2 for ASHRAE 90.1-2007 and 0.6 W/ft^2 for ASHRAE 90.1-2010 (TABLE 9.5.1)

Need to square this with the DOE Prototype Buildings before making a change.

@asparke2

I'm not sure I'm a big fan of using the standards information attached to the construction that is applied to a surface to determine what should be the baseline construction of this surface.

It will not even work for most of the current Construction Sets that ship with OS, since for example Ground Walls, Floors, Ceilings and Exterior Floors can refer to the same construction

OpenStudio is smart enough as it is to correctly classify surfaces based on their boundary condition, z coordinate, and tilt. I think we should rely on that rather than rely on people creating on construction for each surface type AND filling out the standards information on each on them.

https://github.com/NREL/openstudio-standards/blob/baseline_automation/openstudio-standards/lib/openstudio-standards/standards/Standards.Space.rb#L1389

https://github.com/NREL/openstudio-standards/blob/baseline_automation/openstudio-standards/lib/openstudio-standards/standards/Standards.Space.rb#L1392

I think both of these lines should read req_top_ctrl = false no?

This is potentially going to be tricky, but we have to find a way to gracefully handle Service Hot Water Loops.

Right now the current logic is:

• a plant loop that serves a water use connections isn't deleted Standards.Model.create_performance_rating_method_baseline_building calls Standards.Model.remove_performance_rating_method_hvac
• Get all WaterHeaters in model and change fuel type if standard is 90.1-2013, do nothing otherwise.

Couple of Notes:

• The WaterHeater fuel type is one thing, but there's a ton more to do, per G3.1.11 (especially b. and e.)
• eg G3.1.11.e: if a "Where a combined system has been specified to meet both space heating and
  service water heating loads, the baseline building system shall use separate systems meeting the minimum efficiency requirements applicable to each system individually.". This is quite common in my experience to have a space heating boiler serve a storage tank through an internal or external HX. In the baseline I'd model a WaterHeater:Mixed with a minimum efficiency requirement (typically 80%), having the same storage capacity as the proposed design, and a burner heating capacity similar to the proposed system (this is tricky, the space heating boiler really is sized for the space heating load + DHW. I know some reviewers that force you to use the proposed space heating boiler capacity in the baseline waterheater, which to me is completely ridiculous, but I digress).
• I just ran the PRM on a model that had a Service Water Heating loop with a single branch on the supply consisting of a FluidToFluid:HX and a WaterHeater:Mixed used as a storage tank only (no burner capacity). The resulting thing is en E+ crash because the FluidToFluid:HX is no longer connected on the supply side. The waterheater:mixed still has zero burner capacity anyways.
• G.3.11.b is especially fundamental too: in any case you should model the baseline per minimum efficiency requirements, and if proposed heating source is electricity, then electric resistance is used (particularly important in case proposed is a Heat pump water heater)

Suggestion:

I suggest trying to asses how the SHW load is being handled: what fuel type is used, and is this a combination of space heating and SHW. Find the storage capacity of any storage medium, and find the heating capacity of the equipment serving the SHW load.

Then probably delete everything on the supply side of the SHW loop(s), keeping only the SPM and the water use connections. Maybe want to keep the pump too.

What do you think folks?

WWR reduction will be done by raising sill height. This causes the least impact on the daylighting area calculations and controls placement.

It'll work well for perfectly rectangular windows, but it fails in my case, notably because I have a window with 4 sides that's not perfect, and due to rounding error the method will end up creating a 4-sided windows that REALLY isn't rectangular.

In my opinion we should resize all windows around the centroid, which means it'll work nicely for all 3-sided (it's called a triangle I'm told) and 4-sided windows (@asparke2 I had already mentioned this in a @todo)

What do you think? If you agree, I already have the code to do that.

https://github.com/NREL/openstudio-standards/blob/master/openstudio-standards/lib/openstudio-standards/standards/Standards.CoilCoolingDXSingleSpeed.rb#L45

https://github.com/NREL/openstudio-standards/blob/master/openstudio-standards/lib/openstudio-standards/standards/Standards.CoilCoolingDXTwoSpeed.rb#L205

These should be appended "OS:" because it doesn't work right now.

I'll do a PR asap.

ExportStandardsToJSON.rb:13:in []': (in OLE methodValue': ) (WIN32OLERuntimeE
rror)
OLE error code:80070057 in

HRESULT error code:0x80020009
Exception occurred.
from ExportStandardsToJSON.rb:13:in getNumRows' from ExportStandardsToJSON.rb:33:ingetTemplatesHash'
from ExportStandardsToJSON.rb:535:in `

If you run "create_doe_prototype_building" several times in a row, especially for buildings with large numbers of skylights, you will get slightly different simulation results. These differences are caused by non-deterministic lighting controls placement due to the apparent randomness in either the OpenStudio.subtract or OpenStudio.joinAll methods. The differences in lighting cascade to cause differences in heating, cooling, pumps, fans, etc.

The impact is most pronounced in buildings where a large part of the building's total lighting is controlled via daylight sensors under skylights. RetailStandalone is the worst.

This was discovered in doing analysis for the PTool. Basically, Measures were showing impacts in areas where they shouldn't have. Digging in further, it was determined that the baseline models were different in the lighting control placement and slightly different in the sensor controlled fraction.

Requires adding way to specify water use per person, these will go into model, need to issue warning if not hooked up when translated to IDF

At least some of the current sizing runs are not necessary. I'll look in more details tomorrow, but we can certainly get rid of at least the last one (just set each boiler sizing ratio to 0.5 if you have two of these...)

I notice differences in the floor, roof and wall constructions between the EnergyPlus and OpenStudio Prototype Small Office Building for ASHRAE 90.1-2010, ClimateZone 2A. See excel attachment for differences.

Also, I am new to GitHub and have been unable to find any forum standards, so my apologies if this issue is not formatted correctly.
OpenStudio.EnergyPlus.Construction.Differences.Small.Office.Building.-.Climate.Zone.2A.-.ASHRAE.90.1-2010.xlsx

For Bldg 5, ALL zones with FourPipeFanCoils are being interpreted as have PurchasedHeat rather than PurchasedHeatAndCooling. At first I thought this issue was related to Setpoint Schedules, but that does not appear to be the case.

WWR differences in EnergyPlus and OpenStudio SmallOffice model due to osm classifying door as glassdoor and IDF classifying as opaque.

From UnmetHours.

We should do as good of a job at this as we can before we build more on this, https://docs.google.com/spreadsheets/d/1BO27ceOigvsYWWdIIMNlqGvabjFbvtWkHepaSvy0mlY/edit#gid=786160439

@asparke2 FYI

this causes the sizing simulations to fail

G3.1.2.9 Fan Motor Efficiency = the efficiency from Table 10.8 for the next motor size greater than the
bhp using the enclosed motor at 1800 rpm

To me this means that if bhp < 1 HP, you should look at 1 HP instead of "assuming PSC motor at 29% per a PNNL paper". I noticed that because the Section 1.4 tables from LEED were indicating my fan power for my "small" (<65 kBTU/h) PSZ-AC system group was way off.

I'll do a PR once I'm done working on my current project (for which I've modified a lot of code to suit my own needs)

Applies to 2007, 2010, and 2013. The code incorrectly defaults to reset_required = false in this method. The code should instead apply OA reset control to both CHW and HW loops (#79) by default.

G3.1.3.9 Chilled-Water Supply Temperature Reset
(Systems 7, 8, 11, 12, and 13). Chilled-water supply temperature shall be reset based on outdoor dry-bulb temperatureusing the following schedule: 44°F at 80°F and above, 54°F at60°F and below, and ramped linearly between 44°F and 54°Fat temperatures between 80°F and 60°F.

If the proposed model has a SHW system it will be removed in the baseline model, although the WaterUseEquipment objects will be retained.