---

Hallo,

im Rahmen eines Praktikums bin ich gerade dabei ein User Material für Abaqus zu schreiben. Ich habe meinen Code in Fortran soweit fertig und mache mich nun ans Debuggen. Deshalb meine erste Frage: Gibt es einen bequemen Weg zum Debugging mit Hilfe von Visual Studio 2008? Den Intel Fortran Compiler habe ich installiert.
Momentan behelfe ich mir mit write- und read-Anweisungen.

Womit ich bei meinem eigentlichen Problem angelangt bin:

• In meiner UMAT rufe ich eine selbstgeschriebene Subroutine zur Berechnung von DDSDDE auf. Solange nach diesem Aufruf keine write-Anweisung einfüge, bricht die Berechnung sofort ab und die .log-Datei liefert:

  Code:

  ---

  11/12/2012 9:47:32 AM
  Abaqus Error: The executable standard.exe
  aborted with system error code 1073741819.

  ---

  
  Füge ich nun nach dem Aufruf der Subroutine für DDSDDE einen beliebigen write-Befehl ein, wird die Berechnung vollständig und korrekt durchgeführt. Hat jemand eine Idee woran das liegt?

• Eine andere Merkwürdigkeit, die ich mir bisher nicht erklären kann, hängt mit meinen lösungsabhängigen Variablen zusammen. Ich habe insgesamt zehn verschiedene lösungsabhängige Variablen eingeführt, die ich am Ende meiner UMAT Routine folgendermaßen dem Feld statev zuweise:
  

  Code:

  ---

  statev(1) = Bruchfunktion
        statev(2) = Variable_2
        statev(3) = Winkel
        statev(4) = Variable_4
        statev(5) = Variable_5
        statev(6) = Variable_6
        statev(7) = Variable_7
        statev(8) = Variable_8
        statev(9) = Variable_9
        statev(10)= Variable_10

  ---

  
  Die Berechnung der Variable_x erfolgt in Subroutinen, die ich übernommen habe und funktioniert ohne Probleme. Ich habe nun eine Subroutine eingefügt, die "Bruchfunktion" und "Winkel" ermittelt. Die Subroutine liefert auch die gewünschten Ergebnisse. Die Ausgabe dieser Variablen, sodass ich sie in der ODB Datei betrachten kann, funktioniert jedoch nicht ohne weiteres.
  Erst wenn ich nach dem Aufruf der Subroutine noch einen write-Befehl einfüge, der eine der beiden Variablen ausgibt, kann ich mir die beiden Variablen auch in der ODB anschauen.
  Weiß jemand wo mein Fehler liegt?
  

Die berechneten Spannungen und Verschiebungen stimmen mit einer Referenzlösung überein. Im Grunde bin ich schon froh, dass die UMAT Routine arbeitet. Da ich nun aber weitere Funktionen einfügen soll, möchte ich meine Fehler gerne nachvollziehen, um sie zukünftig von vorne herein ausschließen zu können.

Vielen Dank im Voraus

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

---

Hallo,

ich habe nach wie vor ein Problem mit der Zuweisung der lösungsabhängigen Variablen.

Momentan ist es leider so, dass eine lösungsabhängige Variable in der ODB mehr oder weniger beliebige Werte anzeigt, die nicht einmal im Wertebereich der Funktionen liegen, die der Berechnung der Variablen zugrunde liegen. Lasse ich mir die betreffende lösungsabhängige Variable jedoch mithilfe eines write-Befehls direkt in die log-Datei schreiben, sehe ich, dass die Berechnung korrekt abläuft und nur die Darstellung in der ODB nicht gelingt.

Code:

---

      write(*,*) 'Variable_1 =', Variable_1
      write(*,*) 'Variable_2=', Variable_2
      write(*,*) 'Variable_3 =', Variable_3
      statev(1) = Variable_1
      statev(2) = Variable_2
      statev(3) = Variable_3

---

Kurioserweise wird nicht immer die selbe Variable falsch dargestellt. Je nach Job ist mal die eine, mal die andere falsch. Ich habe bisher keinen blassen Schimmer womit das zu tun haben könnte.

Hat hier jemand eine Idee?

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

---

