---

Hallo Spezis,

hat schon jemand Erfahrung mit einer GRID Anbindung an Teamcenter gesammelt?

Ich möchte folgendes Aufbauen:
- Um den zentralen Server nicht zu belasten, sollen rechenintensive CAx Jobs auf nicht aktiven NX CAx Maschinen ausgelagert werden.
- Beispiel Jobs sind Rendering von Bildern, MKS FEM CFD Simulationen, CAD Modell- und Zeichnungsaktualisierungen
- Initiierung der Jobs durch das Teamcenter Workflow System
- Übergabe der Jobs in das GRID durch den Create Image Server

Hierzu habe ich verschiedene GRID Systeme getestet: ALCHEMI, UNICORE und CONDOR.

Mit CONDOR lassen sich gezielt IDLE (unbenutze) Maschinen ansteuern. Per CMD Befehle kann ich schon solche Jobs auf GRID Maschinen verteilen und ausführen lassen. Was noch fehlt ist die Anbindung an Teamcenter mittel dem Create Image Server auf PERL Basis.

Hat Jemand schon ähnliche Systemumgebungen aufgebaut bzw. hat Erfahrungen mit dem Create Image Server oder dem CONDOR GRID System bzw. dessen PERL Modul?

Ich wäre an einem Erfahrungsaustausch interressiert.

Gruß

Matthias Ahrens

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

---

Hallo MAhrens

wir bekommen im Sommer einen neuen Server auf dem wir mehrere Virtuelle Maschinen drauf haben werden. Auf den Virtuellen Maschien laufen dan die Workflows & Create Image Dienste....

Wieso einfach wenns kompliziert auch geht ?

grüsse
mäd mäx

------------------
Wer glaubt etwas zu sein, hat aufgehört etwas zu tun !
und .... Ein Kreis ist ein rundes Quadrat.

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

---

Hallo Mäd Mäx,

warum?

Weil auch virtuelle Server nicht CPU Ressourcen aus dem Nichts abgreifen könne. Wir haben zum Beispiel unsere Testinstanz auf einer virtuellen Maschine auf dem Produktiv - Host laufen. Sobald ich CPU - intensive Aktionen auf der VM starte fährt natürlich der bereitstellend Host auch in eine Last Situation rein.

Genau aus diesem Grunde möchte ich CPU - intensive Aufgaben komplett auf andere Rechner, die in dem Moment nicht genutzt werden, auslagern. Speziell numerische Simulationen wie CFD, FEM und MKS als auch Visualisierungsaufgaben (Rendern von einzelnen Bilder oder von Filmen bzw. Animationen) benötigen viel Ressourcen.

Daher soll der zentrale Server solche Jobs, die über das Teamcenter Workflow System und den Create Image Server erhält, an die inaktiven Rechner im GRID - Verbund verteilen. Nachdem diese die Rechenarbeit geleistet haben, sollen die Ergebnisse zu demzentralen Server zurückgespielt werden. Dieser bindet diese dann wieder in die Teamcenter Datenbank ein.

Im Batch - Betrieb (Ohne Trigger durch einen Workflow und Create Image Server) funktioniert das mit CONDOR schon ganz gut. So habe ich einen Render Job und einen Nastran FEM Job schon im GRID verteilen können. Die jeweiligen CONDOR Executoren (inaktive Client Computer) haben dann eine verdeckte Teamcenter und NX Sitzung gestartet. Sie haben die benötigten Daten aus der Datenbank extrahiert und die Berechnungen durchgeführt. Nach Abarbeitung wurden die Ergebnissdateien (Bild und FEM Ergebnisdatei) wieder in das CONDOR Ausgangsverzeichnis auf dem zentralen Server zurück übertragen.

Gruß

Matthias

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

---

110307_MA_EN_CONDOR_as_Teamcenter_Job_Queue_Management.pdf

Hallo Teamcenter Spezialisten,

aufgrund fehlernder Flexibilität im Teamcenter Standard Job Queue Management System TSTK habe ich das Thema "CONDOR unter Teamcenter" neu aufgenommen und in unserer Teamcenter 8.3 Umgebung realisiert. Neben der PDF Übersicht im Anhang anbei eine kurze Zusammenfassung:

1. PLMXML - Closure Rule definieren, damit die benötigten Objekt Informationen der Workflow - Targets und Workflow - Refeferenzen exportiert werden können.
2. Im Workflow wird zuerst der EPM-export-to-plmxml Action Handler mit der definierten Closure Rule als -context Argument verwendet. Da das Argument -file nicht verwendet wird, wird jetzt eine entsprechende PLMXML Datei mit einem Dateinamen, der gleich dem Jobnamen ist exportiert.
3. Nach dem EPM-export-to-plmxml Action Handler wird der invoke_system_action Handler verwendet mit einem angepassten PERL Skript als Argument. Dieser schreibt nun die Workflow Details inklusive der Target und Referenz Tags in eine weiter XML Datei und ruft anschließend ein PERL Skript auf. Dieses PERL Skript kopiert nun diese beiden XML Dateien in eine spezilles Verzeichnis und ruft ein VBScript auf.
4. In dem VBScript steckt nun die meiste Programmlogik. So werden dort je nach Job Argument verschiedene Daten aus den beiden XML Dateien per XML Parser extrahiert. Anschließend werden Batch Dateien und Condor Submit Dateien geschrieben. Da zum Teil mehrere Condor Jobs Abhängigkeiten besitzen, verwendet das System den CONDOR DAG Mechanismus. So werden zum Beispiel Render Aufgaben auf angeschlossene 4Tier Clients ausgelagert, während der Datei - upload und das Workflow Signoff auf dem 2Tier Server erfolgt.

Der Vorteil in der Condor Lösung liegt darin, dass jeder Job als auch jeder angeschlossene Client mit verschiedenen Attributen belegt werden kann. Auch lassen sich im Condor die Jobs mit unterschiedlichen Prioritäten belegen. Durch geschickte Auswahl der Client Attribute kann man so zum Beispiel festlegen, dass bestimmte Job Typen vorzugweise nur auf betsimmten Condor Clients ausgeführt werden. Auch lassen sich inaktive (IDLE) Anwender - Workstations in den Condor Pool einbinden.

Gruß

Matthias

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