Vernetzung importierter Körper bleibt problematisch

Alle Fragen zu: Vernetzung, Materialien, Lasten, Randbedingungen und Elementparameter /
All questions to: meshing, materials, boundary conditions and element properties

Moderatoren: ccad, mz15, auroraIco, Lehrstuhl

Antworten
FEMVIDI
Import
Beiträge: 10
Registriert: Sa 21. Jan 2012, 21:34

Vernetzung importierter Körper bleibt problematisch

Beitrag von FEMVIDI »

Hallo Aurora Team,

nach guten Erfahrungen mit V1 war ich auf die Veränderungen gespannt - und da sind doch einige!
Bravo!

Mein Problem bezieht sich allerdings auf die Vernetzung.
Ich habe mich schon mit Netgen als Standalone Programm beschäftigt, ebenso mit Gmesh und empfand es nicht
als schlecht oder unmöglich.
Jedoch in Aurora wollen die (selben) Geometrien nicht so recht - ich erhalte dann zwar Meldung in der Tetgen.log
nach zu sehen, aber so richtig bringt mich das nicht weiter.
Ich kann via Aurora nicht auf die gleichen Parameter zurückgreifen wie bei Netgen selbst, oder?

Ich nehme an der Benutzerfreundlichkeit wegen wurde das etwas verschlankt - was ich normalerweise als gut und richtig empfinde.

Nun geht es erst mal weiter ans Testen - einfache Geometrien funktionieren übrigens soweit gut - genau wie ich es aus Aurora V1 kannte/kenne.

Gruß
Femvidi
ccad
Z88-Chef
Beiträge: 129
Registriert: Fr 31. Okt 2008, 18:33

Re: Vernetzung importierter Körper bleibt problematisch

Beitrag von ccad »

Hallo FEMVIDI,

bei Z88Aurora V2 wurde absolut nichts an den OpenSource-Vernetzern Tetgen und Netgen veraendert (die sind eh' nicht von uns), das ist noch genauso wie in der Version 1.

Die Problematik ist von vielen Vernetzern bekannt: Einmal geht der eine besser als der andere, und manchmal klappt es garnicht mit dem Vernetzen - das ist selbst bei sehr teuren, vollprofessionellen CAD- und FEM-Programmen der Fall (keine Namen!). Versuchen Sie einmal den Tetgen oder - was meist etwas bringt - schreiben Sie etwas veraenderte oder vereinfachte STEPs aus oder aendern Sie bei STLs die Parameter beim Ausschreiben.

Sie werden aber feststellen, dass , wenn Sie eine saubere Vernetzung hinbekommen haben, das Picking in V2 um Klassen besser ist als in der V1.

Viele Gruesse

Prof. Rieg
selopez
Preprocessor
Beiträge: 69
Registriert: Sa 24. Mär 2012, 03:10

Re: Vernetzung importierter Körper bleibt problematisch

Beitrag von selopez »

Hello FEMVIDI

If you're checking your stp models at NETGEN, I strongly recommend you to "heal" the model with its IGES/STP DOCTOR (Menu > Geometry), and then re-export it from this soft. As NETGEN and AURORA apply the OpenCascade kernel, that what is good for the first, will be also for the second. The advantage of this path is that you'll have, at NETGEN, several instances to see what's possibly wrong in your model and return to the CAD for rebuild it. I also recommend you to mesh the model in NETGEN after the healing process. This would also show you other possible issues. Finally, if you can get a well meshed model in NETGEN and then export the geometry from this soft, you can be reasonably sure to succeed at AURORA.

The problem with the traffic of STP models is that the main CAD vendors, have been "messing" its outputs (in STP and IGS) in order to isolate their users. What’s indeed an abominable commercial politic. It's highly possible that the stp that you export from NETGEN, that will be good for AURORA, is then not for your initial CAD.

Best Regards
Benutzeravatar
Sebastian
Preprocessor
Beiträge: 51
Registriert: Di 7. Feb 2012, 10:48
Wohnort: Cape Town, South Africa
Kontaktdaten:

Re: Vernetzung importierter Körper bleibt problematisch

Beitrag von Sebastian »

selopez hat geschrieben:... the main CAD vendors, have been "messing" its outputs (in STP and IGS) in order to isolate their users. What’s indeed an abominable commercial politic...
On that note:
Back in the late-1970's, the French government wanted to facsimile-transmit letters rather than pack paper around the country. The encoding system they developed for this purpose was something known by the (and I may screw it up here) acronym NAVLPS. The U.S. Department of Defense saw this effort and wanted to one-up it by making the geometry being sent something that could accurately be reconstructed by a computer at the other end. This program was known as the Initial Graphic Exchange Specification (IGES). Sometime later (1984, I believe), Autodesk was in the process of setting themselves up as the CAD system accepted by building departments across the State of California. It was pointed out to them that they could not establish a proprietary data format as a public standard for data. They created a quasi-public version of their DWG database under the title Drawing eXchange Format (DXF). This was, if you will, status zero of the attempt to create a system neutral CAD data exchange system.

NAVLPS evolved (doing data exchanges with other systems) into ISO-10303 aka STEP. IGES went through several iterations with a defined end-goal of becoming the Product Description Exchange Specification (PDES). DXF has always been limited by the design of the AutoCAD DWG dataset, though it has moved to a more inclusive interchange tool from time to time.

In point of fact, the reason PDES was never released was the collusion between American government agencies and the (then) major CAD/CAE/CAM companies in the wake of the destruction of the (once) National Bureau of Standards (NBS) and its replacement by the National Institute of Standards Technology (NIST). The thing to understand is that NBS's Charter was to promulgate and enforce standards while NIST's Charter is to protect intellectual property rights (which is actually the job of the Patent, Copyright, and Trademark Office). Few people today understand that ther is no government agency enforcing standards in the U.S. today.

NIST, listening to the (at that time) mostly government-backed CAD companies, cancelled a decade's worth of work on PDES and renamed the exercise to Product Description Exchange using STEP. That left STEP as the only viable standard for engineering data interchange. The same groups and forces that worked so hard to eliminate the NBS and use (so-called) standards as a stick with which to control (rather than develop) industry focused their sights on ISO. I have watched as things such as threaded hole designations, surface finish requirements, and other annotations have been removed from ISO-10303 under the claim of intellectual property rights and utility has been lost. The attempt to restore such information interchanges is currently being run under the aegis of ASME/ANSI Y14.41-2012 Digital Product Definition Data Practices. The same groups that worked to prevent PDES and STEP from providing a true neutral engineering data interchange have set their sights on preventing Digital Product Definition Data Practices from becoming effective.

Quote: Lew Merrick link
selopez
Preprocessor
Beiträge: 69
Registriert: Sa 24. Mär 2012, 03:10

Re: Vernetzung importierter Körper bleibt problematisch

Beitrag von selopez »

Dear Sebastian,

Thank you very, very much for your so interesting article. It clarifies the origin of those issues that all we, that work with CAD systems, need to deal with when communicate with clients or providers.

Regards
Antworten