@UEBER = Probleme mit PC oder Workstation? Rent-a-HiWi! @UEBER LINIEN = Neuer Vor-Ort-Service des RZ für PC- und Workstation-Nutzer Rent-a-HiWi! - <%-2>unter diesem Schlagwort bietet das RZ seinen Kunden eine neue, zusätzliche Serviceleistung an. Ab sofort können Sie bei uns qualifizierte wissenschaftliche Hilfskräfte anfordern, wenn Sie Probleme mit Ihrem PC oder Ihrer Workstation haben und einfach nicht mehr weiter wissen.<%0> Fragen wie "ich krieg' das Netzwerk nicht zum Laufen, was mach' ich falsch?" oder "welche Software brauche ich, um ans Netz zu kommen?" tauchen immer häufiger auf. Eine telefonische oder auch persönliche Beratung im RZ reicht da oft nicht aus, da die Lösung des Problems häufig von vielen Faktoren physikalischer und logischer Art abhängt, und nur ein versierter Experte vor <%-2>Ort die richtigen Entscheidungen und Maßnahmen treffen kann.<%0> Mit der zunehmenden Vernetzung hat sich diese Problematik nun noch verschärft. Auch Probleme mit der Installation von Betriebssystemen und Anwendungspakteten sind meist konfigurationsbedingt und können nur vor Ort schnell erkannt werden. Bisher hat sich das RZ in diesen Fällen auf das umfassende Beratungsangebot der Mitarbeiter/innen, der Programmierberatung und von Micro-BIT gestützt. Hausbesuche von Mitarbeiter/innen und wissenschaftlichen Hilfskräften waren eher die Ausnahme. An dieser Stelle möchten wir nun unseren Service erweitern und gezielt zu einem von jedem(r) Institutsmitarbeiter/in abrufbaren Vor-Ort-Service übergehen. Für diesen Service wird pro Stunde eine Gebühr in Höhe des Stundenlohnes einer wissenschaftlichen Hilfskraft von ca. 20.- DM in Rechnung gestellt. Diese Dienstleistung ist hauptsächlich für PC- und Workstation-Nutzer gedacht, die Probleme mit der Installation von <%-2>Hard- und Software oder bei Netzwerkeinbindungen haben. Soweit möglich werden auch Fehlerbehebungen vorgenommen. Angefordert werden können die Fachkräfte über den WWW-Server des RZ http://www.uni-karlsruhe. de/Uni/RZ/Dienste/HiwiRent/,<%-5> per Telefon -2067 oder 9661230, via mail an microbit@rz.uni-karlsruhe.de. Entsprechende Angaben, die wir zur Auswahl der richtigen Person und Terminvereinbarung benötigen, sind in ein bereitgestelltes Formular einzutragen bzw. werden abgefragt. Unser Tip: beim nächsten Problem versuchen Sie es doch einmal mit uns! @AUTOR FUNKTIN = Dieter Oberle @UEBER = Umrüstung des Vektorrechners SNI S600/20 Wie in der Benutzerversammlung am 27.6.1995 bereits angekündigt wurde, ist das Rechenzentrum wegen der gestiegenen Wartungskosten gezwungen, die Prozessoren des Vektorrechners SNI S600/20 zum Jahresende durch neue Prozessoren zu ersetzen. Die neuen Prozessoren sind wegen der Realisierung in CMOS-Technologie in den Betriebskosten deutlich niedriger als die alten Prozessoren, so daß trotz höherer Rechenleistung niedrigere Betriebskosten anfallen. Nach dem derzeitigen Stand der Planung ist die Anlieferung für Dezember 1995 vorgesehen. Nach der Installation des Betriebssystems und der Einrichtung der lokalen Betriebsumgebung können die Anwenderprogramme portiert werden. Bis Ende Februar 1996 sollten diese Arbeiten abgeschlossen sein, da die Lauffähigkeit der bisherigen Codes nur bis Ende Februar gewährleistet werden kann. Für August 1996 ist eine weitere Reduzierung der Zykluszeiten vorgesehen. Der Rechner in seiner neuen Konfiguration stellt sich dar als Vektorprozessorsystem, das 4 Processingelemente (PE) umfaßt. Die Architektur der einzelnen PEs ist der Architektur der bisherigen Prozessoren sehr ähnlich, so daß optimierte Programme auch weiterhin mit hoher Effizienz laufen werden. Jedes PE ist mit einem Hauptspeicher von 2 GB, einer Skalareinheit (SU) und einer Vektoreinheit (VU) ausgestattet. Die SU arbeitet nach dem RISC- Prinzip, <%-3>so daß mehrere Instruktionen parallel abgearbeitet werden<%0> können, was zu einer maximalen Instruktionsrate von 300 bzw. 400 MIPS führt. Die VU beinhaltet je eine Load-, Store-, Add/Logical-, Multiply- und Divide-Pipeline, zwei Mask-Piplines sowie dynamisch <%-2>konfigurierbare Vektorregister von insgesamt 128 KByte<%0> Größe mit dazu passenden Maskenregistern. Die Spitzenleistung einer VU beträgt 1,6 bzw. 2,2 GFLOPS, so daß die Gesamtleistung mit 6,4 bzw. 8,8 GFLOPS deutlich über der bisherigen Leistung von 5 GFLOPS liegt. Die interne Zahldarstellung entspricht dem IEEE 754 floating point standard während die Daten bisher im sog. IBM-Format gespeichert wurden. Ein Austausch von Binärdaten mit Workstations ist deshalb problemloser möglich. Mit der Umrüstung der Hardware geht eine Neuinstallation der Software einher. Das neue Betriebssystem UXP/V ist eine Weiterentwicklung des bisherigen Betriebssystems UXP/M. Vektorisierende Compiler <%-2>stehen für Fortran 90 und C zur Verfügung, die Source-Code-kompatibe<%0>l zu dem bisherigen Fortran 77- bzw. C-Compiler sind. Das Rechenzentrum wird die <%-3>Unterprogrammbibliotheken BLAS, LAPACK, FIDSOL/ CADSOL, VECFEM, LAPACK, RAND/VP<%0> und FFT/VP bereitstellen. Außerdem ist davon auszugehen, daß eine Version der NAG-Library verfügbar sein wird. Die IMSL-Bibliothek wird wegen der geringen Nutzung nicht weiter unterstützt werden. Die Finite-<%-4>Elemente-Programme ABAQUS, FIDAP und NASTRAN<%0> können zunächst noch nicht unter UXP/V angeboten werden. Das Rechenzentrum bemüht sich jedoch, vergleichbare Compute-Server für diese Pakete bereitzustellen. Entsprechende Freigabeanträge sind beim Ministerium gestellt. Um Anwendungsprogramme zu portieren, ist i.a. nur eine Neuübersetzung notwendig, wobei jedoch Maschinenkonstanten, die von der internen Zahldarstellung abhängen, anzupassen sind. Binärdaten (z.B. Restart-Files) müssen in die IEEE-Zahldarstellung gewandelt werden, was mit entsprechenden Laufzeitoptionen beim Schreiben bzw. Lesen der Daten möglich ist. Ob bei der Übertragung von Binärdaten Probleme zu erwarten sind, kann schon jetzt überprüft werden, indem die Daten auf einer Workstation eingelesen werden. @BODY VORN = Bei weiteren Fragen wenden Sie sich bitte @BODY VORN = <%-2>an Herrn N. Geers (Tel. 608-3755, e-mail: geers@rz.uni-karlsruhe.de) <%0>oder @BODY VORN = <%-4>an Herrn P. Schroth (Tel. 608-3752, e-mail: schroth@rz.uni-karlsruhe.de<%0>). @AUTOR FUNKTIN = N. Geers @UEBER = Glasfaserverbindung zur Westhochschule und zur Fachhochschule in Betrieb Seit dem 18. September 1995 ist die neuinstallierte Glasfaserverbindung in die Westhochschule in Betrieb, die Laserstrecke wurde abgeschaltet. Damit ist die Anbindung des Westcampus an das übrige Netz der Universität (nun) ebenso stabil wie Verbindungen innerhalb des Ostcampus. <%-2>Die Strecke zur Westhochschule hat eine maximale Bandbreite von 10 Mbit/s und ist in Form eines Ethernetsegments realisiert. Die Auslastung der Verbindung (in der Vergangenheit ungefähr 1 Mbit/s) muß natürlich noch beobachtet werden. Sollte es zu Engpässen kommen, kann die Glasfaserstrecke (unter Einsatz neuer aktiver Netzkomponenten auf beiden Seiten) auch mit erheblich höheren Geschwindigkeiten genutzt werden.<%0> In Kürze wird auch die Verbindung zur Fachhochschule (64kbit/s) auf Glasfaser umgeschaltet. Danach steht hier ebenfalls eine Bandbreite von 10 Mbit/s zur Verfügung. @BODY VORN = Reinhard Strebler, Tel. -2068 e-mail: Strebler@rz.uni-karlsruhe.de. @2 ZEILER = Reinhard Strebler @UEBER = WWW-Zwischenspeicher: Der Proxy/Cache @BODY FETT = Das Wachstum Netzes Das World Wide Web ist ein ständig wachsendes Netz, und noch scheint es so, als seien dem Wachstum keine Grenzen gesetzt. Kein Internetdienst zuvor hat je einen solchen Boom erlebt. Seit der Veröffentlichung von Mosaic Ende 1993 scheint die Zahl der WWW-Server ins Unermeßliche zu steigen. Mit der wachsenden Zahl der WWW-Server steigt auch die Menge der angebotenen Informationen, und, was noch entscheidender ist, die Menge der übertragenen Informationen, die durch die wachsende Akzeptanz (und die steigenden Anwendungsmöglichkeiten) des World Wide Web als Informationsmedium noch zusätzlichen Vorschub erfährt. Das World Wide Web hat sich inzwischen als der weltweit populärste Dienst im Internet etabliert und sogar FTP überflügelt. @BODY VORN = Das Dilemma der begrenzten Kapazitäten Die Außenleitungen der Universität sind in ihrer Kapazität beschränkt, ein noch entscheidenderer Flaschenhals ist die USA-Anbindung des DFN, die auch <%-2>bei einigen "innerdeutschen" Verbindungen in Anspruch<%0> genommen werden muß. Da dies dazu führt, daß man tagsüber manchmal überhaupt nicht mehr "in die große weite Welt" hinauskommt, gilt es, den Verkehr über diese Leitungen auf das Notwendigste zu beschränken. Eine Möglichkeit der Beschränkung (und sicher die am wenigsten restriktive) ist die Vermeidung der Übertragung redundanter Information, wie dies im World Wide Web oft gegeben ist, wenn viele Leute sich die gleichen Seiten anschauen. Ziel ist also, jede Seite nur einmal über die Außenleitungen zu übertragen und danach lokal zu halten und geeignet im Campus zu verteilen. @BODY VORN = Der WWW-Proxy als Stellvertreter Um die Anfragen nach WWW-Seiten entsprechend zu koordinieren, ist es notwendig, diese über einen zentralen Rechner der Universität laufen zu lassen. Im World Wide Web ist ein solcher Mechanismus bereits vorgesehen: Ein Proxy kann HTTP-Anfragen (also das "eigentliche" WWW-Protokoll) an andere WWW-Server weiterleiten, er kann aber auch andere Protokolle wie FTP, <%-2>Gopher oder WAIS umsetzen und damit den Zugriff auf diese Protokollwelten auch für Browser ermöglichen, die diese Protokolle selber nicht unte<%0>rstützen. @BODY VORN = Der WWW-Proxy als Cache Die Funktionalität des WWW-Proxys läßt sich nun, dem Ziel der Lastvermeidung entsprechend, dahingehend erweitern, daß alle Dokumente, die den Proxy passieren, auf einer lokalen Platte (Cache) zwischengespeichert werden. Kommt nun eine zweite (dritte, etc.) Anfrage für dasselbe Dokument, kann der Proxy dieses sofort aus dem Cache liefern, ohne den entfernten Rechner erneut kontaktieren zu müssen. Auf dem zentralen WWW-Server der Universität www.uni-karlsruhe.de ist ein solcher als Cache konfigurierter Proxy installiert; zum Zwischenspeichern von Dokumenten verfügt er über 2 GByte Plattenplatz. @BODY VORN = Cache-Mechanismen Natürlich verbleiben die Dokumente nicht für immer im Cache; zum einen würde ihn dies zum Überlaufen bringen, zum anderen wären die Dokumente irgendwann nicht mehr aktuell. Deshalb wird jede Nacht ein "Expire" durchgeführt, das veraltete Dokumente aus dem Cache löscht. Die Zeit, in der ein Dokument veraltet, wird dabei dynamisch festgelegt. Bei Dokumenten, die über HTTP verteilt werden, kann explizit vom Autor des Dokumentes angegeben werden, wie lange es im Cache verbleiben soll; ist eine solche Verweildauer nicht angegeben, wird vom Proxy 10% der Zeit seit der letzten Änderung als Verweilzeit angenommen. So verbleiben Dokumente, die sich selten ändern, lange im Cache und helfen effektiv, die Netzlast zu verringern, während sich oft ändernde Dokumente häufig auf ihre Aktualität hin überprüft werden. <%-2>FTP- und Gopher-Dokumente, die weder explizite noch implizite Verweildauerangaben ermöglichen,<%0> werden z.Zt. für eine Woche gehalten, FTP-Verzeichnisinhalte für einen Tag. Suchanfragen, also dynamisch erzeugte Dokumente, werden gar nicht gecacht. @BODY VORN = Benutzung des Proxy/Caches Der vom RZ installierte Proxy kann HTTP-, FTP-, Gopher- und WAIS-Anfragen weiterleiten; dies ist aber nur für Anfragen außerhalb der Universität sinnvoll. Um den Proxy zu benutzen und damit in den Genuß der schnelleren Antwortzeiten dank Cache zu kommen, muß der Browser so eingestellt werden, daß er den Proxy zum gegebenen Zeitpunkt richtig anspricht. Die Einstellungen unterscheiden sich je nach Betriebssystem und Browser. @BODY VORN = UNIX/X11 Die meisten Browser unter UNIX (wie Mosaic, Arena oder lynx) lassen sich auf die gleiche Art und Weise konfigurieren. Man setzt die Environment-Variablen http_proxy, ftp_proxy, gopher_proxy und wais_proxy auf http://www.uni-karlsruhe.de/ (der / am Ende ist wichtig!). Zusätzlich ist die Variable no_proxy auf uni-karlsruhe.de,uka.de einzustellen; hiermit wird die Liste der Domains spezifiziert, für die der Proxy nicht konsultiert werden soll. Als Benutzer der Korn- oder Z-Shell oder der Bash kann man z.B. folgendes in sein .profile eintragen: @BODY VORN = export http_proxy=http://www.uni-karlsruhe.de/ @BODY VORN = export ftp_proxy=http://www.uni-karlsruhe.de/ @BODY VORN = export gopher_proxy=http://www.uni-karlsruhe.de/ @BODY VORN = export wais_proxy=http://www.uni-karlsruhe.de/ Wer die C- oder TC-Shell benutzt, trägt folgendes in sein .login ein: @BODY VORN = setenv http_proxy http://www.uni-karlsruhe.de/ @BODY VORN = setenv ftp_proxy http://www.uni-karlsruhe.de/ @BODY VORN = setenv gopher_proxy http://www.uni-karlsruhe.de/ @BODY VORN = setenv wais_proxy http://www.uni-karlsruhe.de/ <%-2>Auf den vom RZ installierten Workstations sind diese Einstellungen bereits im System eingetragen und müssen nicht vom einzelnen Benutzer vorgenommen werden. Wenn man überprüfen will, ob der Proxy verwendet wird, kann man echo $http_proxy eingeben; wenn diese Variable gesetzt ist, wird der Proxy angesprochen. Netscape übernimmt zwar beim ersten Aufruf die Werte aus diesen Variablen, erkennt nachträgliche Änderungen aber nicht mehr. Hier müssen die entsprechenden Eintragungen in den Preferences erfolgen. Die Eintragung erfolgt nicht wie bei den Variablen als URL, sondern getrennt nach Host und Port, hier muß www.uni-karlsruhe.de bzw. 80 eingesetzt werden.<%0> @AUTOR FUNKTIN = Andreas Ley @UEBER = Für WWW-Einsteiger: HTML-Kurzanleitung @BODY VORN = Was ist eigentlich HTML? HTML heißt HyperText Markup Language, ist also eine Sprache, um Hypertexte mit Markierungen zu versehen. (Genaugenommen ist HTML ein SGML-DocumentType.) HyperText ist einfach normaler Text (für Informatiker: Knoten), der Verbindungen (für Informatiker: Kanten) zu anderen Dokumenten hat. So entsteht ein richtiges Netz (für Informatiker: Graph) von Dokumenten, das sich World Wide Web nennt. Diesen Verbindungen kann man durch einfaches Auswählen nachgehen. @BODY VORN = Wie sieht HTML aus? HTML sieht zuerst einmal wie ganz normaler Text aus. Und das ist es eigentlich auch. Nur daß dazwischen spezielle Zeichenketten auftauchen, die die HTML-Befehle darstellen. HTML-Befehle werden auch als Tags bezeichnet. Ein Tag fängt immer mit einem Kleinerzeichen (<<) an, dann kommt der Name des Tags und zum Abschluß ein Größerzeichen (>>), also etwa so: <<NAME>>. Es gibt Tags, die mitten im Text auftauchen (sie werden als leere Tags bezeichnet) und andere, die einen Teil des Textes umschließen. Dazu gibt es neben dem schon beschriebenen Opening Tag noch einen Closing Tag, der sich von ersterem nur durch einen Slash ( /) vor dem Namen unterscheidet: <</NAME>>. Außerdem gibt es noch Tags, die Attribute haben, mit denen man das Verhalten der Tags beeinflußen kann. Solche Attribute stehen zwischen dem Namen und dem Größerzeichen und werden durch Leerzeichen voneinander getrennt. Manche Attribute haben zusätzlich noch einen Wert, dieser wird dann mit einem Gleichheitszeichen an das Attribut angehängt. Enthält der Wert selbst Leerzeichen, sollte man ihn in Anführungszeichen einschließen: <<NAME ATTR="Wert">>. @BODY VORN = Ein ganz komplizierter Tag würde also so aussehen: <<NAME ATTR1 ATTR2="Wert">> Irgendwelcher Text <</NAME>> Da HTML als ASCII-Text definiert ist, dürfen auch keine Zeichen über 127 verwendet werden. Das heißt zunächst auch erst einmal, daß keine Umlaute direkt in den Text geschrieben werden dürfen. Um dennoch Umlaute und Sonderzeichen im Text unterzubringen, werden die sogenannten Entities verwendet, die eine Umschreibung für Umlaute sind. Achtung SGML-Freaks: Entities sind eigentlich SGML-Makros, können aber nicht als solche verwendet werden, da die Browser keinen SGML-Parser haben, sondern nur bestimmte vordefinierte Entities. Entities fangen mit einem Ampersand (&) an, dann folgt der Name der Entity, abgeschlossen mit einem Semikolon (;). Der Ampersand selber hat dann natürlich auch ein eigenes Entity; ebenso braucht man für <%-2>das Größer- und das Kleinerzeichen auch eigene Entities.<%0> @BODY VORN = ä: ä ö: ö ü: ü ß: ß Ä: Ä Ö: Ö Ü: Ü &: & <<: < >>: > Auf den RZ-Workstations steht das Kommando htmlconv zur Verfügung, mit dem man in einem Dokument die ISO-Umlaute in HTML umwandeln kann. @BODY VORN = Der prinzipielle Aufbau eines Dokuments Bei HTML geht alles ganz hierarchisch zu. Das fängt damit an, daß man sich auf die entsprechende Document Type Definition bezieht (HTML ist ja ein SGML-Typ), wobei dann die erste Zeile eines Dokuments lautet: @BODY VORN = <%-2><<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">> Um ein HTML-Dokument jetzt als solches zu kennzeichnen, wird es zuallererst in einen <<HTML>>-Tag eingeschlossen. Das eigentliche Dokument gliedert sich dann in einen Header und einen Body. Der Header wird durch <<HEAD>>-Tags umschlossen; hier stehen allgemeine Informationen über das Dokument, aber nichts, was zu irgendeiner Ausgabe führt. Der Body ist der eigentliche Informationsträger, er wird durch <>-Tags begrenzt und enthält all das, was später zur Anzeige kommen soll. @BODY VORN = Ein typisches Dokument sollte also so aussehen: @BODY VORN = <> @BODY VORN = <> <> Header-Elemente <> <> Body-Elemente <> <> @BODY VORN = Auf den RZ-Workstations steht das Kommando newhtml zur Verfügung, mit dem ein leeres Dokument angelegt werden kann, das diesen Konventionen entspricht. @BODY VORN = Was im Header steht Im Header stehen Informationen über das Dokument, aber noch kein Inhalt, also nichts, was zu irgendeiner Ausgabe führt. Es handelt sich vielmehr um Meta-Informationen, die dem Browser etwas über das Dokument erzählen; wie es heißt, wer es gemacht hat und vieles mehr. Das wichtigste Element im Header ist der Titel des Dokuments, er wird mit <><F255P255> gekennzeichnet. Der Titel sollte ein Dokument auch außerhalb seines Kontextes kennzeichnen, er wird z. B. für die Anzeige in der <M>History, der <M>Hotlist oder als Ausgabe automatischer Suchoperationen im Netz benutzt. Er sollte, alleinstehend, eine Aussage über das Dokument treffen, anhand der man das Dokument identifizieren kann. Insbesondere sollte man Titel wie "Einführung" oder "Überblick" oder "Meine Homepage" vermeiden - das sind Überschriften! Ein weiteres wichtiges Element ist das <F102P10><<LINK>><F255P255>-Element, das für Verbindungen zwischen Dokumenten genutzt werden kann; Hauptaufgabe ist gegenwärtig die Kennzeichnung des Urhebers eines Dokuments. Dazu erhält der <F102P10><<LINK>><F255P255>-Tag ein Reverse-Relationship-Attribut (REV) mit dem Wert "made", es kennzeichnet also, wer das Dokument "gemacht" hat. Der Autor wird dann im <F102P10>HREF<F255P255>-Attribut aufgeführt, er wird durch eine <F102P10>mailto:-URL<F255P255> gekennzeichnet, die eine E-mail-Adresse enthält. Einige Browser sind aufgrund dieser Kennzeichnung bereits in der Lage, Kommentare direkt an den Autor zu schicken. Der Header ist mit <F102P10><<HEAD>><F255P255>-Tags geklammert. Ein typischer Header könnte also so aussehen: @BODY VORN = <F102P10><<HEAD>> <<TITLE>>Dokument-Titel<> <> <> @BODY VORN = Was im Body steht Im Body steht der Inhalt des Dokuments, also all das, was angezeigt werden soll. Dies kann zunächst einmal ganz normaler ASCII-Text sein. Dabei muß auf Zeilenumbrüche und Ähnliches nicht geachtet werden, dafür sorgt nämlich der Browser oder WWW-Client. Und da jeder Browser anders funktioniert, andere Zeichensätze oder Fenstergrößen hat, sollte man auch tunlichst vermeiden, irgendwelche Annahmen darüber zu treffen. Einfacher Fließtext kann aber nur begrenzt eine Aussage vermitteln. Deshalb gibt es in HTML zusätzliche Tags, mit denen man etwas über die Struktur und den Inhalt eines Dokuments aussagen kann. Diese Struktur wird dann vom Browser in ein Layout übertragen, das aber von Browser zu Browser unterschiedlich sein kann. Man sollte beim Schreiben eines HTML-Dokuments also immer darauf achten, daß es von unterschiedlichen Programmen ganz unterschiedlich dargestellt werden kann. Insbesondere Sätze wie "Klicken Sie mit der Maus auf die blau unterstrichenen Wörter" sind für Leser, die nur ein ASCII-Terminal haben und mit den Cursortasten fett geschriebene Wörter auswählen müssen, äußerst verwirrend. HTML-Tags dienen also nur einer semantischen Gliederung des Dokuments und geben dem Browser Hinweise über den Inhalt, die dieser dann in eine seinem Benutzer angenehme Darstellung übersetzt. @BODY VORN = Überschriften HTML stellt sechs verschiedene Level von Überschriften zur Verfügung, die mit den Tags H1 bis H6 markiert werden. Ein mit einer Überschrift versehener Text sähe also so aus: @BODY VORN = <

