Inventor Engineer-to-Order

Reply
Active Contributor
scottheide
Posts: 32
Registered: ‎01-17-2012
Message 1 of 9 (226 Views)

Size Matters!

226 Views, 8 Replies
08-16-2012 11:43 AM

OK, all you folks who normally ignore these discussion group messages, can you weigh in on this?  

 

What is the largest Inventor ETO model out there in terms of:

   # of parts?

   # of unique parts?

   With or without constraints

 

We are struggling with models over ~2500 parts and maybe 100 unique parts using FBP (no constraints).  Anyone out there got a bigger one? 

ScottHeide@CruzBayCustom.com
Board Manager
Jon.Balgley
Posts: 242
Registered: ‎08-23-2006
Message 2 of 9 (216 Views)

Re: Size Matters!

08-16-2012 05:16 PM in reply to: scottheide

FWIW, this is about the same size that you reported.  It uses constraint-based positioning.  It ran to completion in a minute or so, changing from a smaller model to this size.

 

Image-0067.png

 

Image-0068.png

 

 

Image-0069.png

 

 



Jon Balgley
Autodesk Configurator 360 / Inventor ETO team
Autodesk, Inc.

Active Contributor
scottheide
Posts: 32
Registered: ‎01-17-2012
Message 3 of 9 (209 Views)

Re: Size Matters!

08-16-2012 07:13 PM in reply to: Jon.Balgley

Interesting.  If you double the number of parts does it run in 2+ minutes?  Although the parts/unique parts numbers look similar to our smaller models, the model itself looks like a simple quantified part.  How deep is the rule set?  How deep is the assembly tree?  

 

I've found that with our model the cliff seems to be above 2500 parts.   Actually, for most of the tests we've done so far, the problem is with models that are much bigger  (say 10K+ parts), but Inventor seems to create the first 2500 parts relatively quickly then bogs down.  We haven't done tests yet with part numbers that are greater than 2500 and say less than 3500. 

ScottHeide@CruzBayCustom.com
Mentor
bsee1
Posts: 211
Registered: ‎11-14-2011
Message 4 of 9 (200 Views)

Re: Size Matters!

08-17-2012 06:07 AM in reply to: scottheide

While we're talking about performance, this looks like a good time for me to throw in my request for someone to fill out this page: http://wikihelp.autodesk.com/Inventor_ETO/enu/2013/Help/0148-Inventor148/0307-Inventor307/0324-Tools...

It's been under construction for 2 versions of ETO now.  

 

My best guess is that you meant to include these functions on that page:  writeAllDesignsMemoryUsage, writeAllMapsMemoryUsage, and writeAllPartsMemoryUsage.

When I export the files created by those functions, it would be useful to know what units those numbers are in.  I was hoping for it to at least be in the wikihelp.

 

The writeAllPartsMemoryUsage function seems to have a problem.  You can see in the image below that it does not label the column headings for some of the numbers it outputs.  I'm unsure of how to use the data if it doesn't have somethign to describe what the numbers are for.

 

 

partsMemoryUsage.png

 

 

More relevant to your question, there's 2 things my team tried.  First, switching to ETO 2013 was a large help.  2013 seems much faster than 2012 when opening large assemblies. 

 

Second, just through a large amount of code optimization we were able to create the same assembly using half the memory(and in half the time).  That's a harder thing to teach, especially without an ETO debugger, but is probably your best bet for increasing performance.

 

Definitely take a look at the ETO function writeAllDesignsMemoryUsage.  It will help you find your innefficiencies. Export it as a .csv file.

 

Hope some of this helps!

-Brandon

*****************************
Win7 x64 - 16gb ram
i7 3610qm
FirePro M4000

Inventor 2013
ETO 6.1
Active Contributor
scottheide
Posts: 32
Registered: ‎01-17-2012
Message 5 of 9 (194 Views)

Re: Size Matters!

08-17-2012 07:09 AM in reply to: bsee1

Thanks Brandon.  We'll try some of your suggestions. 

 

You don't mention the number of parts your models have or whether you are using FBP or constraints?   My gut feel (which could very well be wrong) based on the fact that there seems to be an exponetial slowdown over ~2500 parts is that the issue might be related to the number of parts/assemblies and how ETO is dealing with that many parts/assemblies more than the basic memory useage.   Our parts, by they way, are mostly simple blocks.  

 

