| | | KISTERS 3DViewStation: 3D-Visualisierung für After Sales, Service und Ersatzteile, eine Pressemitteilung
|
Autor
|
Thema: subroutine III (3908 mal gelesen)
|
Gunkerle Mitglied WMA
Beiträge: 133 Registriert: 15.03.2007
|
erstellt am: 29. Jan. 2009 13:46 <-- editieren / zitieren --> Unities abgeben:
Hallo ich versuche im CAE die user subroutines HETVAL und USDFLD genmeinsam zu benutzen, habe aber Schwierigkeiten die Uebergabe der in usdfld definierten Variablen hinzubekommen. Im manual steht an der entsprecehnden Stelle leider nur user coding fuer update von statev und flux. Leider habe ich ekein Beispiel gefunden, in dem diese Aufruf/Uebergabe der daten aus usdfld in Hetval mal durchgefuhert worden ist. Ich habe meinen Testfall (USDFLD & Hetval) unten angefügt. Wie muss ich die Übergabe der Stat-variablen an die Hetval gestalten. Dies ist mirt nicht klar? Waere schoen, wenn mal jemand sich meine Version anschauen koennte. Ich erhalte immer die Meldung : Error in job 01: Problem during compilation - F:\Test\uhetvalx.for Job 01 aborted due to errors. subroutine usdfld(field,statev,pnewdt,direct,t,celent,time,dtime, 1 cmname,orname,nfield,nstatv,noel,npt,layer,kspt,kstep,kinc, 2 ndi,nshr,coord,jmac,jmtyp,matlayo,laccflg) c include 'aba_param.inc' c character*80 cmname,orname character*3 flgray(15) dimension field(nfield),statev(nstatv),direct(3,3),t(3,3),time(2), * coord(*),jmac(*),jmtyp(*) dimension array(15),jarray(15) c c Get temperatures from previous increment call getvrm('TEMP',array,jarray,flgray,jrcd, $ jmac, jmtyp, matlayo, laccflg) call getvrm('ER',array,jarray,flgray,jrcd, $ jmac, jmtyp, matlayo, laccflg) call getvrm('S',array,jarray,flgray,jrcd, $ jmac, jmtyp, matlayo, laccflg) temp = array(1) epsdot11=array(2) c epsdot22=array(3) c epsdot33=array(4) c epsdot12=array(5) c epsdot13=array(6) c epsdot23=array(7) stress11=array(8) c stress22=array(9) c stress33=array(10) c stress12=array(11) c stress13=array(12) c stress23=array(13)
field(1) = temp field(2) = epsdot11 c field(3) = epsdot22 c field(4) = epsdot33 c field(5) = epsdot12 c field(6) = epsdot13 c field(7) = epsdot23 field(8) = stress11 c field(9) = stress22 c field(10) = stress33 c field(11) = stress12 c field(12) = stress13 c field(13) = stress23 statev(1) = field(2)*field(8) RETURN END Beispiel Hetval
SUBROUTINE HETVAL(CMNAME,TEMP,TIME,STATEV,DTIME,SVAR,FLUX,PREDEF, 1 DPRED) C INCLUDE 'ABA_PARAM.INC' C CHARACTER*80 CMNAME DIMENSION TEMP(2),SVAR(1),PREDEF(1),TIME(2),FLUX(2),DPRED(1),statev(1) C dummy=statev(1) FLUX(1)=0.40483+10+statev(1) c FLUX(1)=0.40483+10+dummy RETURN END Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
carsten1983 Mitglied Doktorand
Beiträge: 125 Registriert: 11.10.2007
|
erstellt am: 29. Jan. 2009 14:37 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
Die Meldung besagt das ein Fehler während des Kompilierens gefunden wurde Da hilft erstmal nur die Routine solang durch den Compiler zu schicken, bis man alle Fehler beseitigt hat. Ich habe deine Subroutinen eben auf die üblichen Fehler (Syntax, Komma,Klammer, Einrückung..) überprüft. Dabei hat mein Compiler noch n paar Fehler gefunden. Theoretisch solltest du jetzt (falls nicht durch copy&paste Fehler durch Einrückungen entstehen), wenn du die Routine verwendest andere Fehlermeldungen bekommen subroutine usdfld(field,statev,pnewdt,direct,t,celent,time,dtime, 1 cmname,orname,nfield,nstatv,noel,npt,layer,kspt,kstep,kinc, 2 ndi,nshr,coord,jmac,jmtyp,matlayo,laccflg) c include 'aba_param.inc' c character*80 cmname,orname character*3 flgray(15) dimension field(nfield),statev(nstatv),direct(3,3),t(3,3),time(2), * coord(*),jmac(*),jmtyp(*) dimension array(15),jarray(15) c c Get temperatures from previous increment call getvrm('TEMP',array,jarray,flgray,jrcd, $ jmac, jmtyp, matlayo, laccflg) call getvrm('ER',array,jarray,flgray,jrcd, $ jmac, jmtyp, matlayo, laccflg) call getvrm('S',array,jarray,flgray,jrcd, $ jmac, jmtyp, matlayo, laccflg) temp = array(1) epsdot11=array(2) c epsdot22=array(3) c epsdot33=array(4) c epsdot12=array(5) c epsdot13=array(6) c epsdot23=array(7) stress11=array(8) c stress22=array(9) c stress33=array(10) c stress12=array(11) c stress13=array(12) c stress23=array(13) field(1) = temp field(2) = epsdot11 c field(3) = epsdot22 c field(4) = epsdot33 c field(5) = epsdot12 c field(6) = epsdot13 c field(7) = epsdot23 field(8) = stress11 c field(9) = stress22 c field(10) = stress33 c field(11) = stress12 c field(12) = stress13 c field(13) = stress23 statev(1) = field(2)*field(8) RETURN END c Beispiel Hetval
SUBROUTINE HETVAL(CMNAME,TEMP,TIME,STATEV,DTIME,SVAR,FLUX,PREDEF, 1 DPRED) C INCLUDE 'ABA_PARAM.INC' C CHARACTER*80 CMNAME DIMENSION TEMP(2),SVAR(1),PREDEF(1),TIME(2),FLUX(2),DPRED(1), 1 statev(1) C dummy=statev(1) FLUX(1)=0.40483+10+statev(1) c FLUX(1)=0.40483+10+dummy RETURN END Zu der Geschichte mit den Statevariablen kann ich dir in diesem speziellen Fall nicht viel sagen. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Gunkerle Mitglied WMA
Beiträge: 133 Registriert: 15.03.2007
|
erstellt am: 29. Jan. 2009 15:01 <-- editieren / zitieren --> Unities abgeben:
Hallo carsten1983, ich erhalte nach wie vor nur die Fehlermeldung: Problem during compilation - F:\Test\uhetval-eps.for Wie würde denn in anderen Subroutines die Uebergabe der Statvariablen (aus der USDFLD) erfolgen? Was ich dazu bisher in den Handbüchern gefunden, fand ich nicht wirklich erhellend.
ciao Gunkerle
Zusatz: Ohne den versuch der Uebergabe der Statvariablen funktioniert die HETVAL so wie sie soll. [Diese Nachricht wurde von Gunkerle am 29. Jan. 2009 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
carsten1983 Mitglied Doktorand
Beiträge: 125 Registriert: 11.10.2007
|
erstellt am: 29. Jan. 2009 15:23 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
So wie ich die Hilfe verstehe, müssen einfach nur die Statevariablen mit Werten belegt werden (Nachdem sie angefordert wurden). Die Übergabe an sich erfolgt in meinen Augen durch den Aufruf beider Subroutinen mit dem Parameter STATEV(Nstatv) in der Parameterliste. Ich habe aber, wenn ich ehrlich bin im Moment ein sehr ähnliches Problem: Ich schreibe gerade an einer UMAT rum, bei der bestimmte Sachen mithilfe der Statevariablen von einem Inkrement ins nächste geholt werden sollen. Dabei hat sich die Übergabe bis jetzt auch als wenig erfolgreich entpuppt. Mein Problem an der Stelle ist, dass die Statevariablen partout nicht vom 0. ins 1. Inkrement übertragen werden. Selbst wenn sie am Ende des 0. Inkrements ausgegeben werden und alles ok scheint, werden sie bei einer Ausgabe direkt am Anfang des folgenden Inkrements mit 0 ausgegeben. Zu deiner Fehlermeldung: Ich bin mir sehr sicher, dass diese Meldung auf einen schlichten Syntaxfehler hindeutet. Ich habe gerade an einer funktionieren Routine einfach ein Komma eingefügt, womit sofort diese Meldung provoziert wurde. Edit: Ich habe die fehlerfrei compilierte Datei als test.txt hochgeladen, kannst die ja mal versuchen [Diese Nachricht wurde von carsten1983 am 29. Jan. 2009 editiert.] [Diese Nachricht wurde von carsten1983 am 29. Jan. 2009 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Nicksen Mitglied wissenschaftlicher Mitarbeiter
Beiträge: 239 Registriert: 04.05.2007
|
erstellt am: 30. Jan. 2009 10:07 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
Vorschlag: Initiiere doch am Start der Inkremente deine STATEV neu. Speicher zB die Startwerte in einem Modul und hol sie dort wieder raus. Die weitere Berechnung der aktualisierten STATEV musst du ja eh schon programmiert haben. ------------------ ========== == Dingsen == ========== Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Gunkerle Mitglied WMA
Beiträge: 133 Registriert: 15.03.2007
|
erstellt am: 30. Jan. 2009 10:50 <-- editieren / zitieren --> Unities abgeben:
Zitat: Original erstellt von Nicksen: Vorschlag:Initiiere doch am Start der Inkremente deine STATEV neu. Speicher zB die Startwerte in einem Modul und hol sie dort wieder raus. Die weitere Berechnung der aktualisierten STATEV musst du ja eh schon programmiert haben.
Hallo Nicksen, waere es moeglich mir mal ein einfaeches konkretes Beispiel fuer deinen Vorschlag zu schicken? ich kann ja mal beschreiben, wie ich die Zusammenhänge sehe: Statev ist ein Feld, dessen Komponenten einfach ueber Zuweisungen mit werten belegt werden koennen. In der Usersubroutine USDFLD wird am Anfang des Inkrementes die Statev aktualisiert, indem die Werte der benoetigten Variablen sich mittels getvrm besorgt werden und dann per Zuweisungskette (siehe unten) statev mit den gewuenschten Werten aufgefuellt wird. In meinem Fall bvaruche ich eine skalare Statev. call getvrm('TEMP',array,jarray,flgray,jrcd, $ jmac, jmtyp, matlayo, laccflg) call getvrm('ER',array,jarray,flgray,jrcd, $ jmac, jmtyp, matlayo, laccflg) call getvrm('S',array,jarray,flgray,jrcd, $ jmac, jmtyp, matlayo, laccflg) temp = array(1) epsdot11=array(2) stress11=array(8) field(1) = temp field(2) = epsdot11 field(8) = stress11 statev(1) = field(2)*field(8) Was mir bisher unklar ist, wie die Werte an die Hetval uebergeben werden. Sprich reicht ein Aufruf der Form (in der Hetval) aus? In der Form wie unten angegeben, hatte ich das Manual jedenfalls verstanden, aber genau das scheint ja nicht zu funktionieren, deshalb ???
HETVAL: dimension dummy(XYZ) dummy(1)=statev(1) FLUX(1)=0.40483+10+dummy ciao Gunkerle
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Gunkerle Mitglied WMA
Beiträge: 133 Registriert: 15.03.2007
|
erstellt am: 30. Jan. 2009 11:02 <-- editieren / zitieren --> Unities abgeben:
Hallo, ich habe Carstens zurueckgeschickte Hetval-Variante ausprobiert und erhalte jetzt die folgende Meldung. Ich benutze die version 67 EF-1 Problem during linking - Abaqus/Standard User Subroutines. This error may be due to a mismatch in the Abaqus user subroutine arguments. These arguments sometimes change from release to release, so user subroutines used with a previous version of Abaqus may need to be adjusted.
Momentan starte ich den Compilationsvorgang aus Abaqus cae heraus, mittels der Option beim Jobstart entsprechende Subroutines einbinden zu koennen. Koennten die Problem auch daher kommen? Wie wuerde ein etsprechender Befehl zum Einbinden mehrerer Usersubroutines in der Kommandozeilenvariante aussehen? ciao gunkerle
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Nicksen Mitglied wissenschaftlicher Mitarbeiter
Beiträge: 239 Registriert: 04.05.2007
|
erstellt am: 30. Jan. 2009 12:06 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
Hi, also zum letzten Beitrag erstmal... Die Konsolenvariante ohne CAE ist so: abaqus job=<*inp-file ohne Dateiendung> user=<USER-file ohne Dateiendung> Das Verwenden mehrerer Routinen funktioniert, wenn alle Routinen in einem FORTRAN-file gespeichert werden und diese "Sammlung" unter user=... angegeben wird. Frage hier: Hast du alle Routinen in ein FORTRAN-file gelegt und diese dann als Subroutinendatei angegeben oder anders? Zu der anderen Sache mit den STATEV... Wie die Uebergabe genau funktioniert kann ich leider nicht sagen, aber ich denke, wir werden das schon hinbekommen. Schau vorerst, dass du das mit dem Routinen-file regelst und dann sehen wir weiter.
Ich hab im Moment auch noch ein paar kleine Fehler zu finden und die Zeit drueckt schon arg. Dennoch versuch ich, dir den ein oder anderen Tip zu geben. Alles was ich an Fehlern mit Subroutinen bisher gemacht habe, musst du ja nicht noch einmal machen. Ein Beispiel, wie du es wolltest, kann ich derzeit allerdings nicht bieten. Da hab ich nichts da. bis in baelde der Nicksen ------------------ ========== == Dingsen == ========== Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Gunkerle Mitglied WMA
Beiträge: 133 Registriert: 15.03.2007
|
erstellt am: 04. Feb. 2009 08:32 <-- editieren / zitieren --> Unities abgeben:
Zitat: Original erstellt von Nicksen: Hi,also zum letzten Beitrag erstmal... Die Konsolenvariante ohne CAE ist so: abaqus job=<*inp-file ohne Dateiendung> user=<USER-file ohne Dateiendung> Das Verwenden mehrerer Routinen funktioniert, wenn alle Routinen in einem FORTRAN-file gespeichert werden und diese "Sammlung" unter user=... angegeben wird. Frage hier: Hast du alle Routinen in ein FORTRAN-file gelegt und diese dann als Subroutinendatei angegeben oder anders? bis in baelde der Nicksen
Hallo Nicksen, bisher habe ich versucht mehrere files einzubinden. Kein Wunder also, dass Abaqus meckert. War die letzten Tage mit hohem Fieber krank, deshalb melde ich mich jetzt erst wieder. Bis demnächst ciao Gunkerle
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Nicksen Mitglied wissenschaftlicher Mitarbeiter
Beiträge: 239 Registriert: 04.05.2007
|
erstellt am: 04. Feb. 2009 15:44 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
|
Gunkerle Mitglied WMA
Beiträge: 133 Registriert: 15.03.2007
|
erstellt am: 10. Feb. 2009 10:42 <-- editieren / zitieren --> Unities abgeben:
Hallo alle zusammen, auch wenn ich allealle subroutinen in einem File zusammenfasse, bekomme ich die folgende Fehlermeldung: Error in job test7: Problem during linking - Abaqus/Standard User Subroutines. This error may be due to a mismatch in the Abaqus user subroutine arguments. These arguments sometimes change from release to release, so user subroutines used with a previous version of Abaqus may need to be adjusted. Job test7 aborted due to errors.
Ohne den versuch die USDFLD Informationen einzubinden, also Hetval alleine, funktioniert.
Weiss jemand Rat? ciao gunkerle Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
carsten1983 Mitglied Doktorand
Beiträge: 125 Registriert: 11.10.2007
|
erstellt am: 10. Feb. 2009 10:53 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
Überprüf mal die Argumente von USDFLD. Bei dir steht ganz am Ende Jmtyp, in der Doku heißt dieses Argument aber JMATYP. Der Compiler meckert, weil die Argumente die er für USDFLD hinterlegt hat nicht mit den Namen deiner Argumente übereinstimmen. Edit: Außerdem scheint mir auch der Name des letzten Arguments fehlerhaft zu sein. Laut Doku sollte dort statt LACCFLG LACCFLA stehen. Versuch das mal, das sollte eigentlich Abhilfe schaffen. [Diese Nachricht wurde von carsten1983 am 10. Feb. 2009 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Gunkerle Mitglied WMA
Beiträge: 133 Registriert: 15.03.2007
|
erstellt am: 17. Feb. 2009 12:58 <-- editieren / zitieren --> Unities abgeben:
Hallo alle zusammen, ich bin etwas weiter aber leider noch nicht durch :-). Ich bekomme die in der Datei angegebenen beiden Fehlermeldungen. Kann jemand weiterhelfen? Der benutze Qzuellcode ist in der Textdatei hinterlegt. ciao gunkerle
[Diese Nachricht wurde von Gunkerle am 17. Feb. 2009 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Nicksen Mitglied wissenschaftlicher Mitarbeiter
Beiträge: 239 Registriert: 04.05.2007
|
erstellt am: 17. Feb. 2009 17:02 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
Hallo Gunkerle, in deinem Quellcode ist viel auskommentiert. Als erstes wuerde ich in der USFLD das Interface umbrechen, denn so eine lange Zeile wird sicherlich vom Compiler nicht vollstaendig gelesen. Wenn du die Zeile umbrichst, dann achte darauf, dass du ein Fortsetzungszeichen hinzufuegst. Schau dir das auskommentierte Interface der USFLD an, dort sind Zahlen als Fortsetzungszeichen genutzt worden. Wobei ich mich grade frage, warum du das nicht sowieso nutzt, denn dort steht dasselbe drin, wie in der langen Zeile. Die Definitionen der einzelnen Variablen sollten auch lieber nicht geaendert werden. ABAQUS liefert den Routinenkopf doch komplett im Manual mit, warum dann nicht verwenden? Probier das mit dem Umbrechen mal aus. Die Fehlermeldung hinsichtlich dem implicit- statement versteh ich nicht so recht. Das sollte doch alles in dem INCLUDE-file stehen und daran hab ich noch nie was geaendert. Das andere riecht in meinen Augen derb nach einem verfruehten Zeilenende fuer den Compiler. Viel Erfolg erstmal. Bis morgen oder so. Grueße vom Nicksen ------------------ ========== == Dingsen == ========== Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Gunkerle Mitglied WMA
Beiträge: 133 Registriert: 15.03.2007
|
erstellt am: 20. Feb. 2009 11:11 <-- editieren / zitieren --> Unities abgeben:
Zitat: Original erstellt von Nicksen: Hallo Gunkerle,in deinem Quellcode ist viel auskommentiert. Als erstes wuerde ich in der USFLD das Interface umbrechen, denn so eine lange Zeile wird sicherlich vom Compiler nicht vollstaendig gelesen. Wenn du die Zeile umbrichst, dann achte darauf, dass du ein Fortsetzungszeichen hinzufuegst. Schau dir das auskommentierte Interface der USFLD an, dort sind Zahlen als Fortsetzungszeichen genutzt worden. Wobei ich mich grade frage, warum du das nicht sowieso nutzt, denn dort steht dasselbe drin, wie in der langen Zeile. Die Definitionen der einzelnen Variablen sollten auch lieber nicht geaendert werden. ABAQUS liefert den Routinenkopf doch komplett im Manual mit, warum dann nicht verwenden? Probier das mit dem Umbrechen mal aus. Die Fehlermeldung hinsichtlich dem implicit- statement versteh ich nicht so recht. Das sollte doch alles in dem INCLUDE-file stehen und daran hab ich noch nie was geaendert. Das andere riecht in meinen Augen derb nach einem verfruehten Zeilenende fuer den Compiler. Viel Erfolg erstmal. Bis morgen oder so. Grueße vom Nicksen Hallo Nicksen, ich hatte es zunaechst genau so wie im Beipiel mit den Umbruchzeilen, da hatte der Compiler dann Fehlermeldungen ausgegeben (und zwar fuer JEDE Umbruchzeile!), die erst verschwunden waren, nachdem ich alles in eine Zeile geschrieben hatte.
ciao Gunkerle
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Nicksen Mitglied wissenschaftlicher Mitarbeiter
Beiträge: 239 Registriert: 04.05.2007
|
erstellt am: 20. Feb. 2009 13:06 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
Wir reden aber noch immer ueber FORTRAN im fixed-format oder? Sind denn bei der Version mit Umbruch wirklich alle Zeichen an ihrem richtigen Platz? Das kommt mir schon komisch vor. Bitte pack die betreffende inp-Datei zusammen mit deinen Subroutinen in ein Archiv und lad das mal hoch. Ich wuerde sehr gerne in der kommenden Woche schauen, ob das bei mir klappt. Ein feines Wochenende erstmal. Grueße ------------------ ========== == Dingsen == ========== Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Gunkerle Mitglied WMA
Beiträge: 133 Registriert: 15.03.2007
|
erstellt am: 23. Feb. 2009 11:21 <-- editieren / zitieren --> Unities abgeben:
Zitat: Original erstellt von Nicksen: Wir reden aber noch immer ueber FORTRAN im fixed-format oder? Sind denn bei der Version mit Umbruch wirklich alle Zeichen an ihrem richtigen Platz? Das kommt mir schon komisch vor.Bitte pack die betreffende inp-Datei zusammen mit deinen Subroutinen in ein Archiv und lad das mal hoch. Ich wuerde sehr gerne in der kommenden Woche schauen, ob das bei mir klappt. Ein feines Wochenende erstmal. Grueße
Hallo Nicksen, ich habe die Testdateien mal hochgeladen. Es sind 3 dateien 1.) Input file (test.inp) 2.) Kombination aus USDFLD & HETBVAL Subroutine (die funktioniert nicht: si-1-changed-2.for) 3.) hetval subroutine alleine (funktioniert: si-1-changed.for) Ich vermute ,dass die Probleme etwas mit der langen Zeile zu tun haben beim si-1-changed-2.for-File im USDFLD-Subroutinen Abschnitt. Ich ahbe allerdings Varianten wie mehrere zeile ausprobiert (sprich copy & paste plus Abstandskorrekturen für die fixed-form-Variante). Die kombinierte fassung lief bisher allerdings nicht durch. Erreichen moenchte ich eine Eigendefinition der Waermestrome & Leistungen ueber Terme der Art: Integration/Summation ueber : spannung_ij * dehnrate_ij. Wenn ich das Manual richtig verstanden habe, benoetige ich dafuer die USDFLD und muss mir die entsprechenden Variablen mittels get_XYZ in die USDFLD verfuegbar machen. ciao Gunkerle
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Nicksen Mitglied wissenschaftlicher Mitarbeiter
Beiträge: 239 Registriert: 04.05.2007
|
erstellt am: 24. Feb. 2009 09:06 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
Hi Gunkerle, jetzt LAEUFTS!!! Also mit der langen Zeile klappt das bei mir auch nicht. Aber schon ganz zu Beginn musste ich die Dateiendung von *.for auf *.f aendern, da mein Compiler offensichtlich nur danach sucht. Wie dem auch sei. Die erste Version lief ohne Probleme seitens der Kompilierung durch. Bemerken moechte ich jedoch, dass im *.msg file sehr viele Sigularitaeten angemahnt werden. Da ich mit gekoppelten Temperaturproblemen nicht oft zu tun habe, wirst du schon wissen, ob das so sein muss. Und noch was: Im *.dat file steht diese Bemerkung: ***WARNING: THE *USER DEFINED FIELD OPTION HAS BEEN USED, BUT THERE ARE NO USER-DEFINED FIELDS ACTIVE IN THE MODEL. USER-DEFINED FIELDS MAY BE ACTIVATED BY THE *FIELD OR *INITIAL CONDITIONS,TYPE=FIELD OPTIONS OR BY DEFINING MATERIALS WITH FIELD VARIABLE DEPENDENCIES Da fuer beide Routinen-Versionen dasselbe *.inp verwendet wird, solltest du noch einmal genau pruefen, ob deine Hetval wirklich genutzt werden kann. Die zweite Version (si-1-changed-2.f) habe ich nur geringfuegig geaendert. Als erstes hatte ich einfach die lange Zeile umgebrochen und die Fortsetzungszeichen an die richtige Stelle gesetzt. Dann lief sie bereits durch; natuerlich mit denselben oben angesprochenen Warnungen in *.dat und *.msg! Danach hab ich diese Zeilen aus- und deine urspruenglichen Zeilen wieder einkommentiert. Da klappte es nicht sofort. Der Fehler hier: Das Wort SUBROUTINE bei der USFLD war eine Stelle zu weit links. Es fehlte ein Lehrzeichen. In dem Archiv, welches ich hier anhaengen werde, findest du die Routinen mit der Endung *.f, die sich von deinen unterscheiden. Da kannst du das noch einmal nachschauen. Jedenfalls laufen beide FORTRAN Dateien nun durch und du kannst weiterarbeiten. Pruefe jedoch noch einmal genau, ob dein User-Feld wirklich genutzt wird. Mir scheint dass da noch ein Keyword im *.inp fehlt. Sollte im Manual zu finden sein. beste Grueße und weiterhin gutes Gelingen der Nicksen ------------------ ========== == Dingsen == ========== Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Gunkerle Mitglied WMA
Beiträge: 133 Registriert: 15.03.2007
|
erstellt am: 25. Feb. 2009 09:41 <-- editieren / zitieren --> Unities abgeben:
Zitat: Original erstellt von Nicksen: Hi Gunkerle,jetzt LAEUFTS!!! Also mit der langen Zeile klappt das bei mir auch nicht. Aber schon ganz zu Beginn musste ich die Dateiendung von *.for auf *.f aendern, da mein Compiler offensichtlich nur danach sucht. Wie dem auch sei. Die erste Version lief ohne Probleme seitens der Kompilierung durch. Bemerken moechte ich jedoch, dass im *.msg file sehr viele Sigularitaeten angemahnt werden. Da ich mit gekoppelten Temperaturproblemen nicht oft zu tun habe, wirst du schon wissen, ob das so sein muss. Und noch was: Im *.dat file steht diese Bemerkung: ***WARNING: THE *USER DEFINED FIELD OPTION HAS BEEN USED, BUT THERE ARE NO USER-DEFINED FIELDS ACTIVE IN THE MODEL. USER-DEFINED FIELDS MAY BE ACTIVATED BY THE *FIELD OR *INITIAL CONDITIONS,TYPE=FIELD OPTIONS OR BY DEFINING MATERIALS WITH FIELD VARIABLE DEPENDENCIES Da fuer beide Routinen-Versionen dasselbe *.inp verwendet wird, solltest du noch einmal genau pruefen, ob deine Hetval wirklich genutzt werden kann. Die zweite Version (si-1-changed-2.f) habe ich nur geringfuegig geaendert. Als erstes hatte ich einfach die lange Zeile umgebrochen und die Fortsetzungszeichen an die richtige Stelle gesetzt. Dann lief sie bereits durch; natuerlich mit denselben oben angesprochenen Warnungen in *.dat und *.msg! Danach hab ich diese Zeilen aus- und deine urspruenglichen Zeilen wieder einkommentiert. Da klappte es nicht sofort. Der Fehler hier: Das Wort SUBROUTINE bei der USFLD war eine Stelle zu weit links. Es fehlte ein Lehrzeichen. In dem Archiv, welches ich hier anhaengen werde, findest du die Routinen mit der Endung *.f, die sich von deinen unterscheiden. Da kannst du das noch einmal nachschauen. Jedenfalls laufen beide FORTRAN Dateien nun durch und du kannst weiterarbeiten. Pruefe jedoch noch einmal genau, ob dein User-Feld wirklich genutzt wird. Mir scheint dass da noch ein Keyword im *.inp fehlt. Sollte im Manual zu finden sein. beste Grueße und weiterhin gutes Gelingen der Nicksen
Hallo Nicksen, vielen herzlichen Dank fuer deine Bemuehungen, ich war schon ziemlich am verweifeln. ciao Gunkerle
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Nicksen Mitglied wissenschaftlicher Mitarbeiter
Beiträge: 239 Registriert: 04.05.2007
|
erstellt am: 25. Feb. 2009 10:10 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
|
Kappel Mitglied WMA
Beiträge: 48 Registriert: 14.11.2006 EDIT: Ich kann mit meinem Script defo1 und defo2 verarbeiten und daraus neue Felder erzeugen. Der Fehler tritt also aus wenn ich die Daten aus zwei ODBs verarbeite. Die Dimensionen der Felder müssen aber gleich groß sein weil ODB2 auf dem gleichen Modell basiert wie ODB1 wobei nur die Knotenkoordinaten verschoben wurden.
|
erstellt am: 02. Apr. 2009 08:32 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
Hallo, ich mache gerade meine ersten Gehversuche mit der Erstellung von Userroutinen. Leider kann ich dem Manual nicht entnehmen, wo ich meine erstelle Routine "hinkopieren" muss damit er sie findet. Ich verwende Abaqus 681. ein kurzer Hinweis wäre toll! lg E.K. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Nicksen Mitglied wissenschaftlicher Mitarbeiter
Beiträge: 239 Registriert: 04.05.2007
|
erstellt am: 02. Apr. 2009 08:43 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
Hallo Kappel, das Routinenfile muss bei einem Rechnungsstart aus der Konsole, in dem aktuellen Arbeitsverzeichnis liegen. Also da wo auch das entsprechende *.inp file zu finden ist. Wenn du aus CAE heraus die Rechnung startest, dann musst du das Routinenfile in den Job-Optionen ja angeben. Da kannst du dich dann zu dem entsprechenden Ort durchklickern. Ich persoenlich bevorzuge die erste Variante. Ich gehe in mein Arbeitsverzeichnis, erstelle die *.f Datei wo alle notwendigen Routinen drinstehen und dann starte ich meine Rechnung: abq681.exe job=meinINPfile user=meinROUTINENfile interactive Das "interactive" ist nur dazu da, um die Eintraege aus dem *.log auf die Konsole umzuleiten. So sieht man was beim Compilieren und Linken passiert und erkennt auch ziemlich gut, wann der Job beendet ist. Probiers mal aus. Beachte aber, dass du einen FORTRAN compiler brauchst und die entsprechenden Variablen und Pfade gefunden werden. Vllt. kopierst du einfach aus dem verificaton-manual eine INP und eine zugehoerige Routine in ein beliebiges Verzeichnis und testest, ob dein System derzeitig in der Lage ist, mit Subroutinen zu arbeiten. Grueße und gutes Gelingen der Nicksen ------------------ ========== == Dingsen == ========== Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Kappel Mitglied WMA
Beiträge: 48 Registriert: 14.11.2006 EDIT: Ich kann mit meinem Script defo1 und defo2 verarbeiten und daraus neue Felder erzeugen. Der Fehler tritt also aus wenn ich die Daten aus zwei ODBs verarbeite. Die Dimensionen der Felder müssen aber gleich groß sein weil ODB2 auf dem gleichen Modell basiert wie ODB1 wobei nur die Knotenkoordinaten verschoben wurden.
|
erstellt am: 02. Apr. 2009 09:03 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
Hallo Nicksen, Danke für den Hinweis. Ich habe wer weiß wo gesucht aber nicht in den Joboptionen Jetzt konnte ich es finden und habe auch deinen Tip versucht umzusetzen. Nun bekomme ich einen Fehler der wie folgt aussieht: Problem during linking - Abaqus/Standard User Subroutines. This Error may be due to a mismatch in the ABAQUS user subroutine arguments. These arguments sometimes change from release to release.... Hast Du vielleicht einen Tipp wie ich diesem Problem auf den Grund gehen kann? Das klingt ja eher so, als ob es Änderungen an der an den Benennungen der Variablen gegeben hat. lg Erik [Diese Nachricht wurde von Kappel am 02. Apr. 2009 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
carsten1983 Mitglied Doktorand
Beiträge: 125 Registriert: 11.10.2007
|
erstellt am: 02. Apr. 2009 09:18 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
|
Kappel Mitglied WMA
Beiträge: 48 Registriert: 14.11.2006 EDIT: Ich kann mit meinem Script defo1 und defo2 verarbeiten und daraus neue Felder erzeugen. Der Fehler tritt also aus wenn ich die Daten aus zwei ODBs verarbeite. Die Dimensionen der Felder müssen aber gleich groß sein weil ODB2 auf dem gleichen Modell basiert wie ODB1 wobei nur die Knotenkoordinaten verschoben wurden.
|
erstellt am: 02. Apr. 2009 09:35 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
Hallo Carsten, ich habe den Thread gelesen. Aber so wirklich liefert er die Lösung nicht. Um die Funktion meines Systems zu testen habe ich die Dateien "uexpan2x.for" und "uexpan2x.inp" aus dem Verification Manual in ein Verzeichnis kopiert und versucht durchzurechnen. Ich bekomme erneut die oben genannte Fehlermeldung. Ich nutze die HTML Documentation zu Abaqus 681. Hilfreich wäre eine Liste der Parameter, die in dieser Version von Abaqus übergeben werden. Vielleicht gibt es da tatsächlich Neuerungen. Weiß jemand auf anhieb, wo ich eine derartige Liste finde? lg Erik Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
carsten1983 Mitglied Doktorand
Beiträge: 125 Registriert: 11.10.2007
|
erstellt am: 02. Apr. 2009 09:42 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
Hallo, die Ursache kann eigentlich nur sein, dass ein Fehler bei der Argumentübergabe auftritt. An deiner Stelle würde ich das Handbuch (passend zu deiner Version) nehmen und aus dem Kapitel "User Subroutines Verification Manual" den Korpus für deine Routinen übernehmen, dann sollte dieser Fehler behoben sein. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Kappel Mitglied WMA
Beiträge: 48 Registriert: 14.11.2006 EDIT: Ich kann mit meinem Script defo1 und defo2 verarbeiten und daraus neue Felder erzeugen. Der Fehler tritt also aus wenn ich die Daten aus zwei ODBs verarbeite. Die Dimensionen der Felder müssen aber gleich groß sein weil ODB2 auf dem gleichen Modell basiert wie ODB1 wobei nur die Knotenkoordinaten verschoben wurden.
|
erstellt am: 02. Apr. 2009 10:14 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
Hallo, ich gehe auch davon aus, dass etwas bei der Parameterübergabe nicht passt. Wie genau kann ich jetzt aber rausfinden was das ist? gibt es in der Dokumentation irgendwo eine Liste der Abaqusvariablen, die für die Kommunikation mit den Routinen genutzt werden. Kann es denn wirklich sein, dass die Dokumentation an dieser Stelle veraltet ist? (Mir fehlt da leider die Erfahrung) lg Erik Edit: Derart startet meine Routine:
Code: SUBROUTINE UEXPAN(EXPAN,DEXPAN,TEMP,TIME,DTIME,PREDEF, DPRED,STATEV,CMNAME,NSTATV,NOEL) ... DIMENSION EXPAN(*),TEMP(2),TIME(2),...
Ich habe jetzt einmal in der Dokumentation nach der UMAT gesehen. Da gibt es bereits Unterschiede: Während in meinem Beispiel 2-komponentenvektoren für TEMP und TIME übergeben werden, bekommt die UMAT die Parameter TEMP,DTEMP, TIME und dt übergeben. Hat jemand mal mit der UEXPAN in 6.8.1 gearbeitet? EDIT2: Was sagt mir zum Beispiel EXPAN(*) Mit "Dimension" lege ich eigentlich ja die Dimension der Varibale fest. Aber wofür steht der *? Ist das etwas Ähnliches wie die dynamische Speicherallokation in Fortran 90/95? [Diese Nachricht wurde von Kappel am 02. Apr. 2009 editiert.] [Diese Nachricht wurde von Kappel am 02. Apr. 2009 editiert.] Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Gunkerle Mitglied WMA
Beiträge: 133 Registriert: 15.03.2007
|
erstellt am: 02. Apr. 2009 14:36 <-- editieren / zitieren --> Unities abgeben:
lg Erik Edit: Derart startet meine Routine:
Code: SUBROUTINE UEXPAN(EXPAN,DEXPAN,TEMP,TIME,DTIME,PREDEF, DPRED,STATEV,CMNAME,NSTATV,NOEL) ... DIMENSION EXPAN(*),TEMP(2),TIME(2),...
Ich habe jetzt einmal in der Dokumentation nach der UMAT gesehen. Da gibt es bereits Unterschiede: Während in meinem Beispiel 2-komponentenvektoren für TEMP und TIME übergeben werden, bekommt die UMAT die Parameter TEMP,DTEMP, TIME und dt übergeben. Hat jemand mal mit der UEXPAN in 6.8.1 gearbeitet? EDIT2: Was sagt mir zum Beispiel EXPAN(*) Mit "Dimension" lege ich eigentlich ja die Dimension der Varibale fest. Aber wofür steht der *? Ist das etwas Ähnliches wie die dynamische Speicherallokation in Fortran 90/95? [/B][/QUOTE] Hallo Erik, versuche mal... ...den * durch eine hinreichend große Zahl zu ersetzen. ...darauf zu achten, dass bei Copy & Paste Aktionen keine ueberfluessigen Blanks mitkopiert werden ...alle Variablennamen in der uebergabeliste GROSS geschrieben sind und an der richtigen Stelle stehen ciao Gunkerle Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Kappel Mitglied WMA
Beiträge: 48 Registriert: 14.11.2006 EDIT: Ich kann mit meinem Script defo1 und defo2 verarbeiten und daraus neue Felder erzeugen. Der Fehler tritt also aus wenn ich die Daten aus zwei ODBs verarbeite. Die Dimensionen der Felder müssen aber gleich groß sein weil ODB2 auf dem gleichen Modell basiert wie ODB1 wobei nur die Knotenkoordinaten verschoben wurden.
|
erstellt am: 03. Apr. 2009 07:30 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
Guten Morgen, Ist das Großschreiben wirklich relevant? Ich habe den Block aus der Dokumentation kopiert. Leerzeichen werden doch vom Compiler ignoriert oder nicht? Hat vielleicht jemand eine Minisubroutine, die unter ABAQUS 681 läuft. Ich will nur sehen ob mein Compiler seinen Dienst ordnungsgemäß ausübt. Für den Stern (*) eine hinreichend große Zahl angeben ist doch nicht wirklich sinnvoll. Ich bin mir nicht ganz sicher ob ich die Doku an dieser Stelle richtig verstehe, eigentlich sollte die Vorgabe im Propertymodul (Expansion -> Isotrop) die Dimension der Parameter in der Routine festlegen. Hmm, ich bin ein wenig ratlos! Hat noch jemand eine Idee? lg Erik Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Kappel Mitglied WMA
Beiträge: 48 Registriert: 14.11.2006 EDIT: Ich kann mit meinem Script defo1 und defo2 verarbeiten und daraus neue Felder erzeugen. Der Fehler tritt also aus wenn ich die Daten aus zwei ODBs verarbeite. Die Dimensionen der Felder müssen aber gleich groß sein weil ODB2 auf dem gleichen Modell basiert wie ODB1 wobei nur die Knotenkoordinaten verschoben wurden.
|
erstellt am: 03. Apr. 2009 09:09 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
So ich konnte nun das Problem beheben. Es hatte, entsprechend meinen Erwartungen nichts mit der Routine zu tun. Ich habe in der DOS-Eingabeaufforderung folgendes eingegeben: C:\abaqus verify -user Dort werden dann einige Tests gemacht. Unter Anderem fird dort angezeigt oder der Compiler den Anforderungen entspricht usw. Bei mir lief dieses Tool durch, meldete aber am Ende einen Fehler. In diesem Fall wird auf der Festplatte ein Ordner "C:\verify" angelegt. In diesem Ordner befindet sich ein Logfile (*.log) indem Informationen zu finden sind. Weiter unten in dieser Datei stand bei mir in etwa folgendes: "LINK: fatal error LNK1104: cannot open file 'oldnames.lib'... Wie sich herausgestellt hat bedeutet dieser Fehler, dass die Datei oldnames.lib nicht im LIB Verzeichnet des Intel Fortran Compilers liegt. Ich habe die Datei aus meinem alten Compaq Compiler kopiert und in den LIB Ordner des Intel Compilers eingefügt. Nachdem ich dann erneut im Dos-Fenster den oben genannten Befehl eingegeben habe erhielt ich eine analoge Fehlermeldung für die datei "mscvrt.lib". nachdem diese Datei auch ins Fortran-Lib-Verzeichnis kopiert habe ich erneut das Verify... durchlaufen lassen, mit dem Resultat, dass Dort stand PASS. (In diesem Fall wird kein Verify Ordner auf C:\ erstellt) Resultat: subroutinen funktionieren! Danke für die Hilfe!
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Bayazid Mitglied Student
Beiträge: 1 Registriert: 05.07.2011
|
erstellt am: 06. Okt. 2011 16:16 <-- editieren / zitieren --> Unities abgeben: Nur für Gunkerle
Hallo, Ich versuche eine lokale Laserwärmebehandlung zu simulieren. Meine Aufgabe war nur die Temperaturfelder zu berechnen. Die bezüglichen Phasenumwandlungen sollen durch experimentelle Untersuchungen ermittelt werden. Danach bin ich auf die Idee gekommen, die Phasenumwandlungen auch zu simulieren. Ich habe die Subroutine HETVAL gefunden und ein einfaches Model habe ich damit berechnet. Aus andere Seite habe ich ein komplettes Algorithmus für Phasenumwandlung entwickelt besteht aus JMAK-Gleichung und Mrburger-Model. Ich habe Probleme mit der Funktion und Bedeutung von STATEV und FIELD, wie kann ich die im HETVAL einfügen? Können Sie bitte mir dabei helfen?? Mit herzlichen Dank im Vorraus
Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
| Anzeige.:
Anzeige: (Infos zum Werbeplatz >>)
|