[Basstler]

Tach Gemeinde,

wie wäre es wenn wir probieren per Skripting LTSpice für massive Multiruns zu automatisieren ?!
[D]E_Tob[/D] Black_Chicken hat es ja schon angedeutet, mittels Python sollte es ein Leichtes sein die größtenteils in ASCII vorliegenden LTSpice Dateien, zum Einem automatisch abzugrasen (.measure Werte aus dem Log zum Beispiel).

Oder auch umgekehrt .asc Dateien zu modifizieren um zB. einfache Simulationen, welche die CPU eh nicht wirklich beladen, für Multiruns in mehrere Instanzen zu starten.
Jede Instanz bekommt einen Teilbereich vom Multirun, das in Summe alle Instanzen den vollen Bereich abfahren - halt parallel !

Händisch läuft das bei mir bisher so, die Schaltung steht und es sind .step und .measure Parameter angegeben.
Dann vervielfache ich die .asc und verpasse ihnen ne Nummer (die Instanz).
Per Notepad++ Teile ich dann gleichmäßig die .steps auf die Instanzen, anschließend die benötigte Anzahl an LTSpice Instanzen öffnen, .asc rein gekippt und alle starten.
Wobei man das natürlich eleganter über ne Commandline lösen kann (sollte, bin faul ).

Idealvorstellung wäre ein Skriptbaukasten, der einem nach der .asc fragt, den .step Parameter und die Anzahl der Runs und Instanzen, dann Enter und die LTSpice Armee rennt los
Am Ende werden die Werte samt zugehörigen Step zusammen gesammelt und in eine CSV Datei verklappt, zwecks weiterverwursten.

Mein Problem, habe noch nichts mit Python gemacht ... wird wohl mal Zeit

Und, bin ich der [D]einzigste[/D] einzige der sowas braucht ?

[E_Tobi]

Black_Chicken wars ^^

Werden mehrere Instanzen beim .step deutlich schneller als eine?

Ich kenns nur so dass die Simu so lange quasi keine Wartezeit verursachen bis alle CPU-Kerne voll sind....erst dann wirds langwierig...aber dann bringen mehrere Instanzen ja auch nix mehr...

[Basstler]

Upps, habs geändert, Danke.

Naja, es kommt halt auf die Schaltung an, derzeit spiele ich mit einem rudimentären LLC Wandler.
Ansteuerung mit PULS Spannungsquelle an den Gates, open loop.
Einzig etwas komplexer sind die 'echten Fets' und die Bekannten parasitären Parameter des Übertragers.
Lasse ich das durchlaufen, merkt die CPU da fast nix von, aber es dauert, ist wohl mehr mit dem erstellen der Matrizen beschäftigt, als mit der eigentlichen Mathematik.

Will man nun Parameter durchrödeln, um zB. ne Kennlinie zu erstellen (bei mir Gain vs. Frequenz vs. Laständerung), gibt das nen haufen Runs - derzeit 4160

Seriell würde das dann 4160x 2 Minuten dauern.
Jetzt mit 8 Instanzen sind es 520x 2 Minuten und die CPU ist immerhin zu 50-60% ausgelastet, da wäre noch Spielraum für min. 4 weitere Instanzen ...

[Black_Chicken]

also in deiner multi-instanzierung bin ich noch nicht so ganz angekommen...klar ist du willst das ganze nach möglichkeit in einen möglichst breiten Baum auffächern und parallelisieren. Was ich anbieten kann ist Dir ein Minimalbeispiel für das starten der .asc und auslesen der .log zu erstellen. Dafür müsstest Du mir ein minimalbeispiel deiner .asc mit 1 step zur verfügung stellen

Das ganze läuft übrigens auf Windows etwas besser als auf Linux - ltspice ist halt eigentlich ein windows-native

> python27 ist kein hexenwerk, sofern du irgendeine scriptsprache wie octave/matlab/perl oä beherrschst wirst du dich recht fix zurechfinden. Für windows empfehle ich übrigens das anaconda-paket.

[Basstler]

Was ich da mache kommt später in einem anderem Thread.... also die .asc
Nen Startscript um die .asc ansich zu starten ist kein Hexenwerk

Es geht um das gesamt Paket, .asc angeben, die .steps welche parallelisiert werden sollen, Anzahl Instanzen angeben -> am ende kommt ne .BAT raus mit der dann LTSpice im Rudel los rennen kann - ideale Vorstellung

In Matlab arbeite ich mich auch grad ein, es nen Muss, hatte bisher aber noch nicht die Möglichkeit, sehe aber viele Möglichkeiten mit dem Ding.
Grade mit Simulink lässt sich da ne Menge machen

Klar, Scriptsprachen sind jetzt nicht so komplex, hatte aber auch da bisher wenig Berührungspunkte, keine Notwendigkeit.
Werde mich da mal nächste Woche mit nem Kollegen @Work zusammensetzen, der ist nen As in Python.
Denke irgendwann heute Nacht sollten die 8 Instanzen durch sein, dann habe ich auch gleich ein Datenpaket welches per Script zerlegt werden darf.

Ed:
Darum geht es ... viel im Gange, kaum Last

[Black_Chicken]

Is eigentlich kein Hexenwerk: alles in ASCII: .asc , .log usw...
#1 orginal .asc datei öffnen
#2 .step-string finden und modizfizieren und abspeichern (orginaldatei wieder schließen)
#3 #2 n-1 mal durchführen
#4 alle n simulationen anwerfen und warten [.bat brauchst nicht, du kannst aus python raus direkt befehle an das system weitergeben (import subprocess ...)]
#5 das ganze nochmal für die .log dateien -> strings suchen und daten in array speichern
#6 array als csv exportieren und freuen
#7 ggf. weitere Berechnungen durchführen (kann python auch recht performant)

