Sizing period - Design day


#1

Hey guys,

I would like to run thermal performance simulations only for Design Days, instead of weather files.

In Energy Plus, at Sizing Period: Design Day, we are able to define parameters for the program to create a 24-hour weather profile, inputting solar radiation values (or clear sky models), the day of the year for the solar geometry, humidity, temperature.

My goal is to run solar radiation studies for the 21st of each month but considering a clear sky value from ASHRAE for the specific location. I can do this with Energy Plus but not on Honeybee.

Is there a way to create and edit these Design Days and to run the simulation on Honeybee?


#3

Hey @chris , could you help me on this one?
I’m new to ladybug so if it’s impossible I would be glad to know.

Kind regards


#4

@mtonellis ,

Sorry for the late reply. You had originally posted this during a workshop week and this somehow fell through the cracks.

Before running the energy simulation, Honeybee will read the 99.6% and 0.4% sizing design days from the .ddy file next to the .epw file and add them to the IDF file as the objects you see in your image. So, if you add all of your 12 months of design days into the .ddy file next to the .epw as 99.6% or 0.4% design days, Honeybee will run them all for you.

You might also be interested in this example file, which show you how to bring the results from the sizing runs back into Grasshopper and create some cool visualization of them using TTToolbox:
http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Visualize_Peak_Loads_for_HVAC_Sizing

I hope that helps.


#5

Hey Chris!

Is there a way to bypass Honeybee from reading (and writing the idf object) for the 99.6% and 0.4% sizing days?

I was able to insert my custom Design Day objects via “additionalStrings”, but Honeybee still creates its own idf objects for the sizing design days, as mentioned previously.

Best regards!


#6

@emarta ,

The correct workflow for what you want to do is to copy your design day objects into a .ddy file and use the ddyFile_ input of the Energy Simulation Parameter component to assign that ddy file to the model like so:

Then, the OpenStudio component will pull the design day objects from that .ddy file instead of the .ddy that automatically downloads with the .epw file.

Because design day objects are pretty much always needed for a simulation, they don’t lends themselves well to use with additionalStrings, which is really intended for adding extra objects to the simulation that are not normally there.


#7

@chris, Thanks for the quick response!

I´ve done that, both with OpenStudio Component and EnergyPlus Component. However, both cases it didn´t work. The Energy Simulation Parameter shows that the import worked correctly, but when I go to the .idf file I see that in fact the Design Day Objects being used are those from the .epw
The last image is from the DDY file that I´m trying to pull into the simulation.

image


#8

@emarta ,

Are you using a version of the OpenStudio component that is from NOV_20_2018 or later? From what I can see in the current code, everything should work fine for custom .ddy files.

If you are using the latest OpenStudio component, can you upload your .ddy file? Perhaps it is not formatted correctly.


#9

@chris

ok, this is what happened…

  1. Component version was an issue. I’ve updated and now is importing correctly. Thank you for that! (side note: how can I activate notifications to know when you update the components?)

  2. The DDY import didn’t bring some schedule objects that I have on the .ddy file that orient the Design Day (such as the Beam Solar Day Schedule). I’ve attached my .ddy file for more info.

Thanks for all the help!

SPSaoPaulo.DDY (9.2 KB)


#10

@emarta ,

If you want to get notified when we do a new stable release, you can always follow us on Twitter or LinkedIn. We tend to only post there when we have newsworthy info like a new stable release, a new workshop tour we are announcing, or a new video series that we have uploaded. So you shouldn’t get too many extra notifications by following us if that is a concern.

And it seems you have the one type of .ddy solar model that we don’t do a good job supporting right now. The code in the OpenStudio component is really only built to read the SizingPeriod:DesignDay objects and so it works well with the ASHRAE Clear Sky and ASHRAE Tau solar models but not scheduled solar conditions. It would also be a lot of work to add code that reads in all types of schedules. I think we can support this for Honeybee[+] once we add the energy simulation capabilities there but, for the time being, I would just suggest adding the schedules to the model using additionaStrings_. So you would still assign the SizingPeriod:DesignDay objects through the .ddy but use additionaStrings_ to add the schedules to the model.

Let me know if that works for you and thank you for this example .ddy. We may use it for testing when we try to add these capabilities into HB[+]


#11

Sorry for the late reply @chris, I was busy running more tests in Honeybee this past week.

I’ve noticed that the best way to work around this issue is by importing the extra IDF objects I need via “additional_Strings” input, even the Design Day object. Only because when it loads the DDY file through the “Energy Simulation Parameters” it doesn’t bring my custom Schedules, even if they are written in addtStrings.

So I ran a test writing all extra IDF objetcs I need through “additional_Strings” and it worked fine.
Maybe in the future, it would be interesting to expand the ddy file import function to attend such demands. But nevertheless, you’ve done a great job leaving the possibility to add custom IDF objects to the user. It was very helpful!

Thanks for all the support!