1. Solution exception: Fatal GetSurfaceData: Errors discovered, program terminates

olivierdambron · March 16, 2023, 2:39pm

I´m having trouble with plugging the pollinaton rhino model (validated) to grasshopper.

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.

The errors say:

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!

mostapha · March 16, 2023, 2:59pm

Hi @olivierdambron - Based on the error message, a few internal doors are missing the other surface. Can you share the model with me? Also, see this (https://discourse.pollination.cloud/t/failed-energy-simulation/2451). It looks like you have already resolved those issues.

olivierdambron · March 16, 2023, 4:05pm

Hi @mostapha ,

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.

Here are the files, if you can take a look:
230316 - 3d model.3dm (8.0 MB)
230316 - Thermal script for mostapha.gh (278.4 KB)

Let me know if I can provide any info.

Best,
Olivier

mostapha · March 16, 2023, 5:46pm

Hi @olivierdambron,

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.

I used the Room ID to find the room and the problematic face.

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.

Here is the updated Rhino model.

230316 - 3d model - 2.zip (1.3 MB)

Let me know if you have any other questions!

@chriswmackey - should we add the check for constructions of adjacent faces to the validation routine?

@olivierdambron - looking forward to hearing your feedback about the Rhino plugin as you use it on more projects. Cheers.

mingbo · March 17, 2023, 5:39am

From the screenshot, it seems the construction is set by users. Is it correct @olivierdambron?

olivierdambron · March 17, 2023, 6:26pm

Hi @mostapha ,

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.

Cheers,
Olivier

chriswmackey · March 20, 2023, 4:26pm

Thanks @olivierdambron and @mostapha

There’s already one there

github.com

ladybug-tools/honeybee-energy/blob/master/honeybee_energy/properties/model.py#L934-L949


      
          This method will also check to make sure that two detailed HVACs do not
          reference the same room and that all rooms referencing a detailed HVAC
          have setpoints.
          
          Args:
              raise_exception: Boolean to note whether a ValueError should be raised if
                  DetailedHVAC reference Rooms that are not in the Model. (Default: True).
              detailed: Boolean for whether the returned object is a detailed list of
                  dicts with error info or a string with a message. (Default: False).
          
          Returns:
              A string with the message or a list with a dictionary if detailed is True.
          """
          detailed = False if raise_exception else detailed
          all_err = []

So you should not have been able to get that error with a valid Honeybee Model.

I’ll take a look at why the validation command didn’t tell you about all of these invalid cases when I get the chance.

olivierdambron · March 20, 2023, 6:28pm

@chriswmackey thanks!!

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.

with Error

with Report

chriswmackey · March 20, 2023, 8:21pm

Hey @mostapha ,

In your sample, I see that I get all of the ValidationErrors about the mis-matched constructions.

Did you try running the PO_VAlidateModel command before you tried re-simulating in EnergyPlus?

@olivierdambron ,

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:

Thanks for finding and reporting the bug.

chriswmackey · March 20, 2023, 8:33pm

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?

olivierdambron · March 28, 2023, 1:37pm

@chriswmackey
I’m glad I picked up a bug! Thanks for being so reactive !

The model was not imported from an IDF but was in fact modelled with the Rhino Plugin.
It went through successive Undos, moveedge, moveface, rebuild, delete, it’s quite hard to find it back.

I will report here any findings.

chriswmackey · April 6, 2023, 7:00pm

Ah, thanks for confirming this, @olivierdambron :

@mingbo ,
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.

mingbo · April 10, 2023, 12:37pm

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.

mingbo · April 10, 2023, 1:20pm

I manually added IWindowConstruction and IOpaqueConstruction for now to limit Honeybee.UI for this case.
fix(IConstruction): add IWindowConstruction, IOpaqueConstruction by MingboPeng · Pull Request #241 · ladybug-tools/honeybee-schema-dotnet (github.com)

chriswmackey · April 10, 2023, 4:12pm

Thanks @mingbo ,

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.

mingbo · April 11, 2023, 2:26am

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.

Thanks @chriswmackey, this is helpful. Would you suggest enforcing AirBoundary face can only be assigned with AirBoundaryConstruction?

chriswmackey · April 11, 2023, 4:23pm

Thanks, @mingbo .

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+.

mingbo · April 13, 2023, 9:32am

Thanks @chriswmackey, the Honeybee.UI has been updated with all above enforcements. The next release will include this update.

1. Solution exception: ** Fatal ** GetSurfaceData: Errors discovered, program terminates

1. Solution exception: Fatal GetSurfaceData: Errors discovered, program terminates