>Überschrift<

> @BODY VORN = Ganz ganz viel Text. @BODY VORN = @BODY VORN = Abschnitte und Umbrüche Ein einziger riesiger Text ist auch nicht sehr lesbar, deswegen läßt er sich in einzelne Abschnitte unterteilen. Dazu dient der <

>-Tag, der zwischen zwei Abschnitte gestellt wird und zwei Abschnitte voneinander trennt. Ganz viel Text.<

> Noch mehr Text. Anmerkung: Mit den neuen Versionen von HTML ändert sich die Benutzung des <

>-Tags dahingehend, daß er nun einen Abschnitt umschließt, statt zwei Abschnitte zu trennen. Leider beherrschen die gängigen Browser diese Verwendung noch nicht korrekt, so daß man sich noch an die alte Definition halten sollte. Abschnitte werden i. A. durch einen Abstand voneinander getrennt. Ab und an kann es notwendig sein, eine neue Zeile anzufangen, ohne einen Abstand zu erzeugen; für diesen Zeilenumbruch benutzt man den <
>-Tag. Er wird genau wie <

> verwendet. Eine deutlichere Trennung mehrerer unabhängiger Teile eines Dokuments kann man durch das Einsetzen einer horizontalen Linie erreichen. Sie wird mit dem <


>-Tag erzeugt und genau wie der <

