Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More feedback on the offending object from SvgSerializer errors #4500

Closed
theoryshaw opened this issue Apr 2, 2024 · 10 comments
Closed

More feedback on the offending object from SvgSerializer errors #4500

theoryshaw opened this issue Apr 2, 2024 · 10 comments

Comments

@theoryshaw
Copy link
Member

I get the following error quite a bit when running drawings.

To troubleshoot, i move the camera around until i don't get the error, and then move the camera incrementally back, until i get the error again. I then deduce which geometry might be causing the problem.

This takes quite a long time, to troubleshot.

Am wondering, if there could be an output of some kind that tells you which objects are causing the error, so you can dial into them quickly and fix them, if possible.

Python: Traceback (most recent call last):
  File "C:\Users\Ryan Schultz\AppData\Roaming\Blender Foundation\Blender\3.6\scripts\addons\blenderbim\bim\module\drawing\operator.py", line 212, in invoke
    return self.execute(context)
  File "C:\Users\Ryan Schultz\AppData\Roaming\Blender Foundation\Blender\3.6\scripts\addons\blenderbim\bim\module\drawing\operator.py", line 263, in execute
    linework_svg = self.generate_linework(context)
  File "C:\Users\Ryan Schultz\AppData\Roaming\Blender Foundation\Blender\3.6\scripts\addons\blenderbim\bim\module\drawing\operator.py", line 538, in generate_linework
    self.serialiser.finalize()
  File "C:\Users\Ryan Schultz\AppData\Roaming\Blender Foundation\Blender\3.6\scripts\addons\blenderbim\libs\site\packages\ifcopenshell\ifcopenshell_wrapper.py", line 1577, in finalize
    return _ifcopenshell_wrapper.SvgSerializer_finalize(self)
RuntimeError: An unknown error occurred
@Andrej730
Copy link
Contributor

Can you please send some example triggering "RuntimeError: An unknown error occurred"? Got some idea for a script that will help narrowing it down.

@theoryshaw
Copy link
Member Author

Yes, try and run R - ELEVATION - EAST, in the following.
https://hub.openingdesign.com/OpeningDesign/Highland_Haven/src/commit/bd2401ded7db8bf456ac958f74531fed5aca9f79/Open/Models_and_CAD/BlenderBIM/Highland_Haven.ifc

The offending object is called out below...
0p2EG2ddXF_RDiEon9Jrik

image

@Moult
Copy link
Contributor

Moult commented Apr 3, 2024

I haven't found a fast way to reliably pick up the source of the error. I have a hacky script which slowly culls elements until it finds a broken combination.

Andrej730 added a commit that referenced this issue Apr 4, 2024
Turned out syncing process takes too much time on large projects, so we can speed up the printing process by syncing just once. Also exposed option not to sync to operator's properties to allow debugging failing elements.

A bit related to #4500
Andrej730 added a commit that referenced this issue Apr 4, 2024
Operator can help narrow down failing elements when drawing is failing with "RuntimeError: An unknown error occurred".

it's located in debug section - https://i.imgur.com/b03jmkZ.png

The output is noisy but the results are highlighted:
https://i.imgur.com/0ZA0u60.png
https://i.imgur.com/oXzqIXU.png
https://i.imgur.com/Y0nMRMz.png
@Andrej730
Copy link
Contributor

I added some debug operator that can help. in 797e2e4

Making it I've learned that in large projects we actually have a bottle neck in syncing elements before drawing creating. In my case creating 1 drawing took ~25 secs and ~20 secs of them was syncing objects.

Syncing iterates over all available blender objects, so it's expensive on large projects. Since all objects are synced already after first run, there is no point syncing them again for each drawing if printing multiple drawings at once, so printing multiple drawings should get faster after 5c36599.

But still need to do something about that syncing process to optimize is. The syncing method is

def sync_all_objects(self) -> list[ifcopenshell.entity_instance]:

and the most expensive part is running tool.Collector.sync(obj) for each object. Here's some profiling to get the idea what takes time in the collector.sync:
image

@theoryshaw
Copy link
Member Author

This is awesome!

So the offending object was 0p2EG2ddXF_RDiEon9Jrik, but why is the 0p2EG2ddXF_RDiEon9Jrik object under the print out that says Excluding element didn't fixed the drawing:? Seems confusing. Maybe i'm not reading this correctly.

image

@Andrej730
Copy link
Contributor

So the offending object was 0p2EG2ddXF_RDiEon9Jrik, but why is the 0p2EG2ddXF_RDiEon9Jrik object under the print out that says Excluding element didn't fixed the drawing:? Seems confusing. Maybe i'm not reading this correctly.