I'm not certain, but I think that there are a number of regular Inventor customers who have models well over 2500 parts that load and unload in a reasonable time (at least not hours...).  Which to me would indicate that the memory issue for the basic geometry isn't the problem.  But like I said, we will certainly run some tests with the tools you mention to check it out. 

ScottHeide@CruzBayCustom.com
Mentor
bsee1
Posts: 211
Registered: ‎11-14-2011
Message 6 of 9 (190 Views)

Re: Size Matters!

08-17-2012 07:29 AM in reply to: scottheide

I didn't mention it because you're on a totally different scale than we are.  I'm running ETO on a computer intended for 2D design (Hoping to upgrade soon).  Everything we have uses constraints. Our parts are more than simple blocks. I can't really give more detail because I don't know. I'm a programmer, not an engineer.

 

In 2013 it takes 56 seconds to open 103 total occurrences in the active document with 34 open documents in the session.

Also using 2013, it takes 3 minutes even to open 664 total occurrences in the active document with 76 open documents in the session.

 

It's too bad the process of opening our assembly only uses a single core.  At least in my case, the cpu seems to be the limiting factor.

 

cpuUsage.png

 

 

I can't test with 2012 because things get complicated when moving a project to prior versions, but I can say it was slower.

 

One more thing to add is that if you plan to develop your own user interface, Inventor OEM seems to run faster than the main version of ETO.  However, I'm in the process of putting together a UI now, and I can say it definitely is not a small task.

*****************************
Win7 x64 - 16gb ram
i7 3610qm
FirePro M4000

Inventor 2013
ETO 6.1
Board Manager
Jon.Balgley
Posts: 242
Registered: ‎08-23-2006
Message 7 of 9 (164 Views)

Re: Size Matters!

08-20-2012 02:48 PM in reply to: scottheide

FWIW:  Here are some quick results, just timed on my watch, by eye:

 

 

Total   Unique            minutes:seconds
557     121               0:30
1479    [less than 217]   0:46
3041    167               1:18
12729   387               4:35

 

For each iteration, I changed some of the key "configuration" parameters, as well as the ones that directly affect the quantity.

 

For the last two, both # of occurrences and elapsed time increase by about 4x.  For the first two, there's probably some "noise" in the numbers.  

 

These were all obtained sequentially in the same session, with lots of other apps running in the background (but not actively).  This is on a MacBook Pro, running Windows 7 on Parallels.  ETO 2013.  The model has some patterned occurrences, but overall it is not a simple child list.  The trusses vary in length, depending on where they fall against a "bounding curve".  However, the model uses shared assemblies extensively (exclusively).  So many of the subassemblies eventually prove to be identical to other subassemblies.  And because I round the lengh of the trusses to the nearest 3", it makes it easier for them to be reused.

 

Anyway, take this FWIW.  I know mine is a simplistic model.  If you can give us a model that shows the "bogs down after 2500 parts" behavior, we'd be happy to look into it.

 

 



Jon Balgley
Autodesk Configurator 360 / Inventor ETO team
Autodesk, Inc.

Contributor
james.snyder
Posts: 15
Registered: ‎11-17-2011
Message 8 of 9 (150 Views)

Re: Size Matters!

08-21-2012 08:15 AM in reply to: bsee1

bsee1 wrote:

Second, just through a large amount of code optimization we were able to create the same assembly using half the memory(and in half the time).  That's a harder thing to teach, especially without an ETO debugger, but is probably your best bet for increasing performance.


Some of the code that we did was to consolidate as much of the code as possible.

 

An example is the use of child lists in place of multiple child rules. In our case, we can place multiple instances of a piece of conveyor (for talking purposes lets say up to 50) into an assembly which are then constrained together. The user is prompted for a flavor of conveyor and then the quantity required. Initially I had a child rule for each possible instance of transport and then two child rules for constraints for each piece of conveyor to attach it to the previous piece of conveyor. The math works out that 148 (50 conveyor instances + 98 constraints) child rules where being evaluated every single time the user place a new section of conveyor regardless of the actual quantity that the user entered. To eliminate the extra child rules, I used a child list to place both the conveyor and constraints and reduced the written code down to only three child rules. See below for simplified before and after code snippets.

