---

ballforce_to_hole.txt

Hallo miteinander.
Ich bekomme eine für mich unverstaendliche Warnung:
"Boundary conditions are specified on inactive dof of 858 nodes. The nodes have been identified in node set WarnNodeBCInactiveDof."
was sollen inactive dof sein?
Außerdem bekomme ich später den Klassiker gemeldet:
"Solver problem. Zero pivot when processing D.O.F. 2 of 1 nodes. The nodes have been identified in node set WarnNodeSolvProbZeroPiv_2_3_3_1_3."
An was könnte das noch liegen, außer ... http://ww3.cad.de/foren/ubb/Forum254/HTML/000405.shtml#000001
bzw. was ist der "adjust-parameter"?
Dieser Knoten ist der Ref.Punkt meines rigidbody, der einen Kontakt mit einem verformbaren Körper bilden soll, um diesen dann auch schließlich zu verformen.
Bitte um Hilfe!
Herzlichen Dank im Vorraus.
Gruß hansi.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Morgen,

also ich kann nur was zur ersten Meldung sagen. "inactive dof" steht fuer alle nicht aktiven Freiheitsgrade. Diese haengen vom verwendeten Elementtyp ab. Eine Schale hat neben den Verschiebungen noch eine Rotation zur Verfuegung, welche ueber Randbedingungen beaufschlagt werden kann. Ein SOLID- Element hat nur drei Verschiebungen. Wenn du also ein Modell aus SOLIDs hast und in den boundary conditions vorgibst, dass die Rotation um die x- Achse (beispielsweise) verhindert werden soll, dann gibt das natuerlich einen Fehler, weil man fuer diesen Elementtyp nur Verschiebungen vorgeben kann. Genauso bei den zugehoerigen Kraftbedingungen. Ein Solid laesst an seinen Knoten nur Kraefte zu und keine Momente.

Eine Vermutung hinsichtlich des zweiten Fehlers (des Klassikers): Vielleicht waren zuviele RBs nicht zuordenbar, weil sie auf nicht aktiven Freiheitsgraden bezogen sind. Eventuell (aber wirklich nur eventuell) wird dadurch dein System nicht ausreichend beschraenkt und der Solver bringt solche Meldungen?!

Viel Erfolg bei der Fehlersuche.

der Nuxxon

------------------
==========
==  Dingsen  ==
==========

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Deine inp kommt nicht mal durch den Datacheck. Wie hast du die inp gebaut? Es sind Leerzeilen 'drin und deine Part- und Assemblystruktur ist durcheinander. Diese Meldungen findest du übrigens in der dat-Datei.

Zero Pivot deutet auf einen Overconstraint hin. D.h. du hast in DOF 2 an  dem gemeldeten Knoten zuviele Bedingungen definiert. Z.B zwei Randbedingungen oder Randbedingung+Tie oder Randbedingung+Coupling usw.
Wenn es nur eine Warnung ist hat der Solver eine Bedingung deaktiviert und kann die andere somit erfüllen. Du solltest das aber trotzdem überprüfen und ggf. anders definieren.

Der Adjust-Parameter kann bei Kontaktpaaren aktiviert werden und bewirkt eine Manipulation der Slave-Knotenposition beim Datacheck um den Kontakt von Anfang an sauber zu schließen.

siehe Users Manual 29.2.5 Adjusting initial surface positions and specifying initial clearances in Abaqus/Standard contact pairs

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

ballforce_to_pocket.txt

Danke, danke Nicksen und Mustaine!
Meine "inactive dofs" habe ich beseitigen koennen!
Das "Zero pivot" Problem habe ich aber leider immer noch und Abaqus kann deshalb auch nicht durchrechnen. Obwohl ich das System eigentlich ausreichend beschränkt habe, meine ich. Weiter Constraints habe ich an meinem Ref.Punkt auch nicht. Also overconstraint ist das ganze auch nicht.
Um auf meine Part- und Assemblystruktur zurückzukommen... inwiefern ist die durcheinander? Hab noch wenig Ahnung vom Programm.
Damit man sich mein Problem besser vorstellen kann, werde ich spaeter noch nen screenshot hochladen.
Nochmal danke fuer euren Einsatz!
Gruß Hansi.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

balle_vs._Tasche.jpg

So, hier nun das Bildchen.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Man kann anhand des Bildes nicht erkennen wo genau das Problem ist. Du musst entweder die cae-Datei oder eine lauffähige inp anhängen.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

hans_.inp.rar hans_.cae.rar

Hallo nochmal und danke, dass du dir mit mir Mühe gibst, Mustaine!
Hier die Dateien. Hoffe du kannst mir weiterhelfen.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Klassisches Problem. Du stellst in Step 3 um auf die Punktlast. Zu dieser Last kann aber keine Gegenlast berechnet werden, da es den Kontakt noch gar nicht gibt. Also ist das ein ungelagerter DOF und du erhältst die Zero Pivot-Meldungen für DOF 2.

Die Lösung ist recht einfach. Du musst spätestens am Ende von Step 2 einen Kontakt zwischen den Körpern haben (CPRESS > 0). Der einfachste Weg ist also, dass du den Verschiebungswert in Step 2 etwas erhöhst.

Du solltest außerdem die rotatorischen DOF am Referenzpunkt festhalten.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

ball1.pdf

Hallo Mustaine!
Danke für deine Antwort. Habs grade probiert und leider hats dennoch nicht geklappt.
Die Meldung "zero pivot" (am RP) erscheint immer noch und Kontakt sollte eigentlich da sein. Rein rechnerisch zumindest.
Diese Meldung taucht im step3 auf, wenn aufm RP die Punktlast angreifen soll.
Kann es sein, dass meine Skalierung nicht so ist, wie ich sie annehme/haben will?
Wie prüfe ich das nach? Wenn ich das assembly zusammenstelle ist alles so, wie ich es auch will und annehme.
Hänge noch ein Bild bei, dass auch eine Druchdringung zeigt, die ich seltsam finde.
Danke für die stetige Hilfe.   
Allein geht das mal gar nicht!

