Non standard ASHRAE climate zone strings are saved in OSM but not displayed in model

[DavidGoldwasser]

The Prototype Models save the climate zone as 7A and 8A. The climate zone is saved in the OSM, but not displayed in the GUI.

Showing non-standard strings could be an option, but maybe not a good idea. Could also either update standards to drop the A from 7 and 8 (maybe a can of worms) or in OpenStudio we could update 7 and 8 to 7A and 8A. If we do this some measure like AEDG would need to be updated.

The DOE Prototype measure and the updated SpaceType and Const. set wizard use 7A and 8A.

@macumber and @asparke2 any thoughts

[jmarrec]

Thoughts? Should the OS App use 7A instead of 7, or should standards use 7 instead of 7A? Once we define this, it shouldn't be hard to fix it.

[macumber]

We should save whatever Climate Zone identifiers that OpenStudio Standards accepts

[DavidGoldwasser]

zero energy guides have also been supporting recommendations for climate zone 0, so it could be although it isn't a valid option in OpenStudio standards for 90.1

[macumber]

If this is like the other standards fields, it should suggest values based off the standards json but allow free text entry

[jmarrec]

Isn't the whole idea of ASHRAE standards to be normative though? So I'd day whatever ashrae says plus maybe a couple others if we have backing up (cz zero for eg). I cant see why we would allow free text entry especially since I don't see what use cases there could be. The standards tag for space types have been there for a while and named differently in the past and it was kinda like a general tag you could use in measures later.

For 7a v 7, I guess I'm unclear if they are supposed to represent the same thing, a cursory look gave me a table of climate zones and 7 and 8 don't have a/b(/c) unlike the rest. If it's all the same then we just have to pick one.

[jmarrec]

Looking at ASHRAE 169-2013, or rather a publicly available addendum here since I don't have a copy myself:

I guess I'd need to understand the rationale in openstudio-standards using 7A and 7B for eg before we decide if/what fix is needed on OpenStudio's side.
(I did find here for eg that this helper will select the same weather file too: https://github.com/NREL/openstudio-standards/blob/d754365712142da794914164aebfc26f77f46f27/lib/openstudio-standards/weather/Weather.Model.rb#L32:L35).

Could you help @asparke2 or @mdahlhausen please?

[jmarrec]

Still the same question today. Updated permalink: https://github.com/NREL/openstudio-standards/blob/3daa310202a227293ed486f24f3f5e283da9f0a9/lib/openstudio-standards/weather/Weather.Model.rb#L55-L58

[DavidGoldwasser]

@asparke2 do you have any thoughts for this on how it impacts standards. At this point since we already have standards working with it, I'm fine with leaving 7 and 8 as they are in the GUI now, but I would like to list 0a and 0b as they are used in all zero energy ASHRAE guides, but could create issues if people pass models with these climate zone into create_baseline or create_typical measures.

[asparke2]

I think leaving 7 and 8 as they are is fine. Standards does not support climate zone 0, as this was not a valid climate zone in any of the versions of 90.1 that are supported thus far.