Grasshopper

algorithmic modeling for Rhino

Hi,

Following this thread i"m having "serious" issues that i want to consult with you.

I adapted the attached file (from Chris) to be a residential use, that will have 24 hrs use.

I defined schedules for heating and cooling, where the temperatures will be 20 and 24 respectively. The loads change a bit during the day, and also defined the proper schedules for that.

I defined "hardcore" that winter period will be from November to March.

All this under the warning "I think i did that". Since i'm not getting any heating consumption and when i check the temperatures i get crazy values for the winter period (see plotted charts in the attached file).

Summer values are somehow reasonable (at least temperature wise).

The definitions that HB uses are a bit different than those i'm used to do, so i suppose there is something i'm doing wrong.

Your comments will be much appreciated.

Thanks,

-A.

Views: 1929

Attachments:

Replies are closed for this discussion.

Replies to This Discussion

Hi Abraham, I can't check your file right now but can you check setPts for heating and cooling. There was a bug in OpenStudio schedules for set points which I reported while ago and they get it fixed. I wonder if they have the bug back in the new OpenStudioTemplate? It used to be 0 for both and that was causing the issue.

I'll try to check this, but i think i messed a little bit the things. That's why i'll be glad if you, whenever you have the time, check the file.

In the meantime i changed some definitions and the temperatures are "right" but it still bothers me that the heating in winter time is almost none and, beyond that, the cooling is much higher than the heating.

The OpenStudioMasterTemplate.idf in my system is dated 19.7.2014 and the OpenStudioMasterTemplate_1412836435.idf from 9.10.2014.

Thanks,

-A.

Hi Abraham,

I have taken a look at your model and I can say that nothing is wrong in the running of EnergyPlus and there are no bugs in Ladybug or Honeybee that are causing those results.

The very high temperature values in winter are the result of the fact that you have created a mostly glazed south-facing test box in a high solar radiation climate and you have left almost no place for this heat to escape from your zone.  All of your surfaces other than the glazed surface are adiabatic so there is no chance for the heat to escape there.  In the winter months, you do not allow users to pull the blinds (as per the blinds schedule), open the window (as per the minOutdoorTempForNatVent value of 18C) or run the cooling system (as per your cooling setpoint shcedule).  Left with only a small infiltration rate and a small amount of conduction through a window, the heat cannot escape your zone and so it builds up until the indoor temperature reaches up to 55 C in the afternoon.

You are effectively modeling a solar oven and so I do not find your results that surprising.

Take a look at your solar gains:

Take a look at your total heat gain (people + equip + lights + solar) (you have some interesting internal gains schedules):

Now take a look at the net flow of heat (solar+conduction) through your window (one of 2 places where heat escapes):

And look at your infiltration loss/gain (the other place where heat escapes):

When your building looses the majority of its heat through infiltration and the outdoor air that is not that cold, you know that the indoor temperature must be high.

I would consider letting people pull blinds, open windows, or run the cooling system.  Or you could make the surfaces of your zone non-adiabatic.  Adiabatic surfaces can really distort energy results unless you know exactly how to use them.  My guess is that this test box is supposed to represent something different than what you are modeling.  I imagine that, if this test box were representing a part of a real building, it would probably be exchanging a lot of heat with a core or north-facing zone behind it.

Attachments:

Hi Chris and thanks,

I'm preparing a proper answer to yours :-)

I believe this is one of the cases where bad inputs lead to bad results (in other words: garbage in garbage out).

There is no way that you get such high temperatures in this climate conditions. But i'll send this later on.