[Diese Nachricht wurde von hanspeterlinseisen am 29. Jan. 2008 editiert.]

[Diese Nachricht wurde von hanspeterlinseisen am 29. Jan. 2008 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,
die Durchdringung ist erstmal unproblematisch, da Du Spannungen am Kontakt erhälst und somit Kontakt herrscht. Es liegt wahrscheinlich an Deiner Skalierung. Stell mal im Menü unter Options -> Common -> Deform Scale Factor -> Uniform = 1 ein und das Problem dürfte behoben sein.

Ansonsten solltest Du - wie oben bereits angesprochen - die rotatorischen Freiheitsgrade Deines RP festhalten. Falls es dann immer noch nicht klappt, schick noch mal die neue .cae oder die .inp hoch.

Weiterhin viel Erfolg!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Job-3.zip

Anbei die inp mit dem lauffähigen Modell. Die Änderungen sind genau die die ich in meinem Post erwähnt habe. Es gibt nur Warning im Datacheck, welches aber unerheblich ist.

Wenn du ohne NLGEOM rechnest, skaliert CAE/Viewer die Verschiebung im Postprocessing. Dadurch sieht man ggf. Durchdringungen die nicht da sind. Wie du das auf 1 skalierst steht ein Post weiter oben.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Herzlichen Dank an alle!
Ich werde das heut Abend noch ausprobieren und dann nochma mein "Senf" dazugeben.
Danke, danke, danke!

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Juhuu! Es läuft. Bei mir nun sogar ohne eine einzige Warnung.
Danke! units sind schon unterwegs.

Abschließende Fragen:
1) Gibt es einen Grund dafür, dass du alle BCs einzeln definierst? Also pro dof.
2) Warum nehmen die Spannung im letzten step wieder ab? Ist das das "Rausfedern" auf Grund des Kontaktbildens? Also sind die Spannungen, die ich im letzten increment angezeigt bekomme die dann vorherrschenden!?
3) Warum hast du pro step nen eigenen output request definiert?
4) Bei mir lief es anscheinend noch nicht, weil ich den Kontakt zu "schwach" definiert habe. Rein rechnerisch müsste einer nämlich schon ab einer Verschiebung von 0.15 ...1 gebildet werden. Aber erst wenn ich 0.152 eingebe, funktioniert die Berechnung problemlos!? Also gibt es eine Art Kontaktschwelle vom Programm? Oder ist was an meiner Skalierung meiner parts nicht in Ordnung? Habe beide als .sat-file aus SolidWorks importiert.

Ist es immer besser solche Sachen (BCs, output requests, etc.) möglichst aufzusplitten? Nach step, dof, etc.?

Nochmal herzlichen Dank an alle, die sich bemüht haben mir zu helfen.
Find ich spitze!
Angenehmen Tag noch! 
hans.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von hanspeterlinseisen:
Juhuu! Es läuft. Bei mir nun sogar ohne eine einzige Warnung.
Danke! units sind schon unterwegs.

Abschließende Fragen:
1) Gibt es einen Grund dafür, dass du alle BCs einzeln definierst? Also pro dof.

---

Nein. Das schreibt CAE nur so.

Zitat:

---

2) Warum nehmen die Spannung im letzten step wieder ab? Ist das das "Rausfedern" auf Grund des Kontaktbildens? Also sind die Spannungen, die ich im letzten increment angezeigt bekomme die dann vorherrschenden!?

---

Weil die etwas erhöhte Verschiebung die Kugel tiefer eindrückte als die kleine Kraft. Deswegen federt die Kugel wieder raus und die Spannungen nehmen ab. Wenn du das Ergebnis nur mit der Kraft brauchst, dann ist das der letzte Zustand.

Zitat:

---

3) Warum hast du pro step nen eigenen output request definiert?

---

Das schreibt auch CAE so in die inp.

Zitat:

---

4) Bei mir lief es anscheinend noch nicht, weil ich den Kontakt zu "schwach" definiert habe. Rein rechnerisch müsste einer nämlich schon ab einer Verschiebung von 0.15 ...1 gebildet werden. Aber erst wenn ich 0.152 eingebe, funktioniert die Berechnung problemlos!? Also gibt es eine Art Kontaktschwelle vom Programm? Oder ist was an meiner Skalierung meiner parts nicht in Ordnung? Habe beide als .sat-file aus SolidWorks importiert.

---

Bei deiner Verschiebung waren die Konakte noch nicht ganz geschlossen. Wenn du einen Kontaktdruck (CPRESS) größer null oder COPEN=0 hast ist der Kontakt geschlossen. Bei welcher Verschiebung der Kontakt geschlossen ist ist natürlich problemabhängig. Ist ein Kontakt geschlossen kann man auf Kraftsteuerung umstellen.
Wenn dieses Vorgehen nicht angewendet werden kann weil sich z.B. beide Körper bewegen, kann man alternativ auch mit dem stabilisieren von Kontakten arbeiten.

Zitat:

---

Ist es immer besser solche Sachen (BCs, output requests, etc.) möglichst aufzusplitten? Nach step, dof, etc.?

---

Nein, das würde unübersichtlich werden. Das braucht man nur zu machen wenn es unbedingt notwendig ist um z.B. bestehende Definitionen zu erweitern oder zu verändern.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Danke! Hat mich nen gutes Stück weitergebracht. 
Bis demnächst!
hansi

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP