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.
Hi @compdesignernz 
,
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.
). 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 
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!!
Antoine
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.
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?
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.
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 
The process is as explained above: making basic surfaces and extruding them vertically. Very low tech 
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?
myBuilding_daylight-energy-sim.gh (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.
