A problem with OpenNest

[Lena_Ahmed]

Hello everyone,
I have a problem with OpenNest, so I thought getting some ideas might help…

The problem is that whenever I connect the geometry into the opennest component the whole file will freeze no matter what time I wait and I will eventually have to force rhino to close then start it again and so on.
The geometry I’m trying to connect consists of 1012 polyline curves, I already have them flattened and everything.

Does anyone have any idea about what the problem might be? or what should I try?

Your help would be very appreciated, Thanks!

[kev.r (Kevin)]

Upload a grasshopper file with internalized geometry.

Help Us Help You

Asking questions and getting answers is what this forum is all about. Although people are generally very helpful, there are things you can do to improve your chances of getting good and quick answers. Below you will find some suggestions, but don’t think of them as rules and especially don’t think of them as guarantees. 1. Choose a descriptive title for your post Don’t title your question Help! or I have a problem or Deadline tonight!, but actually describe the problem you are having. 2. Be s…

Nesting a large number of objects or objects that are overly complex can take a long time to complete. Not possible to know exactly what problem you’re facing without a file to look at.

-Kevin

[Lena_Ahmed]

Packing with Open Nest.gh (119.5 KB)
Hey Kevin, thank you for your reply.

Here is the file attached with internalized geometry and everything… when I connected the geometry to OpenNest and left the file running for about an hour, it finally worked! but still this is so much time!! and whenever I need to edit anything in the script I will have to wait for an hour all over again!!

so, is this normal due to the large number of polyline curves (1012)? or there is anything I can do to make it work faster than this?

Looking forward for your help
Thanks in advance!

[kev.r (Kevin)]

Your input curves are simple polygons without any extra control points so they can’t be simplified.

Aligning the longest edge of each polygon with the X-axis speeds up nesting slightly.

@Lena_Ahmed

is this normal due to the large number of polyline curves (1012)?

This seems to be the case.

I divided your input curves into branches of a DataTree and then got these results from nesting them.

1 branch:   479 sheets, 2617.8 seconds
2 branches: 480 sheets,  394.7 seconds
3 branches: 479 sheets,  146.7 seconds
4 branches: 482 sheets,   90.4 seconds
5 branches: 487 sheets,   61.3 seconds
6 branches: 492 sheets,   48.1 seconds
7 branches: 488 sheets,   40.2 seconds

(Results with nothing connected to the “Seed” input.)

Packing with Open Nest_re.gh (123.6 KB)

I’ve saved the file with this Data parameter disabled so it won’t start nesting as soon as the file is opened (right-click on it and select “Enabled” to start nesting).

-Kevin

[Lena_Ahmed]

Wow Kevin! thank you so much for your time! this works really well.

I have some questions if you don’t mind:

1- why did you use the “seed” input eventually? did that do anything?
2- why do you think dividing the input list into branches decreased the computing time? as it is obviously not the best case in terms of material waste… so, is there any logic behind this that you might know?
3- why exactly did we add that part? (the following attached photo)

[kev.r (Kevin)]

@Lena_Ahmed

1- why did you use the “seed” input eventually? did that do anything?

I was just experimenting, changing the “seed” input can produce differing results.

@Lena_Ahmed

2- why do you think dividing the input list into branches decreased the computing time? as it is obviously not the best case in terms of material waste… so, is there any logic behind this that you might know?

You can see from nesting differing numbers of elements that the relationship between the number of elements and the nesting time is not linear.

Nesting 100 elements takes ~3 seconds
Nesting 200 elements takes ~17 seconds
Nesting 400 elements takes ~105 seconds

As far as the added material waste from splitting into groups, perhaps you could combine and re-nest the last few sheets from each group.

@Lena_Ahmed

3- why exactly did we add that part? (the following attached photo)

It matches the indices of the nested items to the indices of the source geometry (otherwise each branch of the DataTree starts numbering at 0).

Do you plan to fabricate and assemble this? Seems like an extremely large job with over 1,000 parts.

-Kevin

[Lena_Ahmed]

@kev.r

You can see from nesting differing numbers of elements that the relationship between the number of elements and the nesting time is not linear.

I see, so there is no specific logic behind this.

@kev.r

perhaps you could combine and re-nest the last few sheets from each group.

can you please give me a hint on how to do this?

@kev.r

Do you plan to fabricate and assemble this? Seems like an extremely large job with over 1,000 parts.

I’m developing a design framework for my thesis, so I needed the whole geometry to be packed efficiently with OpenNest as it is a part of the framework.
However, I’m planning on fabricating a part of the geometry just as a prototype… but still not sure which part I will eventually choose for fabrication.

Again, thank you so much for everything!

[kev.r (Kevin)]

@Lena_Ahmed

@kev.r

perhaps you could combine and re-nest the last few sheets from each group.

can you please give me a hint on how to do this?

This file re-nests the last 3 sheets from each branch.

Packing with Open Nest_re2b.gh (125.0 KB)

Preliminary nesting with geometry divided into 8 branches uses 484 sheets of material. After re-nesting, material use is reduced to 480 sheets.

Again, I have saved the file with this data parameter disabled so nesting will not start as soon as the file is opened Right-click on it and select “Enabled” to start nesting. Solution takes ~33.5 seconds with settings saved in file.

-Kevin

[Lena_Ahmed]

Thank you so much Kevin, you’ve been really helpful to me!