'Before optimization
Child Conveyor_1 As :Conveyor
		grounded? = True
		origin = Point(0.0, 0.0, 0.0)
		xDirection = Vector(0.0, 0.0, -1.0)
		yDirection = Vector(-1.0, 0.0, 0.0)
	End Child

Child Conveyor_2 As (If ConveyorQty? > 1 Then :Conveyor Else :nullDesign)
		grounded? = False
	End Child

Child Conveyor_3 As (If ConveyorQty? > 2 Then :Conveyor Else :nullDesign)
		grounded? = False
	End Child

         'etc... all the way up to Conveyor_50

Child ConveyorInternala_1 As (If ConveyorQty? > 1 Then :IvInsertConstraint Else :nullDesign)
		part1 = Conveyor_1
		entity1 = "Conveyor3a"
		part2 = Conveyor_2
		entity2 = "Conveyor1a"
		axesOpposed? = True
		distance = 1.0
	End Child

Child ConveyorInternalb_1 As (If ConveyorQty? > 1 Then :IvInsertConstraint Else :nullDesign)
		part1 = Conveyor_1
		entity1 = "Conveyor3b"
		part2 = Conveyor_2
		entity2 = "Conveyor1b"
		axesOpposed? = True
		distance = 1.0
	End Child

         'etc... all the way up to ConveyorInternala_99 and ConveyorInternalb_99 

'After optimization	
Child Conveyor As :Conveyor, Quantity = ConveyorQty?
		grounded? = (If Child.index = 1 Then True Else False)
		origin = Point(0.0, 0.0, 0.0)
		xDirection = Vector(0.0, 0.0, -1.0)
		yDirection = Vector(-1.0, 0.0, 0.0)
	End Child

Child ConveyorInternala As :IvInsertConstraint, Quantity = ConveyorQty? - 1
		part1 = evaluateString("Conveyor_" + stringValue(child.index))
		entity1 = "Conveyor3a"
		part2 = evaluateString("Conveyor_" + stringValue(child.index+1))
		entity2 = "Conveyor1a"
		axesOpposed? = True
		distance = 1.0
	End Child
	
Child ConveyorInternalb As :IvInsertConstraint, Quantity = ConveyorQty? - 1
		part1 = evaluateString("Conveyor_" + stringValue(child.index))
		entity1 = "Conveyor3b"
		part2 = evaluateString("Conveyor_" + stringValue(child.index+1))
		entity2 = "Conveyor1b"
		axesOpposed? = True
		distance = 1.0
	End Child
Win7 x64 - 32gb ram
Dual Xeon X5670
eVGA GTX 670

FDSU 2013 SP2
ETO 6.0
Active Contributor
scottheide
Posts: 32
Registered: ‎01-17-2012
Message 9 of 9 (119 Views)

Re: Size Matters!

08-26-2012 08:47 AM in reply to: james.snyder

James and Jon, thanks much for the submissions.  I think this information will be useful for a lot of other developers out there. 

 

James, I don't think your specific suggestion applies to my particular application since it is more of a black-box application and is not interactive at all.   I'm sure that suggestion will be useful for others and for us on future applications.   But the general suggestion to work toward better code in general is dead on (see below).

 

Jon, your experiments help a lot by pointing out that the underlying performance of Inventor is probably not our problem.    

 

Our project started in the early spring and continues on Release 5.1 from last November.   Right now I suspect a major part of our problem is that we got caught up in copy-list bug on that release.   We are investigating that now by converting some very large lists to maps (hash tables).  I'll report back when we are done, but anyone out there working on the previous release and having performance issues with large models should be reminded to read this:

 

http://adndevblog.typepad.com/manufacturing/2012/08/list-referencing-performance-problem.html

 

 

 

 

ScottHeide@CruzBayCustom.com

You are not logged in.

Log into access your profile, ask and answer questions, share ideas and more. Haven't signed up yet? Register

Announcements
Manufacturing Community
The Manufacturing Community provides additional access to tips, tutorials, blogs and networking with peers.

Need installation help?

Start with some of our most frequented solutions to get help installing your software.

Ask the Community


Inventor Exchange Apps

Created by the community for the community, Autodesk Exchange Apps for Autodesk Inventor helps you achieve greater speed, accuracy, and automation from concept to manufacturing.

Connect with Inventor

Twitter

Facebook

Blogs

Pinterest

Youtube