Hi, I have a large model with 3040 rooms. It crashes every time I try to validate the model. I’m wondering if there’s a limit of the number of rooms that Pollination can handle. Sorry I can’t share the model.
Hi @xavierzhou, Sorry about the issue. There is no limitation on the number of rooms. Does the issue happen if you run the validation for a portion of the rooms using a selection?
My best guess is that this is happening because of some unhandled errors. Can you try this and see if it makes a difference?
-
Save the model as an HBJSON.
-
Open the attached Grasshopper file.
-
Right click on the File Path and select the HBJSON file.
-
Double click on the Boolean to load the HBSJON, and run the validation command.
validate-model.gh (10.1 KB)
1 Like
Hi @xavierzhou,
I just saw your message and wanted to confirm that large models with >3000 rooms are managable within Pollination. I was also wondering if the tool could handle large models and wanted to test it with importing a large idf file. In the end, after loading for 4-5 minutes, model was ready to fix/clean up inside Rhino.
Thanks,
Levent
2 Likes
Hi @mostapha ,
- Yes, I was validating selected rooms only, which is a portion of the whole model. But it doesn’t seem to be the problem. I saved the selected rooms to a new model, and tried to validate the whole model, it still crashed.
- Rhino still crashes when I try to validate a large number of rooms which I believe are free of errors. I tried to test the validity by another way: throw the rooms (after solving adjacency) to a HB Annual Loads simulation. And the simulation runs okay! So I think the model is valid, am I right?
- Point 2 leads me to wonder if my laptop is not powerful enough to handle such a large model. Any advice? Which specs should I improve?
- This is the third time I’ve tried to use the ladybug tools / E+ to do energy modelling for this project - same project but different design stages. The first time a couple of years ago without Pollination, so I burnt many nights cleaning up the geometry. The 2nd time (about 6 months ago) and this time both with the aid of Pollination. But I’m still spending weeks to clean up the geometry. The Rhino plug-in is great in cleaning up any individual floors, but it’s still a very painful process to handle multiple floors with very different room layout. The rooms on one floor would leave imprints on the floors above and below that could easily lead to tiny edge or invalid geometry errors. Short of any major improvement in the near future, I think I’ll have to give up this workflow altogether and return back to IES. I’m not sure if any other users face the same problem. Could you please share your thoughts and your plan to address this issue?
- In particular, could you please help understand why E+ is so stringent on the geometry accuracy? Does tolerance setting in Rhino make any difference? If the unit is meter, is there a recommended absolute tolerance?
Thank you.
Xavier
Hi, @xavierzhou,
Thank you for your response with detailed information. It feels like we need to help you to get from trough of disillusionment to the plateau of productivity. Here is the reference. 
Sorry about that! Is there a way to rename the display names and program types and share part of the model with us to recreate the issue. Can you share the Rhino crash report with us?
@mingbo, do we log any information about the crash cases that we can use for this scenario.
Yes. If the simulation runs correctly, then the model must be valid.
This can potentially be the issue, but I doubt it. Do you see your laptop running out out of memory before the crash happens? The spec depends on the size of the models that you have to deal with.
If you are able to build every level quickly, you should be able to build the combination between them also as quickly. I have done that for several models, and I share my approach below.
There is one clear item that can be improved. The tiny edges are not a validation issue. We show them to help users find and clean them up but, in most cases, you can run the model with tiny edges, and the simulation will run fine.
I think we should stop showing them as an issue and add a command to help the user find them only if they are interested in the additional clean up. This is something that @mingbo and I discussed before.
Reading this makes me sad! It feels like we have failed to deliver on our promise. 
At the same time reading what you shared above gives me hope that you are very close. As I said, if you can get one floor clean quickly, you should be able to get several floors clean using the same routines. It looks like your main issue is that the intersection between the floors is causing tiny edges (that you can ignore), or line-like faces that are hard to debug.
My approach is:
- Clean up every level, and ensure the level is valid.
- Start the solve adjacency between two levels from the bottom. Run the validation of the two level.
- Run the
PO_ShowAdjacencycommand to find small alignment issues in the two level. - Use the
PO_RebuildRoomsto merge the faces again, and use thePO_AlignInPlan,PO_AlignToRoomto fix them. - Repeat with the next level. Many times, I find certain axis, that should be applied to multiple floors. That’s when I run the
PO_AlignInPlanfor multiple levels together to save time.
This is something that we can help you with, but we need to better understand the source(s) of the issue. Is it the geometry clean up? Is it that our validation report has been misleading? Is it that you just need a better laptop?
I understand that you can’t share the model as-is, but can you share part of the model with us? Or can we set up a call and share screen to see what do you have to deal with?
@chriswmackey can answer this question better than I can do. But I can tell you that even with all those limitations, you should be able to prepare your model in an acceptable amount of time. We have recently helped a yacht company make an EnergyPlus model of the yacht with all the rooms and geometry complexities. All the adjacencies are solved between the rooms and the model is valid. When that is possible with the Rhino plugin, modeling a building with extruded geometry should also be possible! 
hi @mostapha, I tried checking, but I can’t seem to find the PO_ShowAdjacency command. which version is this available? or did you mean PO_checkadjacency?
I just wanted to second this point here:
All of our translators to the simulation engines automatically remove the tiny edges and duplicated vertices as part of the export process. So you never need to fix these and you really don’t need to be made aware of them at all. I think @mingbo just had some concerns because Rhino SDK makes a note of them but we really should just take the messages about them out of the Rhino plugin. Maybe if people are trying to be perfectionists, we add a PO_RemoveTinyEdges command that does the same thing we do in our simulation engine translators.
While the tiny edges are unnecessary, this is unfortunately not true:
The inverse is true where any valid model should simulate in EnergyPlus (or any of the other simulation engines). If not, then it’s a bug that we will fix. But EnergyPlus lets you simulate all kinds of incorrect stuff that would not be a proper representation of real geometry like open room volumes, rooms with incorrect floor area because what should be a floor is set as “roof” or “wall,” and tons of other things that are clearly wrong but not un-simulate-able. These cases that are clearly wrong are all caught by our validation routines.
This is a tough one as we are all not EnergyPlus developers. But I get the sense that a robust geometry engine was never really a goal of the E+ project since it was always imagined that companies developing interfaces for E+ would figure out the geometry part. At least that is the picture that I get from that fact that I have not seen a E+ geometry feature be prioritized or funded in the last decade. Maybe with the exception of the AirBoundary capability, but it’s a little liberal calling that a feature of the E+ geometry engine.
So we’ve ended up with an EnergyPlus engine that is incredibly picky about meaningless geometry issues like colinear vertices but it also can’t handle things like windows with more then 4 vertices. Nor can it perform basic checks like automatically flipping Surface geometries so they are correctly pointing outward from the room volume. All of these get handled as part of the translation process from Pollination/Honeybee > EnergyPlus and there’s a ton of idiosyncratic stuff about E+ geometry that you never need to worry about because we fix it for you automatically. You just have to focus on fixing the validation issues and we will take care of everything else.
Tolerance is an incredibly important concept, which we thankfully learned a lot about by watching what McNeel did. EnergyPlus has a native absolute tolerance of 1cm, which cannot be changed and I have not seen documented anywhere but it clearly exists and you can prove it to yourself with some simple test simulations. In Pollination, we let you work in any tolerance you want and, as long as your model is valid at that tolerance, it will translate correctly to the E+ native tolerance. If you want your models to match E+ exactly, then you can use a Rhino model tolerance of 0.01 meters. But I do not recommend changing your model tolerance half-way though building it since you can start to get some strange behavior this way. Granted, this strangeness is still fixable if you do happen to change the tolerance. But you’re usually making more work for yourself by changing it.
You mentioned IES and we have bee in communication with them about what tolerance they use but, from the looks of it, it seems like they use a different tolerance for different parts of their software. For example, the tolerance used to evaluate whether a room is solid is different from the tolerance used to evaluate whether a Surface is planar. We’ll post back here if we get more info from them but the best recommendation I have is just get your Pollination model to be valid at its tolerance and 99.9% of the time IES should accept it.
1 Like
Also, if Rhino is crashing and closing on you, @xavierzhou , this is probably a bug. If you are able to PM us with a file that helps us recreate it on our end, there’s a high chance we can fix it.
I’m interested in this topic, and tried “Validate Model” with my model with around 2600 rooms. Rhino crashed and closed.
@chriswmackey @mostapha I can share my model by Message.
Yes! That is the project.
The issue with crashing has been addressed already. The source of the issue was with memory management issue in Eto. The issue is resolved by adding an intermediate step for large models before opening the Eto form.
1 Like