mysterious file size growth - caused by2 many changes?

[brad3378]

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?

 

[RCDLtd]

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.

 

[LeonEng]

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.

 

[brad3378]

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!