Thank you for sharing the model. I was able to fix the adjacency error by running the PO_RebuildRooms command to recreate the faces and remove all the adjacencies and then re-run the PO_SolveAdjacency command to solve the adjacencies correctly.
I could have used the PO_ResetBoundaryCondition command too but I noticed a few degenerated faces errors in the EP error - that’s why I rebuild all the faces to do a cleanup. I also moved the doors that were very close to the edge of the room a bit inside.
That brought me to this error about two adjacent walls with different constructions.
It looks like that this face is set to Ground construction while it should have been set to a foundation construction based on the other interior faces. I’m not sure why this was happening (cc: @mingbo).
After fixing that and re-loading the model into Grasshopper by using clear value I was able to run the model. You can also check the Auto Sync option as an alternative solution.
I have to commend you for finding a bug in the validation routines that I’m not sure I would have ever found myself. It was a typo of a single letter that caused me to miss cases of mis-matched adjacencies only for Doors. I just put together a fix:
You should hopefully be able to get it on your end with the LB Versioner by tomorrow. Once you have the fix, the PO_ValidateModel shows you exactly where you had some invalid adjacencies for Doors:
Also, @olivierdambron . Those “harder to identify” fatal errors that you get there are because you somehow ended up with a model that you should not have been able to create with any of the plugins. In the case of your screenshot, you have a WindowConstruction assigned to an Opaque Face (eg. Wall, Floor, RoofCeiling).
This is the type of error that can cause a lot of headaches down the line but it’s very simple to just enforce it upon the creation of the Honeybee object. This way, we could give you a clear exception message about the wrong construction type instead of letting you make the invalid object with the wrong type of construction and then dealing with the fallout and the other weird types of exceptions that you might experience because the object is not of the correct type.
Neither the Rhino plugin nor the Grasshopper plugin should have let you do this. Do you remember how you created this model or how you might have ended up with a situation like this?
Did you import it from IDF and, if so, do you have the original IDF? Was this IDF simulate-able?
Can you think of any way that the Rhino plugin would let someone assign a WindowConstruction to an Opaque Face? We should be making sure that this does not happen when people assign the constructions because it will create a lot of headaches down the line if we silently let the issue pass.
Hi @chriswmackey, currently there is no easy way to group all construction types for an Opaque or Window Face, except listing each of them for the type checking.
Another idea is we can organize these constructions in the schema library. The current schema has an IConstruction interface which is auto-generated based on the folder name from the source OpenApi Schema. We can add another layer and group them based on if it is applicable to Opaque or Window.
I’ll admit that I didn’t completely follow the details of what you were suggesting but, if it means that the Honeybee UI now enforces that WindowConstructions can only be assigned to Apertures and Glass Doors, then that’s great and that’s all that we need.
Also, now that I know this has been an issue, maybe it’s also worth checking that the UI enforces that ShadeConstructions can only be assigned to Honeybee Shades and nothing else.
I would suggest enforcing that non-air_boundary Faces must use OpaqueConstruction. The core Python libraries also enforce this.
However, we technically let air_boundary Faces accept either AirBondaryConstruction or OpaqueConstruction. I think I realized that the latter case is useful for certain specific AFN situations. I can’t remember exactly what this was but it was helpful for working around some limitation of E+.