I thought it could be useful in some cases. When operator couldn't narrow down the set of elements any further it ends up with 2 elements that are failing - drawing any of them just by themselves doesn't produce errors but drawing them together produces an error:

Couldn't narrow it down any further.
It's some of the 2 elements:
[#4015211=IfcWall('0p2EG2ddXF_RDiEon9Jrik',$,'Wall',$,$,#4500162,#4015228,$,$), #4017076=IfcWall('0KFw8bcCf0ZAIJqgcRgSfh',$,'Wall',$,$,#4100304,#4017096,$,$)]

So it could be either one of them is failing or both of them or combination of them (they fail only when they are both present).
Excluding just one of them will help in the case if it's just 1 element failing:

Excluding element fixed the drawing:
#4017076=IfcWall('0KFw8bcCf0ZAIJqgcRgSfh',$,'Wall',$,$,#4100304,#4017096,$,$)

But knowing that excluding some of the elements that fail together doesn't fix the issue could also be useful - in cases when they are both failing / failing when they are present together.

Excluding element didn't fixed the drawing:
#4015211=IfcWall('0p2EG2ddXF_RDiEon9Jrik',$,'Wall',$,$,#4500162,#4015228,$,$)

Full output from operator without noise:

processing 462 elements
processing 231 elements
processing 115 elements
processing 57 elements
processing 29 elements
processing 15 elements
Will try to reshuffle elements and try again, attempt 1/10
processing 15 elements
Will try to reshuffle elements and try again, attempt 2/10
processing 15 elements
Will try to reshuffle elements and try again, attempt 3/10
processing 15 elements
processing 8 elements
Will try to reshuffle elements and try again, attempt 1/10
processing 8 elements
processing 4 elements
Will try to reshuffle elements and try again, attempt 1/10
processing 4 elements
Will try to reshuffle elements and try again, attempt 2/10
processing 4 elements
Will try to reshuffle elements and try again, attempt 3/10
processing 4 elements
processing 2 elements
Couldn't narrow it down any further.
It's some of the 2 elements:
[#4015211=IfcWall('0p2EG2ddXF_RDiEon9Jrik',$,'Wall',$,$,#4500162,#4015228,$,$), #4017076=IfcWall('0KFw8bcCf0ZAIJqgcRgSfh',$,'Wall',$,$,#4100304,#4017096,$,$)]
Let's test excluding them...

Excluding element fixed the drawing:
#4017076=IfcWall('0KFw8bcCf0ZAIJqgcRgSfh',$,'Wall',$,$,#4100304,#4017096,$,$)

@theoryshaw
Copy link
Member Author

Nice, clever bit of programming going on here!

@aothms
Copy link
Member

aothms commented Apr 5, 2024

Is there something I can look into here?

@Andrej730
Copy link
Contributor

Is there something I can look into here?

@aothms This one is resolved in the current build 👍

Andrej730 added a commit that referenced this issue Apr 5, 2024
To speed up the drawing process in large projects and reduce time on syncing stage I've found that if object is already assigned to it's parent collection (both as part of blender collection and in IFC) we can skip assigning stage significantly reducing time on syncing in general (from 20-25 secs -> 9 secs).

The only thing we'll be missing in that case that object won't be unlinked from other unrelated blender collections which shouldn't break anything in the case of drawing generation.
Andrej730 added a commit that referenced this issue Apr 8, 2024
also fixed the issue with mixed up results at the end of the operator execution
aothms pushed a commit that referenced this issue Apr 18, 2024
Turned out syncing process takes too much time on large projects, so we can speed up the printing process by syncing just once. Also exposed option not to sync to operator's properties to allow debugging failing elements.

A bit related to #4500
aothms pushed a commit that referenced this issue Apr 18, 2024
Operator can help narrow down failing elements when drawing is failing with "RuntimeError: An unknown error occurred".

it's located in debug section - https://i.imgur.com/b03jmkZ.png

The output is noisy but the results are highlighted:
https://i.imgur.com/0ZA0u60.png
https://i.imgur.com/oXzqIXU.png
https://i.imgur.com/Y0nMRMz.png
aothms pushed a commit that referenced this issue Apr 18, 2024
To speed up the drawing process in large projects and reduce time on syncing stage I've found that if object is already assigned to it's parent collection (both as part of blender collection and in IFC) we can skip assigning stage significantly reducing time on syncing in general (from 20-25 secs -> 9 secs).

The only thing we'll be missing in that case that object won't be unlinked from other unrelated blender collections which shouldn't break anything in the case of drawing generation.
aothms pushed a commit that referenced this issue Apr 18, 2024
also fixed the issue with mixed up results at the end of the operator execution
@theoryshaw
Copy link
Member Author

Thankful for this functionality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants