I´m plugging it to a “HB model to OSM” but there´s apparently problem with doors that weren´t a problem in the rhino pollination model once it was validated.
Solution exception: ** Fatal ** GetSurfaceData: Errors discovered, program terminates.
** Severe ** FenestrationSurface:Detailed=“DOOR_3F76A524”, invalid blank Outside Boundary Condition Object.
Do you know what could be the issue?
Thanks!
Thanks so much for keeping an eye here.
Rhino plugin is a a lot of fun to work with, but I’m still learning how things work and the best practice for modelling.
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.
Thank you so much for looking into this case and for the solution. We’re keeping notes of these precious tips and tricks.
Hello @mingbo,
you are right this is a mistake from us, that face should have been assigned as “Foundation”. No bug here.
Thanks to both, I’ll keep going with this and let you know.
I keep in mind to note any feedback I may have. So far, I’ll make 2 other posts separately.
It’s just that sometimes the PO_ValidateModel function returns a report that allows to trace back the error and sometimes in throws an error, harder to identify.
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?