Simulation error for Annual Daylight and Custom Energy Simulations

Hi, @mostapha.

I ran some simulations for a file overnight, and it looks like the file failed at this point.

I ran an iteration of the design in pollination and it worked fine, so I am unsure as to why the simulation failed when running multiple iterations at once.

1 Like

Hi @compdesignernz :wave:,

Sorry you’re experiencing issues with our platform. I had a look at the jobs you submitted and two different issues occured when executing your jobs.

  1. Custom energy sim: it looks like the runs are failing because something is wrong with your model. If you click on one of the Runs and then go to the “debug” tab you will be able to click on one of the failing tasks and check its logs to understand what went wrong. If you’re not sure what’s happening then maybe @chriswmackey is best place to help you debug your model.

  1. Annual Daylight: this error was because of something wrong on our end. We had set a duration limit for each run to be 8 hours (while we are in early access to avoid bugs where jobs go on forever :upside_down_face: ). Each run can take quite long because we allocate 100 CPUs per account to execute all jobs. This means that each Job, and then each Run inside of a job is competing for CPUs. We have changed this setting now which should allow your new annual daylight Job to finish successfully :raised_hands:

It’s worth @'ing either myself (@antoinedao) or @tyler when encountering issues with the cloud platform as we are the team in charge of that part of the Pollination product!

Thanks for testing out our platform and looking forward to more feedback!!



Hi @compdesignernz, I double checked your model using the Rhino plugin - and from the error messages I could fine the problematic zones. Here is one example that Room_27074 has no roof/ceiling.

Then we have Room_27064 with similar situation.

The error message about not being able to resolve adjacency is because it’s trying to solve the boundary condition between a floor and a wall and the constructions don’t match.

How did you create this model? I can see that all the surfaces between the rooms are wrongly set to Wall instead of RoofCeiling.

This might be a bug on our plugins side.

Finally, for the parametric job, since you are not renaming the model the last model is overwriting the first model so all the results will end up being the same. You must rename each model to have a unique name when creating parametric studies.

1 Like

Hi @mostapha .
Thanks for your help on this. The way I modelled geometry was by tracing a floor plan that the architect has given me, creating surfaces from those bounding curves and then extruding to create solids. I am unsure as to why the constructions are wrongly assigning to the model.

Thanks for the note on renaming models. I thought you had to rename the run, rather than renaming the model. I’ll add that capability to my script. @antoinedao thanks for updating the run time capability of pollination. It is much appreciated! I totally understand the quota allocation side of things, so no worries there! I’m assuming that Mostapha’s answer is the answer for my energy sim issue? What would be the best method to mitigating this in the future?

1 Like

The problem is not the construction. It’s the face type which is said to wall instead of being a roof or ceiling. Any chance that you put the wrong angle for separating walls from roof? I assume you used grasshopper to create the analytical model.

If that’s not the case then I’ll be really interested to see how did you set up the creation of rooms and how did it go wrong.

Yes. That should fix the problem. If we can identify the source of the issue then I should be able to provide some suggestions.

1 Like

I did not use grasshopper to create the rooms. I was working off a pdf import which is incredibly backwards, but that is all I could get from the architect :cry: The process is as explained above: making basic surfaces and extruding them vertically. Very low tech :laughing:

Sorry if I was not clear. I meant how did you create the analytical model after creating the solids? Did you use the Grasshopper plugin to translate these solid geometry to honeybee rooms?

Ahhh, yes. I referenced the geometry into a pipeline component and fed that into a HB Rooms from Solid component. I made a construction set for the rooms, as the wall, floor and roof surfaces all have different R-Values. I applied that to the "construction set’ parameter of the HB Rooms from Solid component. I have used data params between functions as that is standard practice with all my grasshopper workflows. Would this be an issue? I also used HBIntersectSolids to solve for collisions

Thanks for clarifying that you used the Grasshopper plugin. The “HB Room from Solid” component isn’t supposed to turn horizontal surfaces into walls so I would like to know a bit more about what is going on. Did you set the _roof_angle_ input to 0 by any chance?

Also, if you could share the .gh definition, that would be helpful and it could help me tweak the component to ensure that it’s harder to get cases like this in the future.

Looking at the “HB Room from Solid” component, I have to imagine that you somehow set the _roof_angle_ to 0. I guess, when I originally wrote the component, I was thinking that there could be some cases where you might want to set all of the faces to be walls or roofs/floors (eg. modeling a geodesic dome building where the roof and the walls are the same).

But, if it’s going to cause people to have more issue than it helps, I can throw an error when the input angle is 0 or 90. What do you think @mostapha ?

For flat roof should the angle be set to 90? I was imagining that this angle was the pitch angle of the roof and therefore 0 degrees. I have therefore set this input to be 0. For a flat roof, what should this angle parameter be instead, if not 0 or 30?

1 Like (171.0 KB)

Ok, maybe we just had a bad input description. That’s not what the _roof_angle_ input does but I can see that the previous description was pretty vague. I just changed it to be the following

roof_angle: A number between 0 and 90 to set the threshold below which faces
will be considered roofs instead of walls. 90 indicates that all
vertical faces are roofs and 0 indicates that all horizotnal faces
are walls. (Default: 30).

This should help avoid this situation in the future. Also, you should always check your geometry using the “HB Visualize by Type” component, @compdesignernz .


I think there are valid use cases for 0 or 90. I feel the approach of improving the input description is the better option.