Frag mal deinen Kollegen - der kriegt das sicher hin

Wenn Du Matlab zur Verfügung hast kannst Du den ganzen spaß auch damit druchexerzieren. Hat den Vorteil dass Du die .raw files direkt einlesen könntest (ltspice2matlab()) -Achtung könnte ne heftige Datenmenge werden!!

[Basstler]

Zitat:Original geschrieben von Black_Chicken
...
Wenn Du Matlab zur Verfügung hast kannst Du den ganzen spaß auch damit druchexerzieren. Hat den Vorteil dass Du die .raw files direkt einlesen könntest (ltspice2matlab()) -Achtung könnte ne heftige Datenmenge werden!!

Interessanter Ansatz

Lasse aber zur Datenreduzierung nicht alles abspeichern, das habe ich schon durch...
5ms Simu mit allem und 20 Steps in der Frequenz waren am Ende 10GB raw und ne unhandliche 2,5GB ASCII Datei mit genau einem Step
Jetzt hole ich mir den Wert zu genau einem Zeitpunkt, langt auch erstmal...

[Black_Chicken]

ja wozu hat man denn 16 cores

Mit meinem x200si mit intel SU7300 wird das jedenfalls nix

[Basstler]

Das hatte ich am Donnerstag auch auf meinem Laptop gemacht, noch nicht uffen Rechenknecht zu hause, erwähne aber nicht was da drin steckt

BTW, kann mal Matlab 2014 in den Keller verklappen, hab da was.
Übrings auch der Grund warum ich mit nem privaten Laptop in der Firma arbeite - die sind zu geizig Matlab anzuschaffen
Kann das als Invest anmelden, aber ob das vor meiner Rente was wird, ist ungewiss.
Es scheitert derzeit schon an neuen PCs für die Hardwareentwicklung, hab da nen 6 Jahre alten I5 - der ist deutlich langsamer als mein Laptop

Nicht das das Budget generell nicht da wäre, unser neuer Abteilungsleiter hat nur schiss vor dem HAbteilungsleiter und kann unsere Anforderungen nicht durchsetzen - ganz traurige Nummer

[Black_Chicken]

Ja, das ist einer DER Gründe warum ich inzwischen komplett auf python umgeschwenkt bin. Kostet nischt, gibts für alle Plattformen, also portabel, die Doku ist ausreichend und es wird ständig weiterentwickelt. Was es nicht wirklich gibt sind fertige toolboxen für jeden schiet... aber ne große community!

Edit:
Was mir daran noch gefällt: Alles was ich mir mit freier Software erarbeitet habe ist eine Investition in die Zukunft (meine zukunft)! (Nehme man an ich bekomm von Arbeitgeber A ne Matlablizenz ->tolle Lösungen alles fein! Beim Wechsel zum Arbeitgeber B oder zu Hause kann ich dass dann aber alles in die Tonne kippen weil: lizenz sackteuer und proprietär, gauner-lösungen mal außen vor gelassen is ja auch nix für die Ewigkeit.)

[Basstler]

Richtiger Ansatz !
Soweit möglich, sehe ich auch zu, nicht von unbezahlbaren Tools abhängig zu sein.

LTSpice ist das beste Beispiel - auch wenn es nicht alle Komfortfunktionen wie andere Pakete liefert, aber es ist für Lau, sehr leistungsfähig und mit bissel Hilfe (so ein Skript wie hier) auch zu mehr in der Lage ...
Bei IDEs für MCUs bin ich inzwischen auch zickig, wenn man erstmal für x k€ Keil oder ähnliches anschaffen muss.
Inzwischen raffen es aber die Meisten, das Eclipse und GCC für Lau ein guter Weg seien kann.

[voltwide]

LTspice steht und fällt mit den benutzten Bibliotheken. Über die Jahre habe ich so Einiges aufgelesen, einige Perlen darunter, die ich aber im Ernstfall nie wiederfinden würde. Und natürlich vieles davon doppelt und 3-fach. Es geht darum, die bereits vorhandenen Standardbibliotheken anzureichern mit externen Daten ohne dabei den Überblick zu verlieren. Dazu folgender Plan:

Libs und hinzuzufügende Teile werden formatiert, so dass jedes .model statement eine einzelne Zeile belegt und Kommentare werden gelöscht. Dies erledigt folgendes shell-script:

Code:

#! /bin/bash
strip_lf() {
  echo "remove comments & create 1-line model spice statements, ignore case"
  sed '/\*/d' "${1}" | tr -d "\n" | tr -d "\r" | sed 's/+\x20*/\x20/g;s/.model/\n.model/gI' > temp
  rm "${1}"
  mv temp "${1}"
}

if [ $# -eq 1 ]; then                  
  if [ ! -f "$1" ]; then
    echo
    echo "ERROR: file does not exist - aborting program"
    echo                     
  else
    strip_lf "${1}"
  fi
else        
  echo                
  echo "ERROR: missing file argument - aborting program"
  echo
fi

Mehrere umgearbeitete Teilbibliotheken können mit einem Texteditor aneinandergehängt ("gemerged") und dann in ein Tabellenprogramm als CSV-Datei importiert werden.
Jedes Modell belegt hier eine genau 1 Zeile, nun kann man alphabetisch sortieren lassen.
Anschließend als *.CSV exportieren.
Fertig ist die neue Gesamt-Lib.
Dank der alphabetischen Sortierung können etwaige Dubletten leicht händisch entfernt werden.

Hat hier mit der standard.bjt unter libre office / linux bereits bestens geklappt.