×
INTELLIGENT WORK FORUMS
FOR ENGINEERING PROFESSIONALS

Log In

Come Join Us!

Are you an
Engineering professional?
Join Eng-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Eng-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

mysterious file size growth - caused by2 many changes?

mysterious file size growth - caused by2 many changes?

mysterious file size growth - caused by2 many changes?

(OP)
I'm working on a part in the Unix C3P 10.1 classic (I-DEAS 10 NX) environment and my file size is becoming enormous.  I have been making a lot of modifications to the part, but the complexity has not changed much.  I know that there is a file size issue because if I export an older version of my part to IGES, it is only have the size as a current IGES export.

I have a theory that parts require a lot more space as they change because if you continuously delete curves (for example) and keep replacing them, the Curve ID # will keep growing.  As an example, the last curve I created has a Curve ID label of "C53241".  Surfaces, Features, Coordinate Systems, etc. all have similarly large ID numbers even though the total sum of these should be well below 1000.

Is there a way to force I-DEAS to recycle the names of unused Curves, Surfaces, Features, Etc in an attempt to bring my file size back to normal?

Does anybody have any suggestions besides starting over from scratch?   Am I even on the right track to finding the problem?

RE: mysterious file size growth - caused by2 many changes?

Last question first, I don't believe I-DEAS can be forced to recycle entity IDs. However, this is not an explanation for increasing file size.

Additionally the size of the IGES file is not a good judge of the size of the Native I-DEAS file. By Default the IGES translation will just translate the surfaces displayed in your model at the point in the history you write the file.

What would effect an IGES file size would be the degree of surfaces and curves contained in the model as well as, for NURBS data like I-DEAS, segments and knots. I-DEAS tends to "protect" the user from this sort of detail, but the more booleans and intersections the surfaces go through tends to push these values up and therefore the amount of math required in the IGES file to describe them.

If you are looking at the Native I-DEAS file size and you see this increasing it could simply be down to using the Lock and Retain Results options within the part history. Every time these options are used the software stores a surface definition of the part at this point.

There could also be other factors such as modelling best practices. i.e. When you are deleting curves and surfaces, I take it that where ever possible you delete the feature out of the part history and not through the Delete Entity option.

RE: mysterious file size growth - caused by2 many changes?

brad3378,

May be the file size increased due to the grow of the information retained in the part's 'history tree' after each modification. If you do not need those info, you can use 'extract surfaces' function to duplicate your part to an orphan part, and delete the original part to reduce file size.

RE: mysterious file size growth - caused by2 many changes?

(OP)
Thanks for the replies.
You were both on the right track.  I just didn't do all my homework before I started to panic and post a message to this forum.

RCDLtd was right that I should not have correlated the size of the IGES file to the slowness of the I-DEAS model.  Apparently you were also right about the "lock & retain results" checkbox in the History Tree.  After I unchecked a few, my part update times actually increased, but however, I was more able to make modifications to the part faster.

I'm new to my current employer, and I inherited this problem part with some interesting design features.  In hindsight, I should have spent more time scrutinizing EVERY single node in the history tree because I saw some very foolish operations.

Now that my part is being manufactured, I have a lot more time to fix problems in the history tree before the next change order is released.  I have slowly been able to improve the robustness of my part's history by replacing long branches of the history tree with orphan surfaces (where feasible) and more intelligent constraints in the areas that will be more likely to have future changes.

As far as I can tell, the biggest improvement came when I replaced a long branch with an orphan.  The crazy thing was how foolish the branch was created in the first place.  The original designer started a branch with an orphan surface, and then just kept modifying it in foolish ways.  I must have counted at least 5 entity delete features and a few stitch & surface-by-boundary features created when he could have just represented the same surfaces by a more simple single orphan feature.

Anyway, I'm just glad that my file is working again.
Thanks again for your advice!

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Eng-Tips Forums free from inappropriate posts.
The Eng-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Eng-Tips forums is a member-only feature.

Click Here to join Eng-Tips and talk with other members!


Resources