Significance of wall orientation

Replies to This Discussion

Permalink Reply by Theodoros Galanos on April 25, 2015 at 10:27pm

Bump.

It's probably a silly question. But as I'm now at my 68th zone of the building I'm getting a bit scared on the prospect of going back and changing orientation of vertical walls. Especially since I internalized everything :(

And an additional probably trivial question. Is it dangerous to not assign the same (adjoining) surfaces to adjoining zones and instead extrude a new surface from the same curve? I am pretty sure this is what solving adjacencies component checks and resolves but need a sanity check. Also need to get rid of bad habits while 3d modeling, it's a longer process.

Thanks a lot!

Theodore.

Permalink Reply by Mostapha Sadeghipour Roudsari on April 26, 2015 at 11:23pm

 Is it dangerous to not assign the same (adjoining) surfaces to adjoining zones and instead extrude a new surface from the same curve?

You can't do that. In an energy simulation surfaces cannot be shared and adjacent durfaces should be exactly the same.

Permalink Reply by Theodoros Galanos on April 26, 2015 at 11:34pm

Hey Mostapha,

Thanks for the reply. What if the adjacent zone extends only in a part of the shared wall. Is it ok if I split the curve to extrude the surface or do I have to actually split the surface itself?

Also, what does cannot be shared mean exactly? Isn't it sharing if the adjacent surfaces going to be shared?

Thanks in advance. Simple matter probably but it's getting me all mixed up.

Kind regards,

Theodore.

Permalink Reply by Theodoros Galanos on April 30, 2015 at 4:18am

Hi Mostapha,

I followed your advice and cleaned up my surfaces. Only took 8 hours :)

However when I run the simulation I get a lot of "interzone azimuths do not match" errors and the simulation fails.

From a little research on the error it seems that the interzone surfaces need to be mirrored surfaces. That is the azimuth needs to be 90.0 on one zone and 270.0 on the other zone for the heat transfer to work correctly. However, after cleaning up my surfaces I always have the same wall in adjacent zones, referenced one for each zone.  Does this mean I need to reorient, manually, all adjacent surfaces? Or is there, hopefully, an automated way to do this in Honeybee?

Sorry for the constant questions.

Thank you so much in advance.

Kind regards,

Theodore.

Permalink Reply by Chris Mackey on May 2, 2015 at 1:32pm

Hi Theodore,

Sorry that there has not been as much activity on this discussion as there should have been.  I know that Mostapha put in a lot of checks that tried to self-correct in cases where the Rhino surfaces were not correctly mirrored.  Part of the difficulty stems from the fact that we wanted to keep these checks fast and just use some vector intersections to test whether a surface is facing the right direction but these checks clearly do not always work in my experience as in yours.  I have thought about adding in a check on the "zones from surfaces" workflow that uses a Rhinoscript function to put the surfaces into the Rhino scene, join them, explode them, and reassign the normals to the original HBSrfs.  Normally, I would use RhinoCommon for this joining operation but I know that the "JoinBreps" function there can produce a closed brep where all of the surfaces are facing inward, which is a bug in RhinoCommon and supposed to be impossible.  This rhinoscript route will take a lot longer to run but I know that it will never fail.

So I know that this is going to be a big compromise in the time it takes to run but I have ran into this difficulty with normals so may times myself that I badly want it to be changed.

Mostapha, what are your thoughts on this?  I am thinking that I will only put the rhinoscript check function on the "CreaHBZones" component and I will leave the masses2Zones workflow as is.

In the meantime, Theodore, can you upload a GH file that contains just a portion of the building that you are trying to simulate but enough so that you get the error?  I will use it to try to fix this issue if Mostapha is ok with it.

Lastly, I really cannot understand what you are asking about with the adjacent surfaces.  As long as you follow the rules that I lay out in this video, you should be fine:

https://www.youtube.com/watch?v=cDvBWDA0aF0&index=10&list=P...

-Chris

