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, 4:09pm

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.

mostapha · March 16, 2023, 5:46pm

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


      
          def check_interior_constructions_reversed(
                  self, raise_exception=True, detailed=False):
              """Check that all interior constructions are in reversed order for paired faces.
          
          
    Note that, if there are missing adjacencies in the model, the message from
              this method will simply note this fact without reporting on mis-matched layers.
          
          
    Args:
                  raise_exception: Boolean to note whether a ValueError should be raised
                      if mis-matched interior construction layers are found. (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.
              """

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?

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

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