Hmm...
Ist jetzt nur eine Vermutung, aber vielleicht liegt es an der Deklaration der Variablen. Sind die richtigen Spezifikationen definiert (real, integer, usw.)?
Manchmal führt das Schreiben eines Wertes auf eine falsch deklarierte Variable zu nicht reproduzierbaren Fehlern. Ich hatte eine Weile mal falsche Werte, die sich als ZAHL+E310 darstellten und das mal so und mal so. Mein Fehler war damals, dass ich double precision und "normales" real gleichzeitig genutzt habe.

Du sagst noch, dass du weitere SDVs anfügst. Hast du im inp-file die *depvar Anzahl hochgesetzt? Wenn dort eine 8 steht und du aber einen statev-Vektor mit 10 Stellen beschreibst, kann es sein, dass kein Fehler gemeldet wird, sondern einfach falsche Schreibbefehle ausgeführt werden. Die berechneten Werte stimmen deiner Aussage nach, also vermute ich, dass es ein Zuweisungsproblem ist, welches mit den Speicherplätzen von Abaqus zusammen hängt. Check m.H. von write Anweisungen die Zuweisung deiner Werte auf die Plätze im statev-Vektor.

Bsp.:
write(*,*)'Variable_10: ',Variable_10
statev(10)=Variable_10
write(*,*)'statev(10): ',statev(10)

Warum die UMAT nur mit einer write-Ausgabe funktioniert und sonst nicht, kann ich mir derzeit nicht erklären. Dieses Phänomen ist mir bisher nicht untergekommen.
Wenn du dahingehend etwas herausfindest, dann teile uns dies bitte mit. Für den Fall dass jemandem Ähnliches passiert, ist das eine sehr nützliche Information.

besten Dank und viel Erfolg

mfg NxxN

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

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

---

Hallo,

wenn die write-Anweisung derart dein Ergebnis beeinflusst, dann kontrolliere mal im Detail die Array-Dimensionen.
Deine Beschreibung deutet für mich auf einen Speicherfehler hin.

Zu dem zweiten Problem:
Wenn die Dimensionen der SDV und der restlichen Arrays in den Routinen korrekt sind, dann sollte in der ODB genau das stehen, was du speicherst. Egal, ob du etwas mit per write in die Konsole ausgeben lässt.
Daher auch hier der Vorschlag die Array-Dimension zu kontrollieren.
Dann muss man auch beachten, dass die Kontur-Plots in ABQ auf Basis der Knotenwerte angezeigt werden. Die SDVs sind jedoch auf den Integrationspunkten definiert. Ist der Gradient zwischen zwei Integrationspunkten eines Elements ungünstig, kann es durchaus passieren, dass auf die Knoten Werte extrapoliert werden, die nicht im Soll-Wertebereich liegen.

Zudem in allen Routinen (umat, sdvini) die Reihenfolge der Übergabeparameter nochmal mit der verwendeten ABQ-Version abgleichen.

MfG,Viktor

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

---

Hallo,

also das Problem mit der write-Anweisung und der Jacobi-Matrix hat sich schon vor einiger Zeit dadurch beheben lassen, dass ich noch einmal die Übergabe der Formalparameter an meine Subroutinen, die das Hookesche Gesetz auswerten, korrigiert habe. Seitdem ich besser darauf achte, dass alle Parameter die richtigen Dimensionen haben, sind diese Fehler glücklicherweise nicht mehr aufgetreten.

Zu den SDV-Problemen habe ich bisher leider keine Lösung. Die write-Anweisung sowohl vor als auch nach der Zuweisung wie sie Nicksen vorgeschlagen hat, zeigt mir nur, dass in der ODB eigentlich auch die richtigen Werte stehen müssten. Ebenfalls sind alle Variablen als double precision deklariert.
Die *Depvar Option in der Input-File stimmt ebenfalls. Die Dimensionen aller verwendeten Arrays werde ich noch einmal prüfen, aber da ich Module verwende, bin ich mir relativ sicher, dass sie in jeder subroutine und function stimmen.

Ich habe auch mal das User subroutine interface direkt aus der Abaqus Dokumentation verwendet - ohne Erfolg. Dieses Interface sieht allerdings genauso aus wie in den alten Abaqus Versionen.
@Viktor: Oder meintest du etwas anderes?

Bleibt lediglich die (unwahrscheinliche) Möglichkeit, dass die Gradienten zwischen den Gausspunkten wirklich so wild aussehen.

Hoffentlich bringt die Überprüfung aller Array-Grössen die Lösung.

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

---

Hallo,

prüfe einfach die tatsächlichen Integrationpunkt-Werte im Viewer über die Query-Funktion.

MfG,Viktor

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