Hi everyone,
Just a sanity check. Is my interior wall orientation crucial to energy simulation in multi zone models (you know the slight discolouration in the Rhino/Grasshoper brep preview)?
I would hope it isn’t as it is a mindbong manual labour to orient everything one by one 
Kind regards,
Theodore.
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.
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.
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.
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.
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
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.
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
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.
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.
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
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
Hi everyone,
Sorry for being away, been kind of busy.
Mostapha, I will try and email the model the coming days. The tricky part is that I can’t really share it online due to confidentiality issues.
I did however run into a similar problem in another much simpler model.
How on earth should I model simple, low-rise appartments? The floor layout changes from level to level. I ended up breaking up the floor/ceilings every time I added a level to the model. Resulted in a pain in the ass modelling process and similar azimuth errors. However, this time I feel it’s because of me.
Is there a better way to simulate this? I know intersect masses does this (from Chris’s video tutorials) but if I’m not mistaken in that case it was breps and not honeybee zones. There must be a better work flow however
Also, stupid question, what do we do with floor/ceilings. I mean since I am supposed (I hope I’ve been understanding Mostapha correctly in this whole post) to use the same surface as floor and ceiling between two levels, can I change orientations without internalizing? Or do I need to internalize?
Sorry for the mess of questions. I’m attaching the model. I internalized all the breps in one of the two buildings (LEFT).
Kind regards,
Theodore.
TypeC.gh (1.44 MB)
After reading this https://unmethours.com/question/2336/what-is-the-difference-between… I am even more confused and even more certain it was my modelling fault.
Does this mean I need to duplicate the surfaces? Is a flip on the brep enough or do I need to create a new surface? Or is this that Honeybee handles by itself (i.e. the normals)?
Kind regards,
Theodore.
Hi again,
Sorry for the onslaught of messages. I managed to run the simulation with no severe errors when I input every floor’s solve adjacencies separately in the energy plus component. I imagine the results are a bit compromised like this but it at least tells me the errors are between the floors, so in the way I set up floors and ceilings.
Thanks in advance.
Kind regards,
Theodore.
Theodore – To answer your initial question "is interior wall orientation crucial to energy simulation in multi-zone models?”. Answer: Yes, very.
EnergyPlus needs to know what bounds each thermal zone and which side of the surface “outside” is, and E+ knows this by the order vertices are entered. E+ requires surface normals to be oriented uniformly (facing outwards, away from the individual zone volume) and all thermal zones need to be fully enclosed, defined by its own set of surfaces.
Therefore, a two zone model with a shared wall requires the dividing wall (ceiling/floor) to be defined for each zone independently. Although these surfaces will have the same x,y,z coordinates and occupy the same plane, E+ will see them as boundaries defining each individual zone so wall assemblies can be applied and the energy transfer calculated correctly. Omitting one shared plane will result in E+ throwing errors at you.
Taking this a step further: if a ceiling in thermal zone Z1, has a thermal zone above it (Z2) that occupies only a portion of the total surface area of the ceiling, with the remaining area as a roof, the “outside” boundary conditions for Z1 ceiling varies (part is a ceiling/floor of Z2 and the other is ceiling/outside) and E+ needs to know this by dividing the ceiling surface accordingly. Thus your ceiling of Z1 will need to be made of two planes one that relates to the floor of Z2 and one that is ceiling/roof material. In other words; when adjacency conditions of a zone’s surface changes, E+ needs to be informed of this condition by defining a new surface.
It may be too late in the night to try to write technical explanations, so I hope this explanation helps clarify rather than confuse.
Cheers
Hi JPE,
Thank you very much for your response, helps clarify things a bit. The articles I’ve been reading state similar strategies.
I want to say that I did follow this in my model (hopefully). The way I understand it, in Honeybee, I need to manually breakdown the surfaces that account for ceiling/floors when the floor plan between levels changes. I believe I did that in my model. However, I was not sure (and still not sure) if Honeybee handles the assigning this “outside” automatically between zones after the zones have been set on per-surface level.
That said, I realize now that I have both exposed floor and exposed ceilings in my model which I wrongly grouped together with all the other floors and ceilings. I will try to remedy that. But given the error log from E+ I think that I have boundary issues in most if not all interfaces between levels (even after I correctly assigned the normals).
As I sad in the previous post, not solving adjacencies between levels and simply dragging each solve adjacency output from each level allows me to run the simulation without the fatal errors, but I have to wonder on the validity of my results.
Kind regards,
Theodore.
Theodore – The severity of E+ errors can have varying effects on results, so live by the mantra “garbage in = garbage out” when working with energy simulation tools and always clean up your model!
Some minor errors simply state that a mathematical impossibility occurred in the calculations, for example, that the RH point dropped below zero. While other errors signify major issues that need to be addressed before any results are to be trusted. Adjacency errors, although not fatal, need to be corrected. For more detailed help with specific errors try the E+ support group over on Yahoo Groups : https://groups.yahoo.com/neo/groups/EnergyPlus_Support/info
Cheers – J
Hello,
I am also working on a two story house model based on surface-by-surface method. Based on the construction drawing provided, It has very sharp inclined roof structure thus the interior space ceiling surfaces are complex (not flat). Although I have checked the reference breps (where surfaces are made from) the energy simulation component gives the “Surface Azimuths do not match” error.
And wondering if this issue fixed completely in the code.
Thanks,
Amaraa