NEVJOHNSON
 |
| 18 Oct 2005 09:18 AM |
|
Hi guys,
I am looking for best practices relating to rapid instantiation and minimal memory usage for UDFS.
Specifically I would like to know which methods of UDF construction are computed the quickest (also which types to avoid)
For example,
If I need to project a point onto a surface I could do it in one of two ways.
1. Use the project functionality directly
2. Build a line (via point-Direction) and intersect this line with the surface.
I am guessing that the internal mathematics can vary and thus may have some impact. If I can reduce my instantiation times and ALSO my update of these instantiated UDFs by even 1 second I will be saving a great deal of time.
Or am I better of constructing my geometry within KWE rules?
I assume that there are many people out there that similarly to me need to instantiante 1000's of UDFs. In addition I would like to optimize for memory usage as I it is clear that as the available memory drops the instatiatiate times start to increase substantially. If you need to instantiate 1000`s od UDFs you can very quickly run into problems with memory issues (NB I am using CAChed files with a 3d Accuracy setting quite high)
Thanks in advance for any tips
Nev |
|
|
|
|
IPHILLIPS
|
| 18 Oct 2005 02:21 PM |
|
I use KWA Rules and formulae, but while they take up less space at the end, they may need as much memory during execution or update. Do you have a way to measure or compare memory usage?
They take up less space, as all is saved is the final result and a bit of text. So while a simple project would have a datum point and the formula: " project(`G-Set.6\Point.1`,`G-Set.1\Surface.1` ) " It woulkd not save much space on its own. But usually you require a long chain of GSD features. Most of which could be replace with the Rule/Formula knowledge language.
There are also ways of packing the memory from time to time. |
|
Ian Phillips. FORCEFIVE AG, Munich, Germany |
|
|
codewriter
|
| 18 Oct 2005 02:47 PM |
|
can you share your ideas(code) on packing the memory?
i'm thinking that we'd all find that useful |
|
|
|
|
NEVJOHNSON
|
| 18 Oct 2005 03:10 PM |
|
All I have is some basic VB code that allows you to test the speed at which a number of UDFs can be instantiated.
It also measures the physical and virtual memory. However it would mean a trial and error approach to testing UDFs that produce the same output but with different construction methods.
I was hoping to above this.
I am already using the memory packing methodology ( I assume you mean visualization mode).
Even with this the complexity of the geomtry I have means that you can quickly run into problems.
|
|
|
|
|
IPHILLIPS
|
| 23 Oct 2005 08:31 AM |
|
| The guys doing loads of meshing and were having memory problems. They could not continue until the memory was flushed. It sounded like they were using a command to do it. But what exactly it was, if it was on windows AIX or in CATIA or part of the FEM meshing workbench, I'm not sure. I did not think I would need it. |
|
Ian Phillips. FORCEFIVE AG, Munich, Germany |
|
|
NEVJOHNSON
|
| 24 Oct 2005 12:28 PM |
|
These guys doing lots of meshing. Who are they?
I would like to see if they were using a method other than visualization mode.
If so then what?
Thanxs
Nev
|
|
|
|
|
IPHILLIPS
|
| 25 Oct 2005 08:16 AM |
|
| Er.. I think they just used the FEM workbenches in V5. I dont know about modes. |
|
Ian Phillips. FORCEFIVE AG, Munich, Germany |
|
|
IPHILLIPS
|
| 02 Nov 2005 03:56 AM |
|
Nev
Did you get any results from your VB code for testing UDFs? I would like to find out if there are benefits using KWA methods instead of GSD features. In a rule, for example, you can create temporary features. If these are faster at update, I would use them to reduce update times of UDFs and powercopies. |
|
Ian Phillips. FORCEFIVE AG, Munich, Germany |
|
|
JSTRAWN
|
| 02 Nov 2005 06:54 AM |
|
One thing that we have found to optimize the use of UDFs and PCs doesn't involve programming or anything.
Just make sure you are using the same base features for each instanciation.
For example: we had a wing spar that contained ~50 flanged lightening holes. The first time we did this, we simply instanciated each PowerCopy/UDF by selecting the resultant face of the solid after the last instanciation. By the time we got to the last lightening hole the part was a dog. It took about 20 minutes to update the solid. And deleting any of the earlier Lightening Holes caused the rest of them to disappear as well. A real pain.
We decided to rebuild the part. First we extracted the Face of the Solid. Then, when we instanciated the ligtening holes, we selected that extracted face for each instanciation. The final part updates in less than 3 minutes. And we can delete and add as many lightening holes as we want without effecting the others.
|
|
Jim Strawn
Cessna Aircraft Co. |
|
|
NEVJOHNSON
|
| 02 Nov 2005 08:33 AM |
|
Jim/Ian,
We too have found that it is best to use inputs that do not change. All my UDFs are independent from one another. This substantially improves the regeneration time for modifications.
For example our UDF inputs are generally data extracted from solids (with link killed) or planes etc..
Also the beauty is that we can do a replace on the extracted surface very easily.
But not so easily for solid geometry.
Ian, I have not finished looking into optimising my UDFs. Either because it does not seem practical to build all the features with KWA or the dictionary is not extensive enough to permit me to do what I need.
I did play around with the idea of generating parameters of the type surface, plane curve etc... and then I turned these datum features into features via formulas.
These instantiated fine as powercopies but as UDF's I kept on getting errors.
I could not figure out what the problem was.
Generally if you can instantiate a PowerCopy successfully then the same applies for a UDF.
However I have found instances whereby this is not the case.
I have attached a jpeg and sample part for your thoughts.
REMOVE the .txt extension to access the RAR file
Let me know what you think.
Regs
Nev |
|
|
|
|
NEVJOHNSON
|
| 09 Nov 2005 09:02 AM |
|
Ian,
I have completed my first set of tests.
I build 2 UDFs which produce the same output.
The first UDF was build using geometry outside of Knowlegeware.
This part contained 72 features in all.
For instantiating 50 UDFs total time was 110s
Phys Mem Usage: 17.5MB
Virtual Mem Usage : 16MB
The second was build using as much Knowlegeware as possible
This part contained 56 features.
For instantiating 50 UDFs total time was 170s
Phys Mem Usage: 22.2MB
Virtual Mem Usage : 21MB
At the moment my conclusion is that less geometry built inside rules is better.
I cannot however verify whether this is the case for geometry built within formulaes.
Any feedback or comments on my findings appreciated.
Nev
|
|
|
|
|
IPHILLIPS
|
| 10 Nov 2005 03:18 AM |
|
If the powercopy works but not the UDF, it probably means you are using R14.
You have to put the formulae in the UDF definition manually. What a pain!
EG Copy the Formulae into a Geom Set. (deactivate the ones in Relations) Use the Geom Set for the UDF definition. Then the UDF should work.
Did you put all of the feature definition in a single rule? It might be faster.
Yes Blends, sweeps, translate, Rotate, Fillet and B-Reps such as boundaries are all not available in KWA. Nutty! |
|
Ian Phillips. FORCEFIVE AG, Munich, Germany |
|
|
COE-FORUM-USER
|
| 05 Jan 2006 08:37 AM |
|
Hello all,
actually, the two objectives are often contradictory (it is difficult to optimize speed and memory)
there was some bugs in temporary objects management in KWA built geometry. The result was that they was not cleaned after evaluation but before evaluation, which means that they consumed memory. This bug has been fixed (R14SP?, R15SP?, R16). After this fix, the memory consumtion is far better for udfs & PC using KWA geometry constructors (RAM and disk).
For speed, it is better to use true wireframe operators because KWA ones create standard ones, update them, copy them and delete them, so there are more operations for the same result.
Regards
|
|
|
|
|
NEVJOHNSON
|
| 09 Jan 2006 09:04 AM |
|
Always nice to get a post from the developers.
I think in general more contributions would really benefit the CATIA community.
These contributions would save us all a lot of time and money.
Thanks for your contribution.
Hopefully it is the first of many.
|
|
|
|
|
IPHILLIPS
|
| 16 Jan 2006 08:44 AM |
|
Quote
Originally posted by: ds_developer
For speed, it is better to use true wireframe operators because KWA ones create standard ones, update them, copy them and delete them, so there are more operations for the same result.
Do you mean that it is better for performance reasons to use interactive GSD features (eg Point.3) instead of defining features inside a rule(let p(point))?
|
|
Ian Phillips. FORCEFIVE AG, Munich, Germany |
|
|
NEVJOHNSON
|
| 16 Jan 2006 09:34 AM |
|
Ian,
Thats how I read it.
It also confirms the tests that I performed too. |
|
|
|
|