Hello everyone.
I’m getting a very persistent vertex mismatch error between differing zones. I am trying to model a double skin facade by making plenum rooms on the outside of a tower building. I have made this kind of model in the past with success. However, in my current model I keep getting the infamous vertex mismatch error and I’m starting to get frustrated since I have done and redone the geometry for the fifth time, each time slightly changing how the geometry was generated. What I get is a long list of errors which look like this:
** Severe ** RoofCeiling:Detailed="DSF_93_C476FA38..FACE2", Vertex size mismatch between base surface :DSF_93_C476FA38..FACE2 and outside boundary surface: DEPARTAMENTOS_24_292B4BEF..FACE8 ** ~~~ ** The vertex sizes are 20 for base surface and 18 for outside boundary surface. Please check inputs.
I have used HB Intersect Solids and I made sure that every face has its corresponding adjacent condition. I have no clue why it says the problem is a RoofCeiling surface, since these are supposed to be wall boundaries.
Hi @Gspahr, it will be really hard to say without seeing your model. If I have to guess you’re probably creating a line like face after intersection. You can use the name of the face with the issue and look it up inside the IDF file and then use those vertices to recreate the face inside Grasshopper and see what’s going on.
Thanks @mostapha, I had to clean up the file a bit since there was a lot going on. As far as I could check, there is no line-like face in the geometry.
I’ll try to take a deeper look at this later since you should not be able to get this error when your Honeybee model is valid but I’ll just generally say that you should not really be modeling a DSF in the way that you have. Trying to model the DSF as one Room that goes across all of those stories is just not a good way to model something like this in EnergyPlus since there’s no way that the air is going to be well mixed across such a thin and large geometry. If you really badly needed to model this as explicit geometry, you should be breaking up the DSF such that you have one Room per story and orientation.
But my official recommendation for how to model something like this is that you should be using a construction. To account for the change in insulation that you get from opening and closing air flow through an assembly like that, you can use the Window Construction Dynamic along with a control schedule that that dynamically changes its insulation level.
Thanks @chris, I’ll take your advice. I’ve tried a few combinations, one of which was a single DSF geometry per room (which also led to the same vertex mismatch error).
I had wandered away from doing it as a construction because I wanted to account for the air flow dynamics of the DSF throughout the year, but I’ll try the workaround.
Can you upload a version of this? With so many Faces in your model, I’m having a hard time figuring out how your model is passing validation while also causing this EnergyPlus erro. But, with a sample that has fewer Rooms, I can hopefully figure out what is going on and get you a definitive answer.
@chris, here is an isolated case for you to be able to recreate the issue. The message from the EnergyPlus error is a bit misleading. The number of vertices are the same but the order of them are different that confuses EnergyPlus.
I have another model which produced it. I “solved it” by assigning an Adiabatic BC to them to move on with the project - it’s the same model that I sent over to @mostapha in the Pollination Forum as a DM.
The problematic faces are funky looking n-gons, but couldn’t figure out why they are failing and the rest with similar geometry are not. Unfortunately can’t share it here, if it is interesting I can send it to you as a DM.
From the sample, it is clear to me what is going on and I can see now that this issue only affects Honeybee Faces that satisfy all 3 of the following criteria:
The Faces are adjacent to one another
The Faces have holes in them
The closest vertex of the outer boundary of the Face to the nearest hole is the upper-left vertex.
It seems that you managed to build a model that wins the lottery and satisfies all of these cases. The last criteria is particularly tough to encounter but, when you have a model that has Faces with holes for every orientation, one of the orientations is bound to cause this issue.
Let me think of the best way to solve this since there are a few ways to do it but, given how rare it is to have geometries with holes in just this position, I don’t want to slow down everything else too much just to get this edge case working. I’ll report back when I have a fix implemented.
FYI, in the meantime, you can solve the case by splitting the DSF zones into two such that the holes are no longer closest to the upper-left vertex.
If it’s the same error and the problematic faces in this other model had holes in them, then this is probably the same issue as what you have here. Let me get this case fixed first and then we’ll test if your other model works.
Man, I can’t believe it. The issue was because I was not rounding the number of decimal places for the vertex coordinates. So we technically had two coordinates that were the same but, because they differed by 0.0000000001, EnergyPlus complained that the vertices were not equivalent to one another ¯\_(ツ)_/¯.
I guess this only affected this particular case with holes in this position because the upper-left vertex gets repeated when the Face gets squashed into a single list of vertices. So this rounding error meant that one of the repeat vertices was not the same by a very tiny amount.
In any event, I just pushed a fix for this:
I verified that the simple model simulates correctly after the fix:
Amazing, that’s less than a nanometer… I mean, we’re talking atom sized tolerances! Could it be that it’s my fault since I generated the geometry with a tolerance that is too small for practical use? I usually crank up the tolerance in Rhino and just type in a bunch of zeroes after the comma.
Anyway, I will try the fix later on. Thank you very much, @chris!
No, it’s not your fault. I would point a lot of blame at the fact that EnergyPlus wasn’t designed with a concept of tolerance so it complains if the coordinates of the geometry don’t match perfectly (even when they differ by floating point tolerance, which is a universal concept of practically all computer languages). In any event, we designed Honeybee and the HBJSON schema with a concept of tolerance. So we have taken it upon ourselves to correct for EnergyPlus’s lack of this concept when we translate things from Honeybee to EnergyPlus. What you found here was just one of those edge cases that we hadn’t corrected for yet.
I also wanted to circle back to my original comment and say that I think the way you are modeling this type of DSF is still a valid way to do it. The main reason why I suggested using Window Construction Dynamic is because this explicit geometric modeling of an opaque DSF is just a lot of work for something that isn’t likely to influence the energy balance much. Opaque conduction just tends to be a very small term of energy balances compared to window conduction and solar gain. But, particularly if you are studying the impact of this strategy on a single apartment or floor of an apartment building, I can understand why you might want to be this detailed. To this end, I would recommend modeling it a small scale and making sure that it can actually make a difference in the energy balance before going to model it on a multi-story model.
I see that, even though the issue with Mostapha’s minimal sample file is fixed after the update, your large model still has some issues. I will try to investigate when I get the chance.
I am sorry that it took me a while but I have finally figured out how to make this work. My initial assessment was correct that the issue only affects adjacent Faces with holes where the hole is closest to the upper-left vertex. I tried a few different ways to get the error to go away and have the simulation proceed but the only one that worked consistently was if I reversed the vertices for the Face that had the hole closest to the upper-left vertex (such that it now perfectly matches its neighbor).
I was a little nervous about doing this at first since reversing the vertices technically flips the normal direction of the surface in EnergyPlus. However, I think this should be ok because I implemented this in a way that it only affects Faces with an adjacency (Surface boundary condition). So this won’t impact the solar calculation at all given that these adjacent surfaces never have any outdoor sun exposure. Furthermore, we always override the volume of each Room/Zone in the IDF using our geometry methods in Honeybee to compute the volume. So this means that flipping the normal won’t cause EnergyPlus to incorrectly autocalculate the Room volume. Lastly, EnergyPlus runs successfully without any severe warnings related to the flipped surface. So all of this leads me to believe that this is probably a valid way to handle this case.
I imagine that the underlying source of the issue is that this E+ vertex size checking function isn’t built to handle the case where the upper-left vertex repeats itself in the list (as is the case when you need to wind inwards to cut the holes out of the shape and then come back out to the outer boundary to define the edges of the shape). So E+ must be matching the wrong one of the two repeating vertices to the adjacent Face. I might report this on the EnergyPlus GitHub since this feels a little bit like a bug. But I don’t know how interested the E+ developers are in addressing these edge cases for geometries with holes, particularly when it seems that I have found a workaround that enables us to still get a valid simulation.
In any event, the fix has just been merged into the code base:
You should be able to get it on your end using the LB Versioner within an hour or so.
I also verified that the larger 75-room model that you uploaded, @Gspahr , can simulate correctly after the fix. Let me know if it also fixes your issue @furtonb .
Could it be that it’s my fault since I generated the geometry with a tolerance that is too small for practical use? I usually crank up the tolerance in Rhino and just type in a bunch of zeroes after the comma.