In the meantime, i find those graphs very enlightening!! Very cool way of understanding what you are doing (or i'm doing). Though i can't reproduce all of them specially the total heat gain and net flow. Can you send the example where you get them?This will be very helpful for me (and others maybe) and to prepare, and justify my answer.

Thanks again,

-A.

Hi Chris and thanks,

I'm preparing a proper answer to yours :-)

I believe this is one of the cases where bad inputs lead to bad results (in other words: garbage in garbage out).

There is no way that you get such high temperatures in this climate conditions. But i'll send this later on.

In the meantime, i find those graphs very enlightening!! Very cool way of understanding what you are doing (or i'm doing). Though i can't reproduce all of them specially the total heat gain and net flow. Can you send the example where you get them?This will be very helpful for me (and others maybe) and to prepare, and justify my answer.

Thanks again,

-A.

Abraham,

Indeed, "garbage in garbage out" might be a good way to describe this case :).  You are correct in that there is no way (or at least very few ways) to get such high air temperatures in your climate's winter.  Believing that this is possible is nothing short of an adiabatic fantasy.

As for the means by which I created those colored charts: with the outputs that you can request with the "Generate EP Output" component, I have tried to make it possible for you to track all terms of the energy balance calculation that E+ is running. If you set the "zoneGainsAndLosses_" input of the "Generate EP Output" component to True, you will get a number of useful energy values out of the E+ simulation (and displayed on the "Read EP Result" component).  This includes solar gains, people gains and infiltration gains+losses.  If you take this output along with the lighting gains, the equipment gains and the heating/cooling that you already usually have coming out of this component, you have almost all of the terms of the energy balance that E+ does.  The only major thing that is missing is the conduction through the envelope but you can look at this if you set "surfaceEnergyAnalysis" to True on the "Generate EP Output" component and use the "Read EP Surface Result" component.  The heat flow through the envelope comes through on a surface-by-surface basis so it can sometimes be difficult to find just the surface that you are interested in if you have a large model.  Since you had only one window in your model, it was easy for me to find.

I should note that the total heat gain chart that I made in the post above is a bit of a hack and is not a perfect representation of all of the heat that is coming into the zone - since it only includes people + equip + lights + solar and not possible infiltration or envelope gains.  It also excludes the heat that can be removed (or accidentally added) by natural ventilation.  To make the chart, all that I did was use the "SeparateData" component on those 4 types of gains and used the native grasshopper "addition" component to add them together (I think that I also had to use a native Grasshopper "Flip Matrix" component to make sure the right parts of the list were added).  The attached GH file shows how I did this.

Let me know if you have any other questions.

-Chris

Attachments:

Hi Chris and thanks,

A bunch of garbage indeed there.

Since i have plenty of questions, first i want to describe the garbage:

1. The schedules for Heating and Cooling were intended to avoid heating/cooling consumption in those months i identified as winter/summer. I defined -50 oC and100 oC for such months. But it was a mistake. Just after i defined all the temperatures the same for winter/summer i get the desired temperatures.

2. Equipment/Lighting schedules: I was mixing the occupancy/lighting schedules (when they are ON) with the loads themselves.  I suppose i get mislead with one of your previous examples. I think i'm getting right now.

So this is with regard the garbage (attached the file with the fixes if you don't mind to check).

Now the questions:

a. HB_setEPZoneThresholds: I'm defining there Cooling/Heating Det point and Setbacks. I don't see them in the IDF. If i define HeatingCoolingSetpoint schedules in the HB_setEPZoneSchedules these definitions are not written in the IDF?

b. HB_setEPNatVent: Im defining min/max indoor/outdoor temperatures. But i also don't see where in the IDF they are registered.

c. I know you are using DualIdealSystem for the dafault HVAC. There is a way of not calculating cooling for winter months? I'm not defining well this question, but in this example i'm getting cooling loads bigger than heating for winter. Can't be (!!). In the worst case you open windows but don't cool. My faculty building shifts the HVAC from cooling to heating  at determined dates in the year. When not needed you don't switch them on. I hope you understand the meaning of the question and find the logic in it. The way i define Ideal Systems allows me to do that, but i can't find how to do that in HB components.

Hope this makes any sense for you.

Thanks for your help.

-A.

Attachments:

Hi Abraham,

Thanks for the clarification.  To answer the questions:

a. If you define the heating/cooling setpoints with custom CSV schedules, you will override anything that you have in the "Set EP Zone Thresholds" component.  The thresholds component only works if you are taking the original OpenStudio schedules assigned based on program.  If you take the original OpenStudio setpoint schedules, you should see that the setpoints show up under the schedules section.

b. The max and min nat vent temperatures show up under the ZoneAirflow objects in the IDF (they are not schedules).  

c. You are getting cooling loads bigger in winter than in summer because you are pulling the blinds every time that the outside temperature goes above 18 C (which does not happen in winter).  Looking at the total solar gain will help you understand this.  It is possible to shut off the cooling system with a schedule in the Ideal Air System template that we use.  I have not built in the functionality to do this in HB yet and, since it requires a schedule, it's difficult to do it manually by editing the IDF (I will do this soon).

You might also want to try adding in an an air side economizer to your ideal air system, which you can do with the new "Set Ideal Air Loads Parameters" component.  This will mix in more outside air when it is cool outside in winter.

-Chris

Thanks Chris,

More questions here:

Answer b: i know they are not schedules but the only section i'm getting under ZoneAirflow is the Infiltration. So i suppose i'm missing some other definition in order to enable this ventilation. Attached the file, updated to today's version.

Added the Economizer, but also it is not making any difference in the IDF. I'm not talking about the results but about the definitions in the IDF file. Again, I'm missing something for sure.

Thanks,

-A.

Attachments:

Abraham,

That is because you are using an older version of the nat vent component.  It is updated in the attached file.

The economizer boolean is changing the Enconomizer type in the ideal air loads template:

-Chris

Attachments:

Yes, Thanks.

Just realized this before your answer. When i update the version i noticed the date of the component is right. Since it didn't gave any error y assumed the component didn't changed. Now i see that i need to check further ...

Thanks again. I think this example file is doing what i wanted (except the cooling/heating consumption in winter/summer, but for now it is not possible).

Thanks again,

-A.

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service