Energy simulation, the run time is very high

[Aliarch]

Hello friends
I modeled a complex shading that contains a large number of surfaces. In daylight simulation everything is ok; But in the energy simulation, the run time is very high and it takes about 4 hours and does not end. While when we disconect the shedes from the model, the run time is reduced to 3 minutes.
According to the picture, I turned the shades from Brep to mesh and finally joined them.
Is there another solution to turn them all into a mesh object (one)?

[TrevorFedyna]

That looks about on path with having a ton of complex shading geometries in an E+ simulation… time wise that is.

Try “flattening” the input to mesh join; if that doesn’t work; I’d need the *.gh file to be of more help.

Also: E+ sim time related questions:

1. Are you using pixel counting or polygon clipping for your Shade calc method?
2. What timestep are you running the simulation for?
3. Are you able to use peak or annual loads components in-lieu of the full energy simulation in this case?

---

While simulating shading with high-geometric complexity; there’s not too much that can be done in terms of getting huge boosts speed wise, as far as I know.
Just a hand full of things you can do to optimize your simulation.

I hope that helps?

[Aliarch]

Thankful @TrevorFedyna
I flattened the trees, but still run-time was not normal. I put the GH file; Thanks for taking a look that.

[Aliarch]

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

[charlie.brooker]

At a guess I’d expect pretty similar number of shades to be produced from the Shade component whether you send it Breps or meshes. The Shade component will mesh any brep input for you, and output the individual faces as HB shades. I’d recommend working with your geometry as a mesh and looking for a way to significantly reduce the number of faces before creating your HB Shades, that should speed up sim times.

Also worth being aware by default e+ only calculates shade factors once per month (12 sets of shade factors per year). So all the detail you’re going to in the geometry definition is arguably lost due to the lack of detail in the simulation. You can adjust this to hourly shading factors at the cost of increasing simulation time.

[Aliarch]

Thank you for your answer @charlie.brooker
I realized the problem was the geometry, not a large number of shades; But whatever I think, I see no flaw in the geometry algorithm. According to previous experiences, we turned the produced trimmed surface into mesh and the energy analysis was done easily. I feel there is something new and hidden here. I hope @chris elps too.

1. ** Severe ** CheckConvexity: Surface=“SHADE_217DDA10_18” is non-planar.
2. ** Severe ** CheckConvexity: Surface=“SHADE_217DDA10_24” is non-planar.
3. ** Severe ** CheckConvexity: Surface=“SHADE_217DDA10_8” is non-planar.
   
   

[dmitry]

This kind of shading geometry is handled very poorly in e+. I would suggest having a look into LBNL Window tools to generate a BSDF file to approximate the shading and attaching it to a window construction.

I’m not sure if the BSDF import option is available in LBT 1.0+ version, but it was available in the legacy plugins. You might want to check the following threads as well:
BSDF Microshade in Energyplus - grasshopper / honeybee-legacy - Ladybug Tools | Forum
Assigning - Construction:ComplexFenestrationState to window - grasshopper / honeybee-legacy - Ladybug Tools | Forum

UPD: should be working with the new LBT as well:

[chris]

Hey @Aliarch ,

Yes, that’s a risk of using meshes to represent the geometry. When you use meshes instead of breps, you sometimes get quad meshes that are not planar. It’s not a very common occurrence and it usually does not change the results much but I’ll try to add something that addresses this case soon so that you don’t get that E+ warning.

In the meantime, I think you can still trust your results but, if you are going to do this type of simulation in the future, you should really use the PixelCounting Shadow Calculation method in EnergyPlus since it’s much, much better at handling simulations like this with large numbers of shade geometries.

@dmitry 's suggestion of using BSDF is also a good one but, if you want to use a BSDF in EnergyPlus right now, you’ll have to use additional strings in the current Honeybee plugins. Honeybee only supports BSDF in Radiance simulations at the moment.

[chris]

FYI, I added some extra checks to ensure that non-planar quad mesh faces are always planarized before export to EnergyPlus:

fix(planarize): Add some extra checks to ensure everything is planar

However, from what I can tell, this may actually be some bug in EnergyPlus since I verified that all of the geometry is planar to within the model tolerance but I still see EnergyPlus still gives the warning. I know that EnergyPlus’s geometry engine is not the greatest so this might be a situation where we just have to trust the better geometry engines of Rhino and our ladybug_geometry library over EnergyPlus’s.

[Aliarch]

Hi @chris Thank you for your effort
Of course, I found the exact cause of the problem several days ago, but I did not have time to discuss it here. The problem arises precisely from Rhino, to which Energy Plus is very sensitive. I came to the conclusion that the Trimmed surfaces could not be analyzed by Energy Plus; As a result, my modeling was limited. I created a complex shadings with a large number of shades so that all surfaces were in Untrimmed surface, and with this method I performed the analysis correctly. Now, do you mean to fix this problem? It means that now you can also run with Trimmed Surface !!!
My current method that works correctly:
Produce Untrimmed Surface and then turn them into mesh and finally import them into Shade Component.