randlomly generated features

[Jim McKim]

Have you ever seen a whole bunch of features get randomly generated on a part as a result of a machining operation? A whole bunch, as in "hundreds". The first sign that it has happened is that the software becomes extremely slow, just as if you were working on a very slow computer. Upon expanding the structure browser, you see a long list of features that were not there before and that you did not intentionaly create. Deleted the features solves the speed problem. Any idea what causes this to happen? I haven't submitted it to Support yet because we haven't been able to capture the sequence of events.

[Wolfgang]

Hi Jim,
may be you should tell us, what kind of feature do you find in the structure browser then?

which icons are displayed?
which feature names are used?
what happens in the model when you delete the features (by selecting in the browser)?
what 'things' does the custom feature report show?

[Mario]

Hi Jim,

which version of OSDM are you using?

Mario

[Jim McKim]

The features have names like 'feat11121'. Support in Fort Collins says they are "empty features" and pointed me to the goody "cleanup_udef" to use to delete them without deleting non-empty features. They said these features (one model had over 13000, yes, that is thirteen thousand!) multiply by doubling during a Save operation. I have since determined that this happens only on some Saves, not every time. They also thought the source of the problem was files from one of our customers, a major user of OSD who I shouldn't name here, but now I don't think that is the case as I checked all the models we received and none of them have visible empty features in the structure browser. Could they be completely hidden and reveal themselves later?
We are using OSD 11.5 now, also saw this on an earlier version, 9.01d I think.

[Mario]

Hi Jim,

I do not recall the exact circumstances under which the features are multiplied.
If the cleanup_udef feature tool helps in your case, just use it on those parts. The features are in fact empty and can be removed.

In the case of features like 'feat11121', those features are shown in the browser right away and are not hidden to the user. You will probably find features named feat1, and then feat11, etc.

In version 11.60 the functionality of the cleanup_udef tool is included, hence you will not encounter this problem.

Hope this helps,

Mario

[Jim McKim]

Originally posted by Mario
Hi Jim,

I do not recall the exact circumstances under which the features are multiplied.
If the cleanup_udef feature tool helps in your case, just use it on those parts. The features are in fact empty and can be removed.

That sounds easy enough, and it does work, but when you load a model with over 13000 features, it brings your computer to its knees before you can execute cleanup_udef!

In the case of features like 'feat11121', those features are shown in the browser right away and are not hidden to the user. You will probably find features named feat1, and then feat11, etc.

Yes, that is the case.

In version 11.60 the functionality of the cleanup_udef tool is included, hence you will not encounter this problem.

I don't think that is correct. I am running 11.60, and loaded the model with the problem, and it did not automatically cleanup during load. I had to load cleanup_udef from the command line and then execute it. I've sent the model to Support (Brad).

Hope this helps,

Mario

Not as much as preventing the problem in the first place! :D

[pkehoe]

We have seen these empty features as well. From what we can
tell they get propagated by machining operations (like unite),
not by saving-although I'll have to check that out.

In our version of 11.6, I will sometimes get a message when I
load a part that "some optimization has occurred" (or something
like that). If I save the part at that point I can see that the file
size is smaller.

I usually run OSDM on HPUX, so maybe that is a difference. I
know that on a PC I can load the cleanup_udef goody, but I
can't on HPUX. So maybe it is built into the load on HPUX, but
not on the PC version.

We still have never figured out what causes the problem to
begin with although there have been several theories.

The problem that we have had in the past is that we never
saw the problem until the number of features was so large that
it became a performance problem. And by then nobody could
remember what they did.

[Jim McKim]

I received a definitive explanation from Support on what causes the large number of features. Firstly, they are user-defined features. If they have a name like "feat###", that just means the user didn't give it a name other than the default. A user-defined feature can become empty when the elements that were in it at one time are now deleted. OSD retains the feature "placeholder" in case the user wants to put some other elements into it. So far, so good. Now comes the problem: if you do any boolean unites, subtractions, or intersections with any portion of the part (or a copy of it) to another part, these empty features duplicate. Because there are no specific elements to which the feature is tied, it belongs to the part as a whole, meaning no matter how much of the part you cut away, the feature will still be in the part structure. So, for example, if you copy the original part, cut away most of it and move and unite the remainder back to the original part (as you might do to duplicate some detail on the part), the part will now have twice as many empty features. The duplicates get renamed by appending digits to the original names. So, after not to many of these kinds of operations, you can wind up with hundreds or thousands of empty features, at which point performance begins to suffer. (We had one part that had over 13,000 (yes, that's right, folks, thirteen THOUSAND!) of these suckers.) Running the empty-too Cleanup tool in the cleanup_udef goody takes care of the exorcism.

I'm surprised you're having trouble loading the goody on HP-UX - I didn't think there was any difference to the load command. If it is built in, it should show in the toolbox (maybe?). The load command I used is (load "cleanup-udef").

I have an html help file on the goody that Support sent me - doesn't look like I can attach it in vBulletin. Contact me, or Support, if you need this file.

[Jim McKim]

Looks like on unix the command would be (load "goodies/cleanup_udef")

[pkehoe]

I get an error "Cannot open the file goodies/cleanup_udef". I am
running version 11.60 (27Sep2002). Maybe it is included in one
of the later patch versions?

[Jim McKim]

I'm also running 11.6 and we have most users running 11.5, so that shouldn't be the problem. Besides, I got the distinct impression from Support that this has been around for some time. I suggest you contact Support.

[Mario]

Hi Pete,

on HPUX the goody is located under compatibility. When you type
(load "compatibility/cleanup_udef")
it will load the tool.

Documentation can be found on HPUX and NT within the goodies documentation in "readme_071.html".

Hope this helps,

Mario

[John Scheffel]

While we are on the topic of goodies, can anyone from CoCreate explain why the command to load the goodies is not the same for both Windows and HP-UX. This thread is just one example of the confusion this causes, I have run into many others :mad:. It has been this way ever since the first Windows version of SolidDesigner was released. How hard could it be to fix this? It seems like it would just be a matter of adding the "goodies" directory to the search path. Now we see that someone decided to place a goodie in a different path. I would think CoCreate would want to fix this just to simplify the documentation. This is one of those stupid little things that make your users crazy :eek:.

[Markus]

Hi John,

just a few weeks ago we added "goodies" to the search-directories for 12.0 on HP-UX. Therefore the problem with different load-pathes for goodies on Windows and HP-UX will be gone.
The current solution will not cover those compatibility goodies though. I guess we need to rethink this issue as well.

Markus

[John Scheffel]

Originally posted by Markus
Just a few weeks ago we added "goodies" to the search-directories for 12.0 on HP-UX. Therefore the problem with different load-pathes for goodies on Windows and HP-UX will be gone.
The current solution will not cover those compatibility goodies though. I guess we need to rethink this issue as well.
Hi Markus,

Thanks for replying to my rant. Glad to hear this will be fixed in version 12. As a user, I would prefer to see all goodies loaded by a command such as:

(load "goodie_file_name")

regardless of OS or file location.