>-Tag zwischen die zu trennenden Abschnitte gesetzt. Eine besondere Art des Abschnitts ist ein Zitat oder ein Beispiel. Hierzu dienen die <

>-Tags, die im Gegensatz zu den anderen nicht leer sind. Zitate und Beispiele werden oft eingerückt dargestellt. Ein Beispiel für ein Zitat: @BODY VORN = Einfacher Text <
> Zitierter Text <
> Weiterer Text Die Tags <

>, <
>, und <


> sollten nur dann verwendet werden, wenn ansonsten der Text zu einem Abschnitt zusammenfließen würde. Insbesondere sollten nicht mehrere aufeinander folgen, auch wenn manche Browser dies tolerieren; andere erzeugen damit fast leere Seiten. Ebenso brauchen vor oder nach anderen Tags, die ebenfalls eine Trennung des Textes bewirken (z. B. Überschriften), keine Abschnittstrenner zu stehen. @BODY VORN = Listen Manche Informationen lassen sich besser als eine Auflistung denn als fließender Text präsentieren. HTML bietet hierzu drei grundlegende Listentypen an. Der einfachste Typ ist die ungeordnete Liste, was jetzt aber nicht heißt, daß die Listenelemente wild durcheinander angezeigt werden; dies soll lediglich ausdrücken, daß die Liste keine definierte Abfolge darstellt. Eine solche Liste wird durch <
    >-Tags begrenzt, die einzelnen Listenelemente werden durch <
  • > eingeleitet: @BODY VORN = <
      > <
    • >Ein Eintrag @BODY VORN = <
    • >Noch ein Eintrag <
    > @BODY VORN = Für eine definierte Abfolge, wie sie z. B. in einer Gebrauchsanweisung auftaucht, steht die geordnete Liste zu Verfügung, wobei der Browser dafür sorgt, daß dies auch zum Ausdruck kommt (z. B. durch fortlaufende Nummern vor den Einträgen). Eine geordnete Liste funktioniert genau wie eine ungeordnete, nur ist jetzt <
      > statt <
        > zu verwenden. Der dritte Typ unterscheidet sich von den vorherigen dadurch, daß ein Eintrag aus zwei Teilen besteht: einem Eintrag und einer zugehörigen Beschreibung. Eine solche Liste läßt sich als Glossar u. ä. verwenden. Das Schlüsselwort wird dabei durch <
        > eingeleitet, die zugehörige Erklärung durch <
        >: @BODY VORN = <
        > <
        >Ein Eintrag <
        >und der zugehörige Text <
        >Ein anderer Eintrag <
        >und der dazugehörige Text <
        > @BODY VORN = Hervorhebungen und Stile Natürlich sind in HTML Texthervorhebungen möglich, sie sollten sich aber möglichst nur auf die Struktur beziehen. Dazu dienen die strukturellen Markierungen <> (Hervorhebung) und <> (Betonung). Zur Darstellung computerbezogener Daten eignet sich <>. Der Browser entscheidet selber, wie er welche Markierung anzeigt, üblich ist aber kursiv zur Hervorhebung und fett zur Betonung, so verfügbar. <>-Tags werden oft als nichtproportionaler Zeichensatz dargestellt. @BODY VORN = <>Hervorgehobener<> und <>betonter <> Text Neben den strukturellen Markierungen gibt es auch noch explizite Anweisungen für kursiven Text <>, fetten Text <>, unterstrichenen Text <> oder Schreibmaschinentext <>. Dies ist aber keine Garantie dafür, daß der Text dann auch wirklich so erscheint, da manche Browser ihn nicht wie gewünscht darstellen können! Man sollte daher nach Möglichkeit auf diese Markierungen verzichten und auf die strukturellen zurückgreifen. @BODY VORN = Vorformatierter Text Beim Übertragen fertiger ASCII-Dokumente nach HTML kommt es oft vor, daß man einen schön gesetzten Text wie z. B. eine Tabelle hat, die durch den automatischen Umbruch oder durch die proportionalen Zeichensätze zerstört werden würde. Für solche Fälle stehen die <
        >-Tags zur Verfügung, die einen Text in einem nichtproportionalen Zeichensatz darstellen und vorgegebene Zeilenumbrüche beachten:
        @BODY VORN = <
        >Die erste Zeile
        @BODY VORN = Die letzte Zeile<
        > @BODY VORN = Adressen <%-3>Für die Angabe von Adressen gibt es die <
        >- Tags:<%0> @BODY VORN = <
        > Rechenzentrum der Universität Karlsruhe Zirkel 2 Postfach 6980 D-76128 Karlsruhe <
        > @BODY VORN = Hyperlinks Das interessanteste an Hypertext sind die Hyperlinks, also die Verbindungen zu anderen Dokumenten. Dazu muß man aber erst einmal eine Möglichkeit haben, andere Dokumente zu spezifizieren; dies tun die URLs (Uniform Resource Locator). Viele Browser zeigen die URL des aktuellen Dokuments an; sie setzt sich zusammen aus dem Protokoll, gefolgt von einem Doppelpunkt, zwei Slashs //, die den Host einleiten, und dem Pfad zu dem Dokument auf dem Host. Der Pfad hat dabei nur bedingt mit den UNIX-Dateipfaden zu tun, die Interpretation ist dem durch Protokoll und Host spezifizierten Server überlassen. HTTP-Server übertragen aber im allgemeinen die UNIX-Dateipfade auf die URLs, allerdings ist der Startpunkt nicht das Root-Verzeichnis, sondern (aus Sicherheitsgründen) ein spezifisches Dokumentenverzeichnis. So wird aus der URL @BODY VORN = http://www.uni-karlsruhe.de/Betrieb/HTML/Kurzanleitung.html @BODY VORN = der Dateipfad @BODY VORN = /usr/local/etc/httpd/htdocs/Betrieb/HTML/Kurzanleitung.html @BODY VORN = URLs, die mit einer Tilde (~) anfangen, spezifizieren Benutzerverzeichnisse; für RZ-Benutzer liegt der Startpunkt dann in $HOME/.public_html. Jetzt wird die URL @BODY VORN = http://www.uni-karlsruhe.de/~user/Homepage.html @BODY VORN = abgebildet auf den Dateipfad @BODY VORN = /home/ws/user/.public_html/Homepage.html @BODY VORN = Trotzdem kann man mit URLs ähnlich umgehen wie mit Dateipfaden: Man muß beispielsweise in einem Verweis auf ein Dokument nicht immer die ganze URL angeben, wenn sich das andere Dokument auf demselben Server befindet, sondern kann lediglich den Pfad angeben; der Browser setzt dann selbständig Protokoll und Host des aktuellen Dokuments ein. Man sollte von dieser Möglichkeit Gebrauch machen, um so große Schwierigkeiten zu vermeiden, wenn sich einmal der Name des Rechners ändert, auf dem sich die Dokumente befinden. Gehören zwei Dokumente zu einer Hierarchie von Dokumenten, sollte man sogar eine noch lokalere Art von URLs anwenden, indem man den relativen Pfad angibt, genau wie bei Dateipfaden. So würde die URL ../Proxy/ @BODY VORN = abgebildet auf den Dateipfad @BODY VORN = /usr/local/etc/httpd/htdocs/Betrieb/Proxy/ index.html, @BODY VORN = @BODY VORN = wobei noch hinzukommt, daß der Server, wenn nur ein Verzeichnis in der URL angegeben ist, automatisch nach einer Datei index.html sucht. Mit diesen relativen URLs vermeidet man Probleme, wenn die Dokumenthierarchie einmal an eine andere Stelle im Dokumentenbaum verschoben werden soll. Um jetzt konkret einen Hyperlink anzugeben, benutzt man die <>-Tags (A steht für Anchor, zu deutsch Anker), dem öffnenden Tag wird dabei die URL im HREF-Attribut übergeben. Der Textabschnitt, der als Anker dienen soll, wird von den <>-Tags eingeschlossen. @BODY VORN = Den <>Proxy<> sollte jeder verwenden. @BODY VORN = Bilder Bilder sind externe Bestandteile und werden deshalb, ähnlich wie Hyperlinks, unter Angabe ihrer URL eingebunden. Über die URLs gilt dabei das oben gesagte, insbesondere genügt es, bei Bildern, die sich im gleichen Verzeichnis wie das Dokument befinden, den Dateinamen des Bildes ohne weitere Pfadangaben zu spezifizieren. Zum Einbinden von Bildern dient der (leere) <>-Tag, die URL des Bildes wird im im SRC-Attribut übergeben. Zusätzlich kann mit dem Attribut ALIGN, das die Werte BOTTOM, MIDDLE und TOP annehmen darf, die Plazierung des Bildes im laufenden Text angegeben werden. Nicht jeder Browser hat die Möglichkeit, Bilder anzuzeigen; darauf sollte man Rücksicht nehmen. Insbesondere sollte man solche Bilder vermeiden, die lediglich der Dekoration dienen sollen; meist dienen sie nur der Erhöhung der Netzlast oder zerstören das Bild, weil ein frustrierter Benutzer am anderen Ende der langsamen Leitung die Darstellung der Bilder abgeschaltet hat. Andererseits gibt es Bilder, die wichtige Informationen enthalten, die dann aber Benutzern nicht graphikfähiger Browser entgehen. Diesen sollte man wenigstens einen Hinweis auf den Inhalt des Bildes geben, indem man einen alternativen Text im ALT-Attribut angibt, oder (in begründeten Dekorationsfällen) auch einen leeren Text, der so zumindest vermeidet, daß ein Textbrowser nur [IMAGE] anzeigt. @BODY VORN = <> @BODY VORN = @BODY VORN = Kommentare Kommentare in HTML werden zwischen <> eingeschlossen: @BODY VORN = <> @BODY VORN = @BODY VORN = Achtung: Marken lassen sich nicht durch Kommentare ausblenden! Zumindest die gängigen Browser lassen nach dem ersten >> alle Kommentare Kommentare gewesen sein. @AUTOR FUNKTIN = Andreas Ley @UEBER = Englischkurse für das Operating im Rechenzentrum In der letzten Zeit hat eine so rasante Entwicklung im EDV-Bereich stattgefunden, daß sich das Aufgabenfeld des Rechenzentrums entscheidend verlagert hat. Auch die Betriebsabteilung des RZ ist von diesen tiefgreifenden Veränderungen stark betroffen. Während der Betrieb in der letzten Dekade hauptsächlich Aufgaben zu erfüllen hatte, die im Zusammenhang mit den hier installierten Großrechnern standen, ist durch die Dezentralisierung von Rechnern eine Vielzahl von neuen Aufgaben entstanden. Unter anderem sind die Wartung der auf dem Campus verteilten Workstations und die Überwachung der verschiedenen Netzwerke in die Verantwortung des Operatings übergegangen - um nur zwei Beispiele zu nennen. Generell müssen weniger Routinearbeiten erledigt werden, während der Kontakt zu Kunden des Rechenzentrums zugenommen hat. <%-2>Die neuen Aufgaben im Betrieb sind nicht nur durch eine fortschreitende Diversifizierung gekennzeichnet, sondern auch dadurch, daß eine höhere Qualifizierung der Mitarbeiter unerläßlich ist. Daher hat das Rechenzentrum technische Fortbildungsmaßnahmen mit großem Erfolg forciert, die hausintern vorbereitet und durchgeführt wurden. So wurden z. B. ein UNIX- und ein Netzwerküberwachungskurs veranstaltet.<%0> <%-2>Diese Maßnahmen haben gezeigt, daß es dringend notwendig war, die Englischkenntnisse der Mitarbeiter im Betrieb zu verbessern, da alle Computermeldungen und Manuals in Englisch verfaßt sind. Eine Schulung in Englisch sollte den Betrieb sicherstellen und einer Gefährdung der Beschäftigung der Mitarbeiter vorbeugen.<%0> Die Ausbildung mußte einerseits auf die spezielle Vorbildung und andererseits auf die speziellen Aufgaben abgestimmt sein. Solche Englischkurse werden weder von Volkshochschulen noch von universitätsinternen Einrichtungen angeboten. Daher wurden von Oktober 1994 bis April 1995 auf die Bedürfnisse der Betriebsabteilung abgestimmte Kurse erarbeitet und durchgeführt. Die zwingenden Gründe für diese Maßnahme seien nochmal zusammengefaßt: @BODY BLICK 1 = Die Einsatzbereitschaft des Operatings konnte nur garantiert werden, wenn die Englischkenntnisse aller Mitarbeiter des Betriebs in einem halben bis einem Jahr erheblich verbessert wurden. @BODY BLICK 1 = Da die Lerninhalte auf die Aufgaben des Betriebs zugeschnitten waren und kein unnötiger Ballast vermittelt wurde, waren diese speziellen Kurse wesentlich effizienter, kürzer und kostengünstiger als externe Kurse. @BODY BLICK 1 = Es war möglich, bei zwei parallelen Kursen am Rechenzentrum, den Betrieb aufrecht zu erhalten. Dadurch konnten alle Mitarbeiter in einem halben Jahr die notwendigen Kenntnisse erwerben. Nach der Überprüfung der Englischkentnisse der Mitarbeiter stellte sich die Notwendigkeit heraus, Kurse mit unterschiedlichem Schwierigkeitsgrad zu halten. Es fanden zwei Kurse im Umfang von je zwei Wochenstunden für einen Zeitraum von sechs Monaten statt, die auch von Mitarbeitern der Abteilungen Technik und Geschäftsführung besucht wurden. Die Kursinhalte wurden von einer ausgebildeten Englischlehrkraft erarbeitet. Dafür waren drei Monate reserviert. <%-2>Die in diesem Ausbildungsprogramm gewonnenen Erkenntnisse und Kursunterlagen werden anderen Universitätsrechenzentren und Einrichtungen zur Verfügung gestellt, die vor derselben Problematik stehen. Sie werden in Kürze als interne Berichte des Rechenzentrums Nr. <%-3>57/95 und Nr. 58/95 über WWW unter der<%-2> <%-8>URL-Adresse<%-7> http://www.uni-karlsruhe.de/Uni/RZ/Schriften/ beziehbar sein. Teil I enthält die Unterlagen für den Anfängerkurs und Teil II für den Fortgeschrittenenkurs. Wir danken dem Verlag Rudolf Haufe, Freiburg, der die Erlaubnis erteilte, Textpassagen aus dem Buch ``EDV-Fachenglisch, Lehrbuch und Wörterbuch'' von Elisabeth Derisiotis hierfür zu verwenden. Frau Sämann, die mit großem Engagement und völlig selbständig die Kurse vorbereitet und durchgeführt hat, möchte ich an dieser Stelle recht herzlich danken. Dabei ist hervorzuheben, daß es für ihre schwierige Aufgabe keinerlei Unterlagen und Erfahrungen gab. Herr Prof. Schreiner ermöglichte durch seine Unterstützung als Leiter des Rechenzentrums überhaupt erst die Konzeption und Realisierung dieser Kurse. Dafür sei ihm besonders gedankt. Mein weiterer Dank geht an die Mitarbeiter des Betriebs des Rechenzentrums der Universität Karlsruhe, ohne deren Mitarbeit diese Weiterbildungsmaßnahme nicht möglich gewesen wäre. @AUTOR FUNKTIN = Dr. Rüdiger Weiß @UEBER = Wissenschaftler aus Tschechien Gast am Rechenzentrum Die Abteilung ``Numerikforschung für Supercomputer'' unter der Leitung von Prof. Dr. Willi Schönauer konnte Herrn Miroslav Rozloznik, Akademie der Wissenschaften, Prag, Tschechien, für einen <%-2>Forschungsaufenthalt von 12 Tagen im Juli 1995 als Gast begrüßen.<%0> Zwischen der Akademie der Wissenschaften, Prag, Tschechien, und dem Rechenzentrum der Universität Karlsruhe bestehen seit der Wende Kontakte. Herr Rozloznik schreibt zur Zeit am Institut für Informatik der tschechischen Akademie seine Doktorarbeit über iterative Gleichungslöser. In einem Teil dieser Arbeit wird die Stabilität von Implementierungen für fehlerminimierende Verfahren, <%-2>die von Dr. Weiß am Rechenzentrum der Universität Karlsruhe entwickelt wurden, untersucht.<%0> Viele Probleme der Physik, der Ingenieurwissenschaften, der Medizin und Chemie lassen sich durch Systeme partieller Differentialgleichungen beschreiben. Die numerische Lösung dieser Systeme mit den Methoden der finiten Elemente, der finiten Differenzen oder der Randelemente führt auf die Lösung extrem großer linearer Gleichungssysteme. Um diese Systeme in akzeptabler Zeit lösen zu können, sind sowohl die schnellsten Computer als auch die modernsten numerischen Verfahren nötig. Die fehlerminimierenden Verfahren sind neue numerische Algorithmen mit bemerkenswerten Eigenschaften und können darüberhinaus effizient vektorisiert und parallelisiert werden. Daher sind sie sehr geeignet für die Anwendung auf heutigen Superrechnern. Am Rechenzentrum ist wenig Raum für rein theoretische Untersuchungen. Hier ergänzen die theoretischen Untersuchungen der Akademie der Wissenschaften in idealer Weise die hier am Rechenzentrum aus der <%-2>Praxis heraus entwickelten Verfahren. Andererseits <%0>sind zum Praxistest der theoretischen Beiträge von Herrn Rozloznik, <%-2>die neue und stabile Implementierungen <%-3>einführen und untersuchen, Rechner nötig, die in <%-2>Tschechien nicht verfügbar sind. Diese Tests konnten am Rechenzentrum der Universität Karlsruhe durchgeführt werden.<%0> Im Jahr 1994 besuchte Herr Rozloznik für eine Woche die Abteilung ``Numerikforschung für Supercomputer'' am Rechenzentrum der Universität Karlsruhe. Während dieses Aufenthalts wurden erste Tests für neue Implementierungen fehlerminimierender Verfahren auf dem Karlsruher Vektorrechner SNI S600/20 durchgeführt. Die Arbeiten wurden anschließend sowohl in Prag als auch in Karlsruhe weitergeführt. <%-2>Bei dem diesjährigen Aufenthalt von Herrn Rozloznik <%0>wurden auch für sehr große und schlecht konditionierte Matrizen stabile Implementierungen sowohl theoretisch begründet als auch praktisch nachgewiesen. Darüberhinaus konnte gezeigt werden, daß die fehlerminimierenden Verfahren für bestimmte Probleme konkurrenzlos gut sind. Diese Arbeiten haben nun ihren Abschluß gefunden und sind in dem internen Bericht des Rechenzentrums Nr. 56/95, M. Rozloznik and R. Weiß, "On the stable implementation of the Generalized minimal error method", dokumentiert. Der Bericht kann über WWW unter der URL-Adresse @BODY VORN = http://www.uni-karlsruhe.de/~ne03/literatur. html @BODY VORN = bezogen werden. Eine Veröffentlichung in der Zeitschrift Applications of Mathematics wird angestrebt. @AUTOR FUNKTIN = Dr. Rüdiger Weiß @UEBER = Anwendungssoftware @UEBER LINIEN = Floating License für PATRAN 3 Release 1.4-1 Endlich, nach langer Wartezeit kann das bisherige, etwas angestaubte PATRAN 2.5, für das nur eine limitierte maschinengebundene Lizenz existierte, durch das neue P3/PATRAN ersetzt werden. Das Rechenzentrum hat eine Lizenz für 7 gleichzeitige Nutzer auf HP9000 Workstations erworben. Zur Erinnerung: P3/PATRAN ist der Finite Elemente Prä-und Postprozessor innerhalb des MSC/PATRAN-Systems. Mit ihm kann man @BODY BLICK 1 = Geometrien erzeugen und vernetzen @BODY BLICK 1 = auch direkt FE-Netze erzeugen @BODY BLICK 1 = den Elementen physikalische und Materialeigenschaften zuordnen @BODY BLICK 1 = über Schablonen direkt Datensätze für diverse FE-Programme generieren @BODY BLICK 1 = <%-3>die Ergebnisse der FE-Berechnungen grafisch darstellen<%0> Die Benutzeroberfläche basiert auf Motif und die Struktur des Programms hat sich geändert, sodaß Kenner von PATRAN II sich umstellen müssen. Im folgenden einige Charakteristika von P3/PATRAN: @BODY BLICK 1 = Wahl der jeweiligen Applikation (Geometry, Finite Element, Loads/BCs, Results, etc.) über eine Menüleiste. @BODY BLICK 1 = Funktionen und Auswahl von Modellbestandteilen wahlweise über Pop-Up-Menüs, Kommandos oder spezielle Auswahlmenüs. @BODY BLICK 1 = komplette On-Line Dokumentation, incl. Tutorial, Manuals, Beispiele u.v.m. im FrameMaker-Format. @BODY BLICK 1 = <%2>Generierung der kompletten Eingabedaten für ABAQUS<%0>, ANSYS und MSC/NASTRAN. @BODY BLICK 1 = Einlesen von IGES-Daten. @BODY BLICK 1 = Neutrale Files aus PATRAN II sind voll kompatibel. P3/PATRAN kann z.Z. auf den HP9000-Maschinen im RZ-Pool (Raum -112) und im DT-Pool aufgerufen werden. Um P3/PATRAN auch in anderen Pools oder auf institutseigenen Maschinen verfügbar zu machen, muß lokal ein Client installiert werden. Interessenten mögen sich bitte mit mir in Verbindung setzen (Tel. -4035, e-mail: paul.weber@rz.uni-karlsruhe.de). Weitere Informationen findet man im WWW-Server unter http://www.uni-karlsruhe.de/~PATRAN/). @AUTOR FUNKTIN = Dr. Paul Weber @UEBER LINIEN = ftnchek Project Files für numerische Unterprogrammbibliotheken<%10> Das Programm ftnchek (Fortran Program Checker) ist ein sehr leistungsfähiges Werkzeug, das die Erstellung und Wartung von Fortran 77 Programmen unterstützt. Insbesondere kann ftnchek dazu eingesetzt werden, Fehler festzustellen, die durch falsche Parameterübergabe beim Unterprogrammaufruf verursacht werden. Dies war bislang jedoch nur für Programme möglich, die im Quelltext vorliegen. Um diese Funktion auch für die vom RZ bereitgestellten Unterprogrammbibliotheken nutzen zu können, wurden sogenannte Project Files erstellt, die die notwendigen Informationen über die Parameterübergabe enthalten. Wie der entsprechende Aufruf von ftnchek lautet, sowie weitere Informationen zu ftnchek und anderen auf den HP- bzw. IBM-Workstations installierten Dienstprogrammen zur Unterstützung der Fortran-Programmierung findet man im WWW unter der URL: http://www.uni-karlsruhe.de/Uni/RZ/Software/ Anwendungen/LANG/F77TOOLS/ bzw. .../F90TOOLS @AUTOR FUNKTIN = Nikolaus Geers @UEBER LINIEN = <%22>NAG Fortran 90 Library Im Rahmen der erweiterten Landeslizenz für die NAG-Bibliothek wurde jetzt auch die NAG Fortran 90 Library auf den vom RZ administrierten Workstations installiert. Diese Bibliothek wurde unter Benutzung der neuen Sprachelemente von Fortran 90 (Module, generische Prozedurnamen, benutzerdefinierte Datentypen etc.) völlig neu konzipiert. Weitere Informationen zu dieser Bibliothek sind im WWW unter der URL http://www.uni-karlsruhe. de/Uni/RZ/Software/Anwendeungen/MATH/LIBS/ NAGFL90/ abrufbar. @AUTOR FUNKTIN = Nikolaus Geers @UEBER LINIEN = <%22>XV jetzt mit Photo-CD-Support Ab sofort kann mit dem Programm XV das Photo-CD-Format gelesen werden. Die Dokumentation ist beim Studentenwerk für 3,50 DM erhältlich. Das Programm können Sie mit dem Kommando xv an jeder Workstation des RZ aufrufen. @AUTOR FUNKTIN = Rolf Mayer @UEBER = <%14>Veranstaltungen<%0> @UEBER LINIEN = Einführungskurs in ABAQUS 5.4 In der Zeit vom 6.-9. November findet wieder ein Einführungskurs in ABAQUS 5.4 statt. @BODY TABS = Datum: 6.11. bis 9.11.1995 @BODY TABS = Zeit: jeweils 9.00 - 13.00 Uhr, ab 14.00 Uhr Übungen an den IBM RS6000 Workstations @BODY TABS = Ort: RZ, Raum -101, UG Es werden keine speziellen Anforderungen an die Kursteilnehmer gestellt. @BODY VORN = Programm: @BODY VORN = 1. Tag: @BODY BLICK 1 = Aufbau und Struktur von ABAQUS @BODY BLICK 1 = Organisation der ABAQUS-Dokumentation @BODY BLICK 1 = Einführendes Beispiel @BODY BLICK 1 = Erzeugung der Knoten und der Vernetzung mit ABAQUS-Kommandos Der erste Tag wendet sich an Interessenten, die bisher noch mit keinem FE-Programm vertraut sind. Benutzer, die sich schon etwas auskennen bzw. die ihre Modelle mit I-DEAS, PATRAN oder anders als mit ABAQUS-Kommandos erzeugen, können diesen Tag überspringen. @BODY VORN = 2. Tag: @BODY BLICK 1 = ABAQUS am Rechenzentrum (Installation am SNI S600/20, HP9000-FE-Server und an anderen Workstations) @BODY BLICK 1 = ABAQUS-Konventionen @BODY BLICK 1 = Elementebibliothek @BODY BLICK 1 = Materialeigenschaften @BODY VORN = @BODY VORN = 3. Tag: @BODY BLICK 1 = Lösungsalgorithmen @BODY BLICK 1 = Belastungsgeschichte, Prozeduren, Randbedingungen @BODY BLICK 1 = Lasten @BODY BLICK 1 = Restarts @BODY BLICK 1 = ABAQUS-Ausgabe @BODY VORN = @BODY VORN = 4. Tag: @BODY BLICK 1 = ABAQUS/Post @BODY BLICK 1 = spezielle Problemlösungen: @BODY BLICK 2 = Wärmeausbreitungsprobleme @BODY BLICK 2 = gekoppelte Temperatur-/Spannungsprobleme @BODY BLICK 2 = Eigenfrequenzen und -moden @BODY BLICK 2 = dynamische Probleme @BODY VORN = Alle Teilnehmer bekommen die Kursunterlagen zur Verfügung gestellt. Interessenten melden sich bitte telefonisch (Tel. -4035) oder über e-mail (paul.weber@ rz.uni-karlsruhe.de) an. @AUTOR FUNKTIN = Dr. Paul Weber @UEBER LINIEN = Einführung von DCE und LoadLeveler im AB-Pool Ab dem Wintersemester 95/96 wird die Betriebsweise des AB-Pools (MAC-Nachfolge-Pool) in wichtigen Aspekten umgestellt: @BODY BLICK 1 = Die Maschinen laufen vollständig integriert unter dem Distributed Computing Environment (DCE) und verwenden als Benutzer-Filesystem das Distributed File System (DFS). @BODY BLICK 1 = Um in Randzeiten die Maschinenkapazitäten besser nutzen zu können (eine Workstation des AB-Pools hat immerhin 128 MB Hauptspeicher und eine Höchstleistung von 113 SPEC92int und 204 SPEC92fp), wird probeweise ein Batch-Verwaltungs-System (LoadLeveler) eingeführt. Dieses System verwendet ebenfalls DCE und DFS. Dazu veranstaltet das Rechenzentrum am Donnerstag und Freitag, den 5.10.95 und 6.10.95, einen Einführungskurs in die Benutzung des DCE und des Batchsystems LoadLeveler. Die Veranstaltung richtet sich an Betreuer der im Wintersemester im Ausbildungspool stattfindenden Kurse und an Benutzer, die im Ausbildungspool im Batchbetrieb rechnen wollen. Am Donnerstag wird zunächst eine Einführung in DCE und DFS und am Freitag werden dann praktische Hinweise zur Arbeit mit DFS und dem LoadLeveler gegeben. @BODY TABS = Datum: 5.10. und 6.10.95 @BODY TABS = Zeit: jeweils 14.00 - 15.30 Uhr @BODY TABS = Ort: RZ, Raum 217, 2. OG @BODY TABS = DCE/DFS ist ein globales Filesystem und bietet gegenüber anderen verteilten Filesystemen Vorteile bei der Sicherheit, Verfügbarkeit und Performance. Der IBM LoadLeveler wurde vom RZ dahingehend angepaßt, daß im Batchbetrieb auf Daten im DFS zugegriffen werden kann. Mit dem LoadLeveler lassen sich Jobs auf einem Workstationcluster so verteilen, daß die Maschinen gleichmäßig genutzt werden. @BODY VORN = Kursinhalt: @BODY BLICK 1 = Architektur von DCE @BODY BLICK 1 = Konzepte von DCE und DFS @BODY BLICK 1 = Komponenten von DCE und DFS @BODY BLICK 1 = DCE und DFS am RZ @BODY BLICK 1 = Zugriffsschutz im DFS @BODY BLICK 1 = Kommandos zur praktischen Arbeit mit DFS @BODY BLICK 1 = <%2>Kommandos und Parameter zur Arbeit mit dem LoadLeveler<%0> @BODY BLICK 1 = Vorführung dieser Kommandos @AUTOR FUNKTIN = Roland Laifer / Horst Gernert @UEBER LINIEN = <%-4> Vo<%-3>rführung von SCEPTRE 90 unter LINUX<%0> <%-2>Über Jahre hinweg war auf Großrechnern des Rechenzentrums das Netzwerkanalyseprogramm SCEPTRE<%-3> <%0>im Einsatz gewesen, mit dem eine Reihe von Schaltungen simuliert und über Ersatzschaltbilder auch neuartige Bauelemente (z.B. Josephson-Kontakte) auf dem Rechner getestet worden sind. Eine Stärke von SCEPTRE besteht in der besonderen Berücksichtigung nichtlinearer Effekte, die mittels arithmetischer Anweisungen, Tabellen, mathematischer Funktionen, gesteuerter Spannungs- und Stromquellen sowie anderer Netzwerkgrößen beschrieben werden können. Ein weiteres Merkmal ist die Möglichkeit zur Verwendung eigener Parameter und ihrer zeitlichen Ableitungen. Damit lassen sich Differentialgleichungssysteme, die mit elektrischen Netzwerken gekoppelt sein können, gleichzeitig lösen. Auch nichtelektrische (z.B. mechanische) und sogar interdisziplinäre (z.B. mechanisch-elektronische- "Mechatronik") Problemstellungen, die sich durch Differentialgleichungen darstellen lassen, können auf diese Weise simuliert werden. Die Eingabe erfolgt in diesen Fällen entweder direkt in mathematischer Form oder über ein elektrisches Analogon. Obwohl es sich bei SCEPTRE um ein Batchprogramm handelt, läßt es sich auf dem PC (unter LINUX) gut handhaben. Die Rechenergebnisse werden in Tabellenform fortlaufend ausgegeben und können mit gnuplot und anderen Graphikpaketen dargestellt werden; eine Schnittstelle für Online-Graphiken ist ebenfalls vorhanden. Für eine Vorführung von SCEPTRE 90 konnte das RZ den Fachmann (und Portierer nach LINUX) für dieses Programm, Herrn Dr.-Ing. Wolf-Rainer Novender von der FH Friedberg, gewinnen: @BODY FETT ZEN = Vorführung des Netzwerkanalyseprogramms @BODY FETT ZEN = SCEPTRE 90 (Großbildprojektion) @BODY TABS = Datum: Donnerstag, 19.10.95 @BODY TABS = Zeit: 16.45 bis 17.30 Uhr @BODY TABS = Ort : RZ, Raum 217, 2 OG. @BODY TABS = Herr Dr.-Ing. Novender wird schwerpunktmäßig die Handhabung des Programms, die Eingabedaten und den Simulationsablauf anhand von drei Beispielen vorstellen (Marx'scher Stoßgenerator, Gleichstromrelais, Magnetisierungsstrom mit Hystereseverlusten und Fourieranalyse). Alle Interessenten lade ich hierzu herzlich ein. @AUTOR FUNKTIN = Dieter Kruk @UEBER LINIEN = Jahrestreffen der Anwender elektrotechnischer Software Bei elektrotechnischen Aufgabenstellungen ist die Effizienzsteigerung durch Einsatz geeigneter Softwarepakete erheblich. Die Schaltungen werden komplexer, die Leiterplatten dichter belegt, die Bauteile stärker integriert - und manchmal steigen sogar die verwendeten Frequenzen. Mancher Schaltungsentwurf ist ohne Rechnerhilfe überhaupt nicht mehr zu realisieren. Aus diesem Grund sind innerhalb unseres Campus mehrere Dutzend Programme insbesondere für Platinen-Layout und Schaltungssimulation im Einsatz, vor allem die Programme top-CAD und PSPICE. Künftig sind auch Programme zur Beurteilung der elektromagnetischen Verträglichkeit (EMV) von Geräten zu erwarten. Erfreulicherweise sind bei PSPICE in den zurückliegenden Wochen erhebliche Preissenkungen eingetreten, so daß zusätzliche Lizenzen jetzt schon für weniger als DM 3000,- erhältlich sind. Dies hängt offensichtlich auch mit der Marktlage im Softwarebereich zusammen, denn die einfacheren Programme wie TopSPICE und SCEPTRE 90 (siehe auch Bericht auf Seite 16) können bereits für einen Bruchteil dieses Betrages erworben werden. Zum Austausch von Erfahrungen mit den vorhandenen Paketen und zur eventuellen gemeinsamen Bestellung von Softwarepaketen lade ich auch in diesem Jahr ein zum @BODY FETT ZEN = Anwendertreffen für Elektrotechniker @BODY VORN = @BODY TABS = Datum: Donnerstag, 19.10.95, @BODY TABS = Zeit: 16.00 bis 16.45 Uhr @BODY TABS = Ort : RZ, Raum 217, 2.OG @BODY VORN = Themen (voraussichtlich): @BODY BLICK 1 = Erfahrungen mit top-CAD für Windows 1.2 @BODY BLICK 1 = <%-2>Software für Elektrotechniker - Angebote 1995 (Marktlage u.a. bei top-CAD, PSPICE, TopSPICE,<%0> SCEPTRE-90, MENHIR, ELECTRONIC WORKBENCH) @BODY BLICK 1 = Erweiterung der Bauteilebibliotheken-Angebote von Bauteile-Herstellern auf Diskette oder CD-ROM, evtl. Eigenentwicklungen im Campus @BODY BLICK 1 = Kleine Software-Börse für gebrauchte, jedoch nicht mehr benötigte PC-Lizenzen, auch Demo-Versionen (bitte durchforsten Sie mal Ihre Diskettenbox) @BODY BLICK 1 = Das Virusproblem - auch Elektrotechniker können betroffen sein. Hilfestellung durch das Rechenzentrum. @BODY BLICK 1 = Im Anschluß an dieses Anwendertreffen findet eine Vorführung von SCEPTRE 90 statt. @AUTOR FUNKTIN = Dieter Kruk