Grasshopper

algorithmic modeling for Rhino

Hi Guys,

After running a succesful simulation with HB, I went through an issue to read the results with the 'Honeybee_Read EP Result' component. For some reason the

file was not read satisfactorily, this is how it looked like:

I noticed that this would happen only after running simulations with defined boolean values for the conditioning status of the zones. By leaving the default value for the conditioning status, the

file would go through after the simulation.

Any hint on that?

Thanks!!,

Alejandro

Views: 736

Replies are closed for this discussion.

Replies to This Discussion

Hi Alejandro,

If I remember right, Chris has already fixed this. Are you using the latest version on github or the version from food4rhino?

Mostapha

Hi Mostapha,

Chris recently helped me fix an issue with some calculations of the ideal air loads, for which I updated Ladybug and Honeybee to the latest versions of Github (I wonder if that´s what your refering to). The issue I´m writing about now came one week later (now) with a different model.

Here I attach the file..

Thanks!,

Alejandro

Attachments:

Alejandro,

Mostapha is referring to an issue that I fixed long ago with Abraham but that is not your issue.  There was a weird bug in the matching of names between the .eio file and the .csv result file.  I put in an extra check and this fixed your issue.  The file with the fixed component is attached and uploaded the new result reader to the github.

On another note, you use a component that is only meant to edit geometry (not HBZones) in the middle of an HBZones workflow:

You should use the intersect masses component before you change the breps to zones. I did this in the attached file before even bringing the masses into the file and the zone breps that you start with are now correctly ready to go for energy simulation.

As the error on the Read EP Result component suggests, the simulation was not being run correctly because of this and no result file was generated.

Also, I noticed that you changed all adjacent boundary conditions to adiabatic and I really do not recommend this when you have the whole building modeled like this.  Your cooling loads will likely be a lot higher than reality because the heat will not flow from zone to zone, thereby getting trapped in your zones.

-Chris

Attachments:

Awesome, thank you very much!!!

Also thanks for the note about the setup of the workflow (putting the "intersect masses" component after the creation of HBZones), I´ll ke

it in mind. An odd thing in regards to that though, is that the simulations were running as if normal, I was even able to open the .csv file generated afterwards and see the loads for each zone. I understand now that it won´t be desirable to put it that way and may cause some weird behaviors.

About the boundary conditions, in this case they correspond to existing walls of the building, so for this case there isn´t indeed any air getting mixed in between. Thx though as I know that for other cases that may play an important role in the overall thermal loads.

Best,

Alejandro

Alejandro,

Glad to be of help.

I know that the intersectMasses component worked with what you had but I should have clarified to say that you were lucky in your case and the component did not change your geometry much.  Most of the time, you want to make sure that you zone geometry is good before turning it into a zone.

You are right that, when you have air walls, you definitely do not want an adiabatic condition but, even when you have interior partitions between zones, I have often gotten a substantial amount of heat flow across them (particularly when one zone has a higher internal or solar gain than another).  This heat flow, more often than not, drops down the need to take the heat away through the cooling system.  I would just recommend that you do a comparison of the thermal loads of your building with and without adiabatic conditions to understand how much this can affect the simulation.  I know that the adiabatic is faster and, if the results prove to be very close to each other, then it might be ok to continue with the adiabatic assumption.

-Chris

You got it!,

Thanks again

Alejandro and Chris,

intersectMasses, is designed to work with Breps and not Honeybee objects. It should be always applied to Breps (Masses) and not HBZones. If you apply it to Honeybee zone, it doesn't really change HBZone's geometry. This can be considered as a bug and maybe we should add an extra warning to remind users about this.

Mostapha

Good idea.  I just added in a warning.

-Chris

Perfect! Thanks.

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service