Permalink Reply by Theodoros Galanos on May 2, 2015 at 7:10pm

Hi Chris,

Thanks for your response. It is good to know I'm not the only one seeing this. I realize it is a Rhino thing mostly. To be honest, as a novice in Rhino, I do not understand how exactly the normals are assigned. Since most of my surfaces are extrusions from curves (aka the floor plan) I wonder if the normals of the curves should be set prior to creating the surfaces. I also am not sure if the normals are reassigned when you modify surfaces (trim, split, cut, merge, etc.).

I have no problem at all with time matters to be honest. At least in serious models I would prefer to have things set up correctly. So I would welcome and test the approach you are describing.

I do wonder however. Is this really an important issue though? I mean, does it compromise the Energy Simulation results seen as it is not a severe error for EP but just a few hundred warnings (simulation runs and finishes)? Only asking because I'd like to be sure I can trust my model right now.

As for the model itself, I am not in the work pc today. I will upload a few adjacent zones that reproduce the warnings tomorrow when I'll be back at it.

P.S.: Ignore my adjacent surfaces comment. Took me a while to read Mostapha's comment with clear mind and yes I did go back to the videos to settle it :)

Kind regards,

Theodore.

Permalink Reply by Chris Mackey on May 2, 2015 at 8:01pm

In Rhino, there is automatically a direction set to every surface once you create it.  You can use the "Dir" command to see it.  We often try to reassign this in Honeybee if the normal is not facing outward of the zone.  Rhino will not reassign the normal when you trim or split but, if you merge a bunch of surfaces into a closed poly surface, all normals will automatically be assigned to face outward from the solid.

I may not be remembering correctly whether E+ is auto-correcting the direction of the surface when it is not facing the right direction.  If it is auto-correcting, then you are right that this is not a big issue.

Glad adjacent surfaces issue is resolved.

-Chris

Permalink Reply by Theodoros Galanos on May 2, 2015 at 8:30pm

Hi Chris,

Yes I have been using dir but mostly for horizontal surfaces (to properly set up floor and ceiling) but never on horizontal. Yes you are right, in the error output it was mentioned that "EP is trying to automatically fix" so I guess it should be ok. I'll try a 2 zone model perhaps and see if there is any difference in the energy simulation results.

Kind regards,

Theodore.

Permalink Reply by Abraham Yezioro on May 2, 2015 at 10:17pm

As i know E+ is not fixing orientation. All surfaces must be defined using the same rule: CCW or CW depending on the definition of the geometry settings.

-A.

Permalink Reply by Mostapha Sadeghipour Roudsari on May 3, 2015 at 7:22am

It can be also an issue in our side if it looks right in your Rhino model and doesn't show up right in the energy model. As Chris mentioned above there are couple of checks to make sure the order of the points are right and also get the normals fixed if they are not already fixed in Rhino, so if you are still getting this error that should be a good model to be used for debugging our code.

Mostapha

Permalink Reply by Chris Mackey on May 3, 2015 at 9:55pm

Thanks for the clarification, Abraham.  I also just realized that I built a 52-zone model a couple of weeks ago with the surface-by-surface method and checked to be sure that all of the surface normals were correct in Rhino before going to HB (it was quite a pain in the neck as I remember).  Something tells me that I would not have done that unless I realized that it was going to mess up the simulation (I have to keep a better mental or digital log of these cases).  I am going to fix this issue once and for all once I get past this thesis unless anyone wants to take it up sooner:

https://github.com/mostaphaRoudsari/Honeybee/issues/339

-Chris

Permalink Reply by Theodoros Galanos on May 2, 2015 at 7:33pm

Just wanted to add, I get another small funky warning lately. As I said not in my work pc today so I can't remember it word for word. But it was something to do with Energy Plus version. It said something like it found '8.1.0' instead of "8.1.0". 

I'll paste the actual error tomorrow, if this didnt help.

Kind regards,

Theodore.

• ‹ Previous
• 1
• 2
• Next ›
• Page