DYNA_LINE_TRAN mit Zwischenbewertung von Ergebnis
ich versuche mal ein paar hoffentlich hilfreiche Kommentare zu geben:
ja, lediglich die Kraefte und der Analysistyp DYNA_LINE_TRAN muss hinzugefuegt werden (die matrizen werden uebernommen.MGolbs wrote: # als Basis *.comm für transient kann man sicher 90% der harmonischen *.comm nutzen (Netz, Eigenschaften, Kinematik, Lagerungen..)?
Es gibt die Funktion LIRE_FONCTION, damit kann man Daten aus einer ASCII Datei ganz einfach importieren (zum Beispiel CSV).MGolbs wrote: # für die Kraft-Zeitfunktionen der transienten Analyse würde ich gern ASCI Dateien nutzen (also nicht direkt in *.comm einbauen) Die sollte doch mit Python möglich sein, oder gibt es diese Möglichkeit schon per ASTK >> Export File?
Hier verstehe ich dein Problem nicht...das ist natuerlich moeglich.MGolbs wrote: # Ich würde für eine tansiente Analyse verschiedene Kraft-Zeitfunktionen zur gleichen Analyse nutzen wollen. An unterschiedlichen Knoten greifen also speziell definierte Kraft-Zeitfunktionen an.
MGolbs wrote: # Ich würde gern nach einer Anzahl von Zeitschritten ein Postprozessing (besser die Frage Daten behalten oder verwerfen) von speziell ausgewählten Ergebnissen durchführen (z.B. maximale Verschiebung). Dafür würde ich tmp.ASCI Daten schreiben und für die Bewertung nutzen....
# derzeit stelle ich mir das so vor:
- Schleifenabbildung in Shell/bash (der eigentlich Start der gesamten Berechnung erfolgt mit einem Shell Skript), das mache ich jetzt auch schon so.
- Code-Aster weiterrechnen auf Basis von erzeugtem Datenbestand - POURSUITE Ansatz
- die Bewertung ob Daten behalten oder verworfen werden erfolgt in eigenen Programmen (meist ANSI-C) die über Shell Skript bedient werden.
- Die Frage ob Code-Aster in dieser Zeit weiterrechnen kann oder soll (POURSUITE Ansatz ja oder nein) müsste diskutiert werden.
Falls du DYNA_NON_LINE verwendest gibt es den Befehl OBSERVATION, der ist genau dafuer gedacht. Bei DYNA_LINE_TRAN kommst du wohl nicht um eine Python schleife herum.
Hier ein kleines Code-Snippet das die prinzipielle Vorhegensweise verdeutlicht:
#preprocessing
...........
T_LIST=DEFI_LIST_REEL(DEBUT=0.0,
INTERVALLE=(...);
#solution
for i in range(len(T_LIST.Valeurs())):
if i == 0 :
SOL=DYNA_LINE_TRAN(...
INCREMENT=_F(LIST_INST=T_LIST,
INST_FIN=T_LIST.Valeurs()[1]),
...);
#post process results for first time step here
.........
else:
SOL=DYNA_LINE_TRAN(reuse=SOL,
ETAT_INIT=_F(RESULTAT=SOL,),
....
INCREMENT=_F(LIST_INST=LIST_IN1,
INST_FIN=LIST_IC1.Valeurs()[i+1]),
....);
#post process results for consecutive times step here
.........Ja das ist moeglich und bei dem oben beschriebenen Vorgehen notwendig. Falls du im #postprocessing Teil Daten herausschreibst (beispielsweise in einem IMPR_RESU/IMPR_TABLE nach UNITE=30) findest du im temp Verzeichnis die Datei fort.30 welche die tenmporaeren Dateien enthaelt.MGolbs wrote: # kann man während eines Code-Aster Rechenlaufs auf die Daten in (R base /Phad/.. RC 0) zugreifen, diese im Rechenlauf schon reduzieren/verwerfen?
Kommt drauf an...MGolbs wrote: Ich bin mir sicher, dass dies einige Zeit dauern wird bevor so etwas lauffähig funktioniert.
Viel spass beim tuefteln!
Gruss,
Richard
SimScale - Engineering Simulation in your browser!