ALIs

kommt noch

AVS 5

AVS 5 ist der Vorläufer des Produktes AVS/Express, und wie dieses ein Software-Entwicklungssystem mit modularem Aufbau, das zur Entwicklung von Anwendungen im Bereich Datenvisualisierung verwendet wird. Die vorliegende Beschreibung ist nur noch von Interesse, wenn unbedingt AVS 5 verwendet werden muss, andernsfalls ist AVS/Express vorzuziehen, zu dem es eine eigene Beschreibung gibt.

Allgemeines

Unter Visualisierung versteht man die Aufbereitung numerischer Daten mit dem Ziel, anschauliche graphische Darstellungen zu gewinnen. Meist handelt es sich dabei um enorm große Datenmengen, deren direkte Auswertung äußerst mühsam wäre, z.B. Werte auf dem Gitter eines Finite-Elemente-Modells oder Meßdaten. Die Ableitung qualitativer Aussagen steht bei der Visualisierung im Vordergrund, quantitative Aussagen werden selten gewonnen.

AVS 5 ist ein Visualisierungssystem der Firma Advanced Visual Systems Inc. Seit 1997 wird dieses Produkt vom Hersteller zwar noch weitergepflegt (d.h. es gibt gelegentlich Fehlerbehebungen und Anpassungen an neue Betriebssystemversionen), aber nicht mehr weiterentwickelt, denn das Paket AVS/Express ist an seine Stelle getreten. Wenn Sie sich erstmalig mit den Visualisierungsmöglichkeiten, die AVS-Produkte bieten, beschäftigen, so sollten Sie sich besser anhand der Beschreibung von AVS/Express informieren.

AVS 5 ist im LRZ nicht mehr installiert, da es nur noch wenige Benutzer dieser Version gibt, stattdessen steht AVS/Express zur Verfügung. (Sollte es dringend notwendig sein, kann ggf. die Möglichkeit geschaffen werden, AVS 5 noch zu benutzen.)

Einige Beispiele aus dem Funktionsrepertoire von AVS 5:

  • Darstellung einer Funktion f(x,y) als "Funktionsgebirge"
  • Abbildung der Werte in einem 2D-Gitter auf Farbverläufe
  • Schnitte durch 3D-Gitter und Objekte
  • Isoflächen
  • Niveaulinien
  • verschiedene Darstellungsarten für geometrische Objekte, Transparenzeffekte
  • interaktive Eingriffsmöglichkeiten wie z.B. Drehen, Zoomen, Manipulation von Darstellungsparametern, z.B. Lichtquellen etc.
  • Volumendarstellungen
  • Stromlinien in Geschwindigkeitsfeldern, bewegte Teilchen
  • Animationssequenzen
  • etc.

Diese Beispiele zeigen, daß die Aufgaben, die an ein Visualisierungssystem gestellt werden, vielfältig sind. Allen gemeinsam ist aber die Bearbeitung der Daten in mehreren aufeinanderfolgenden Schritten. Um beispielsweise eine "Schicht" in einem dreidimensionalen Array von Werten als "Funktionsgebirge" darzustellen, könnten folgende Arbeitsgänge anfallen:

Einlesen des        "Ausschneiden"      Abbildung des     Darstellung
3D-Arrays           einer Schicht       2D-Arrays         auf dem
von Werten    -->   anhand eines   -->  auf ein      -->  Bildschirm
aus einer           wählbaren           geometrisches
Datei               Index               Objekt

Einzelne Teilschritte können bei verschiedenen Anwendungen oder auch mehrmals in einer einzigen Anwendung auftreten. Daher arbeiten heute viele Visualisierungssysteme nach dem Prinzip der Modularisierung: Jeder Bearbeitungsschritt ist eine eigenständige Programmkomponente, ein sog. Modul. Dem obigen Beispiel entspräche in AVS die folgende Verknüpfung von Modulen:

read field --> orthogonal slicer --> field to mesh --> geometry viewer

Dem Benutzer steht eine ganze Palette von Modulen zur Verfügung, die er mit Hilfe einer graphischen Benutzeroberfläche auswählt, und dann mit der Maus spezifiziert, wie Daten von Modul zu Modul weitergereicht werden sollen. Das dadurch entstehende System (das durch Verzweigungen und Zusammenführungen im Datenfluß fast beliebig komplex werden kann) heißt bei AVS network. Es läßt sich mit einem Fließband vergleichen, auf dem die Eingabedaten verschiedene Bearbeitungsstationen durchlaufen.

Der vorliegende Beitrag gibt einen Überblick über das Arbeiten mit AVS, sei es auf institutseigenen Workstations oder im LRZ. Er kann die Originaldokumentation nicht ersetzen, die zur Einarbeitung in AVS herangezogen werden sollte (siehe Abschnitt Dokumentation). Es werden im folgenden Grundkenntnisse im Umgang mit UNIX und X-Windows vorausgesetzt. Informationsquellen hierzu sind z.B.

  • einschlägige Literatur
  • die Benutzerschrift Einführung in UNIX (erhältlich im Benutzersekretariat)

AVS/Express und AVS 5

Von der Firma AVS Inc. wurde ursprünglich das Visualisierungssystem AVS 5 entwickelt. Vor einigen Jahren wurde AVS 5 gründlich überarbeitet und aufbauend auf ein neues Modell des Daten-Handlings das aktuelle Produkt AVS/Express entwickelt, das eine objektorientierte Struktur aufweist. Trotzdem gibt es noch eine Reihe von Anwendern, die noch mit AVS 5 arbeiten und ihre Anwendungen nicht portieren möchten, daher stehen im LRZ sowohl AVS 5 als auch AVS/Express zur Verfügung. Für den Beginn eines neuen Projekts wird aber die Einarbeitung in AVS/Express empfohlen. Die vorliegende Schrift beschäftigt sich mit AVS 5, das im folgenden kurz mit AVS bezeichnet wird. Für Informationen über AVS/Express wenden Sie sich bitte an Jutta Dreer .

Im folgenden bezeichnet $AVS-Dir das Verzeichnis, einer Installation von AVS 5.

Aufruf und Beenden von AVS 5

Aufruf

Nach einer erfolgreichen Installation wird AVS 5 normalerweise gestartet durch das Kommando

avs

sofern der Kommandosuchpfad $AVS-Dir/bin enthält. Zuvor müssen aber die Umgebungsvariablen LM_LICENSE_DIR mit dem Pfad des Lizenzfiles und AVS_PATH mit dem Installationsverzeichnis richtig belegt werden. (Bitte informieren Sie sich diesbzgl. in der Installationsanleitung des Herstellers.) Die Belegung der Umgebungsvariablen kann in einem kleinen Script durchgeführt werden, z.B. so:

        #!/bin/csh -f
        setenv AVS_PATH         <Installationsdirectory von AVS>
        setenv LM_LICENSE_FILE  <Pfad des Lizenzfiles>
        $AVS_PATH/avs $*

Nach dem Aufruf sollte ein längliches, graues Fenster an der linken Bildschirmseite erscheinen (das Hauptmenü), in dem verschiedene Felder angeklickt werden können.

Bitte vergessen Sie nicht, beim Arbeiten unter X-Windows die Variable DISPLAY richtig zu belegen, wenn Sie AVS nicht an der Konsole starten.

Das Kommando avs kennt verschiedene Optionen, mit denen sich Voreinstellungen treffen lassen. Beispiel

avs -nohw

wählt explizit den Software Renderer. (Dies ist z.B. notwendig, wenn der Benutzer von einem X-Terminal aus an einer SGI-Workstation arbeitet. In diesem speziellen Fall muß übrigens auch noch die Environment-Variable __SGI_NO_REMOTE_GL definiert werden.)

Eine Möglichkeit für dauerhafte Voreinstellungen bietet die Prologdatei .avsrc, die zuerst im aktuellen Verzeichnis und danach im HOME-Directory gesucht wird. Mit deren Inhalt überschreibt oder ergänzt der Benutzer die Einstellungen in der Datei $AVS-Dir/runtime/avsrc, die immer durchlaufen wird. Kommandozeilenoptionen haben dabei Vorrang vor Prologdatei-Einstellungen.

Aufrufoptionen, .avsrc - Einträge sowie ENVIRONMENT-Variablen sind im AVS User's Guide dokumentiert (S. 3-3 und 3-14 ff).

Hardware- und Software-Rendering

Die Realisierung graphischer Darstellungen kann in AVS alternativ auf zwei Arten erfolgen:

  • Es werden durch die AVS-Software Bilder erzeugt, die dann durch einen X-Server auf den Bildschirm gebracht werden. Dies ist das sog. Software Rendering.
  • AVS ruft plattformspezifische Graphik-Funktionen auf, die die Fähigkeiten eines in der Workstation eingebauten Graphiksubsystems ausnutzen, arbeitet also mit Hardware Rendering.

I.d.R. liefert Hardware Rendering schnellere Ergebnisse, ist aber nur an der Konsole einer entsprechend ausgerüsteten Workstation möglich. Andernfalls (z.B. beim Arbeiten über ein Rechnernetz) muß Software Rendering verwendet werden.

Demos

Nach dem Aufruf von AVS bietet sich dem Benutzer im Hauptmenü der Punkt AVS Application zum Anklicken. Er führt auf ein neues Menü mit den Punkten:

  • AVS Demo
  • Data Viewer
  • Return to Main Menu

Durch AVS Demo werden automatisch ablaufende Beispiele gestartet, die eine gute Möglichkeit sind, mit AVS vertraut zu werden. Sie sind in Themengebiete gegliedert, die in einer Kopfleiste auf dem Bilschirm erscheinen. Daraus können einzelne Demos ausgewählt werden, die mit Auto-Run unter dem Menü Control gestartet werden. Sie werden während ihres Ablaufs in einem Extra-Fenster kommentiert.

Beenden von AVS

Das Hauptmenü von AVS enthält den Punkt Exit AVS.

Arbeiten mit AVS

Das Konzept

Wie bereits im ersten Abschnitt erwähnt, ist AVS komplett modular aufgebaut. Eine große Anzahl von Einzelkomponenten (Modulen) steht zur Bearbeitung von Visualisierungsdaten zur Verfügung. Diese können mit Hilfe einer graphischen Oberfläche zu sog. networks zusammengesetzt werden. Schematische Darstellung eines network:

             _____          _____
            |_____|        |_____|
               |_____   ______|
                    |   |                          |
                   _|___|_                         |
                  |_______|                     Datenfluß
                      |       _______              |
                      |      |_______|             |
                      |___  _____|                \ /
                         |  |                      v
                        _|__|_
                       |______|
                         |  |
                  _______|  |__________
               ___|___             ___|___
              |_______|           |_______|

Über solche Module, die Daten einlesen oder auch selbst erzeugen, gelangen Eingabedaten in das network und werden dort von Modul zu Modul weitergereicht und bearbeitet, um am Schluß auf dem Bildschirm graphisch dargestellt oder wieder in eine Datei geschrieben zu werden.

Die einzelnen Module haben folgende Charakteristika:

  • sie erwarten Eingabedaten von festgelegtem Typ, passend zu ihrer Funktion. Ein Modul zur Erzeugung von Isoflächen erwartet z.B. dreidimensionale Felder, ein Modul zur Darstellung von geometrischen Objekten am Bildschirm dagegen eine Geometrie-Beschreibung.
  • Ausgabedaten sind ebenfalls von festgelegtem Typ.
  • Eingabedaten werden
    • von einem Modul selbst erzeugt oder
    • von Dateien eingelesen oder
    • von einem Vorgängermodul im network geliefert
  • Ausgabedaten werden
    • auf dem Bildschirm dargestellt oder
    • in Dateien geschrieben oder
    • an Nachfolgemodule weitergereicht

Arbeiten mit dem Network Editor

Es gibt verschiedene Arten, mit AVS zu arbeiten. Das Zusammenstellen von Applikationen aus Einzelmodulen erfordert zwar mehr Einarbeitung als z.B. die Benutzung des Data Viewer (siehe Abschnitt Der Data Viewer), ist aber für die flexible Nutzung des vollen Leistungsspektrums von AVS zu empfehlen.

Zum Aufbauen und Modifizieren eines AVS network steht eine graphische Oberfläche zur Verfügung, der sog. network editor. Er kann z.B. über das Hauptmenü von AVS gestartet werden. Es erscheint ein großes Fenster, dessen untere zwei Drittel zunächst freie Fläche sind - die Arbeitsunterlage. Als Bausteine findet man im oberen Drittel in Spalten angeordnete Module, die man mit der Maus in die Arbeitsfläche "ziehen" kann. Die Spalten stellen Klassen von Modulen (z.B. Input, Filter, Mapper, Output) innerhalb einer Modulbibliothek dar.

Die Inhalte der vorhandenen Bibliotheken überschneiden sich, am meisten Module findet man in der voreingestellten Modulbibliothek Supported.

Zum Verbinden der Module verwendet man wieder die Maus. Die Icons, die die Module repräsentieren, haben an der Oberseite Input-Ports, an der Unterseite Output-Ports. Farben kennzeichnen den Datentyp, der über diesen Port gelesen/geschrieben werden kann. Die mittlere Maustaste auf einem Output-Port läßt alle von dort aus möglichen Verbindungen als Linien erscheinen und man wählt darunter eine durch Loslassen der Maustaste auf dem Verbindungspartner. Die rechte Maustaste dient zum Löschen von Verbindungen.

Sobald ein Modul von einem Vorgänger geeignete Daten erhält, beginnt sofort die Bearbeitung und die Ergebnisse werden dann weitergereicht, wenn ein Nachfolgemodul am Output-Port hängt. Ein explizites Starten des network ist also meist nicht nötig (Ausnahme: einige Module warten auf zusätzliche Eingaben, z.B. den Namen einer zu lesenden Datei o.ä.).

Ein detailliertes Beispiel würde an dieser Stelle den Rahmen sprengen. Zur Einarbeitung in AVS empfiehlt es sich, die Beispiele im ersten Kapitel des User's Guide (siehe Abschnitt Dokumentation) nachzuvollziehen und sich einige Demos anzusehen. Im Hintergrund der Demos befindet sich meist der Network Editor auf dem Bildschirm, in dem man das gerade aktive network anschauen kann. Mit dem Menüpunkt Write Network kann man eine Kopie davon in eine Datei schreiben, um sie zu einem späteren Zeitpunkt mit Read Network wieder einzulesen und für eigene Bedürfnisse zu verändern.

Die Arbeitsweise von Modulen wird natürlich nicht nur von den Eingabedaten, sondern auch über Parameter gesteuert. Beispiel: für eine Isoflächenberechnung muß ein Funktionswert eingegeben werden. Für jedes in den network editor geladene Modul erscheinen links neben dem network editor ( dort befindet sich das control panel - Fenster ) sog. widgets - das sind Bedienelemente wie Drehskalen, Eingabefelder, File Browser, Schieberegler usw. Alle Widgets eines Moduls bilden eine Seite und es wird je eine Seite im control panel angezeigt. Die Seiten werden gewechselt durch

  • Anklicken des Moduls im control panel,
  • Anklicken des kleinen quadratischen Knopfes im Modul-Icon innerhalb des networks,
  • für graph viewer, image viewer und geometry viewer über das Menü Data Viewers in der Kopfzeile des control panels.

Parameteränderungen stoßen i.d.R. ein Modul und ggf. seine Nachfolger im network zur Neuberechnung an.

Fertige networks können abgespeichert und später wieder eingeladen werden. Darüberhinaus gibt es Hilfsmittel für diese Art der visuellen Programmierung von eigenen Applikationen, z.B.

  • Zusammenstellen eigener Modulbibliotheken
  • Verändern der Bedienoberfläche von Modulen durch neue Anordnung der widgets ("Layout Editor")
  • Zusammenfassen von Teilnetworks zu Makromodulen
  • usw.

graph, image und geometry viewer

Einige AVS-Module können sowohl in ein network eingebaut als auch unabhängig davon genutzt werden, da sie für sich allein schon eine umfangreiche Funktionalität bereitstellen. Im letzteren Fall ruft man sie über das Hauptmenü von AVS auf. Es sind dies

    image viewer       (Darstellung und Bearbeitung von Bildern)
    geometry viewer    (Manipulation von geom. Objekten, z.B.  Drehen,
                       Zoomen, verschiedene Darstellungsarten,
                       Beleuchten...)
    graph viewer       (Erstellen und Editieren von x-y-Plots),

die in der AVS-Dokumentation auch als Subsysteme bezeichnet werden. Entsprechend ist ihre Bedienoberfläche reichhaltiger als bei den anderen Modulen und jeweils in einem eigenen Kapitel im User's Guide (siehe Abschnitt Dokumentation) beschrieben.

Der graph viewer stellt in Bezug auf Funktionalität und Stabilität eine Schwachstelle im AVS-System dar. Mit der Version 5.02 wurde daher AVS um ein verbessertes Modul (AVS/Graph) zur Erstellung von x-y-Plots ergänzt, das über den network editor zugänglich und dem graph viewer vorzuziehen ist. Beschrieben ist AVS/Graph im AVS/Graph User's Guide (siehe Abschnitt Dokumentation).

Der Data Viewer

Für einige Stardardproblemstellungen gibt es eine vorgefertige Bedienoberfläche - den sog. Data Viewer. Er bietet eine Auswahl von Grundtechniken zur Visualisierung von Daten vom Typ field (n- dimensionale Arrays von Werten) oder ucd (meist Finite-Elemente-Modelle o. ä.). Das jeweils benötigte network wird dabei automatisch generiert.

Der Aufruf erfolgt über AVS Applications im Hauptmenü.

Wichtig ist, daß der Benutzer den Eingabedatentyp zu Beginn auswählen muß! Abhängig davon werden ihm dann unter den Menüs Filters und Mappers Techniken zur Bearbeitung angeboten, die auch miteinander kombiniert werden können. Die Auswahlreihenfolge ist dabei egal. Der Benutzer spezifiziert über eine control list, auf welches Objekt sich die Operationen beziehen sollen.

Datentypen

AVS kennt im wesentlichen folgende Datentypen, die der Benutzer bereitstellen muß oder die während der Bearbeitung von AVS erzeugt werden.

Field Data

Field Data sind n-dimensionale Arrays von Werten, die Skalare oder wieder Vektoren mit m Elementen sein können. Ordnet man den Werten noch Punkte im (zwei- oder dreidimensionalen) Raum zu, so erhält man ein Gitter, dessen räumliche Ausdehnung durch die Koordinaten der Gitterpunkte bestimmt wird.

Daten vom Typ Field liegen z.B. vor bei

  • strömungsmechanischen Ergebnisdatensätzen (Felder von Druck-, Temperatur- und Geschwindigkeitswerten usw.),
  • Computer-Tomographie-Daten,
  • meteorologischen Messungen
  • usw.

Je nach Anordnung der Gitterpunkte unterscheidet AVS drei Typen:

uniform

Die Gitterpunkte sind parallel zu den Achsen angeordnet und haben entlang jeder Achse gleichen Abstand. Die räumliche Ausdehnung und die Anzahl der Punkte in jede Richtung genügen also, um das Gitter völlig zu beschreiben. Bsp. (für zwei Dimensionen):

     x   x   x   x

     x   x   x   x

     x   x   x   x

Felder, denen keinerlei Koordinaten-Information zugeordnet ist, werden durch diesen Typ beschrieben. Ein Beispiel sind Bilder: zweidimensionale Felder von Werten, die die Farben der einzelnen Bildpunkte beschreiben.

recitilinear

Auch hier sind die Gitterpunkte parallel zu den Achsen angeordnet, haben aber unterschiedliche Abstände, d.h. pro Achse ist ein Vektor von Positionen nötig, um das Gitter zu beschreiben. Bsp. (für zwei Dimensionen):

    x x   x      x


    x x   x      x

    x x   x      x

irregular

Die Gitterpunkte sind beliebig im Raum angeordnet. Zur Beschreibung benötigt man also die Koordinaten jedes einzelnen Gitterpunktes. Bsp. (für zwei Dimensionen):

                        x
                 x
              x     x        x
               x
             x    x
                        x

Hat man eine Liste von beliebig im Raum verteilten Punkten, die nicht regelmäßig angeordnet sind, sog. scattered data, so kann man diese für AVS als eindim. Field vom Typ irregular darstellen. (Für scattered data gibt es wenig Möglichkeiten zur direkten Weiterverarbeitung, man kann sie aber oft in den Typ ucd umwandeln und hat damit wieder ein ganzes Spektrum an Möglichkeiten zur Verfügung).

Geometry Data

Dieser Datentyp beschreibt geometrische Objekte im dreidimensionalen Raum. Nur in dieser Darstellung können dreidimensionale Objekte durch das Modul geometry viewer auf dem Bildschirm dargestellt werden. In der Regel wird der Benutzer Geometrien nicht selbst erstellen, diese entstehen vielmehr bei Operationen wie z.B. Isoflächenberechnung, Schnittebenen, Stromlinien usw.

Für den seltenen Fall der direkten Erzeugung von Geometrie-Beschreibungen im AVS-Format gibt Anhang A einige Hinweise.

Unstructured Cell Data

Dies ist eine Form der Modellbeschreibung, die meist für Finite-Elemente oder CFD-Modelle benutzt wird.

Molecule Data

Ein spezielles AVS-internes Format zur Beschreibung von Molekülen.

Image und Colormap

AVS kennt für Bilder ein eigenes Format (image), das aber nur für das Abspeichern in Dateien verwendet wird. Diese sind durch die Extension .x gekennzeichnet im Gegensatz zu .fld für Daten vom Typ Field. Intern werden Bilder aber als Spezialfall zweidimensionaler Felder behandelt. Auch bei Colormaps handelt es sich eigentlich um eindimensionale Felder.

Einlesen eigener Daten

Eines der schwierigsten Probleme beim Umgang mit einem Visualisierungssystem ist das Einlesen eigener Daten. Es ist natürlich von Vorteil, wenn der Benutzer Einfluß auf die datenerzeugende Applikation hat und die Ausgabe gleich im AVS-Format erzeugt. Es existieren dazu verschiedene Programmierbibliotheken und kommentierte Beispiele. Oft hat man jedoch einen fertigen Datensatz, der in einem freien, nicht standardisierten Format vorliegt.

Die nachfolgenden Hinweise sollen einige Möglichkeiten aufzeigen, die für die häufigsten Fälle geeignet sind.

Einlesen von Feldern in freiem Format

Daten vom Typ Field (siehe Abschnitt Field Data) stellen bis jetzt den häufigsten Eingabetyp für Visualisierungssyteme dar und können oft mit folgenden Modulen eingelesen werden.

Das Modul read field

Das Modul read field liest zum einen Felder im AVS-spezifischen Format, zum anderen aber auch sogenannte AVS Description Files. Letztere kann der Benutzer z.B. mit einem Editor erstellen, um seinen Datensatz für AVS zu beschreiben.

Welche Art von Eingabe vorliegt, bestimmt read field automatisch. In jedem Fall muß das Description File die Extension .fld haben.

Beispiel für ein Description File, das stets mit # AVS beginnen muß:

  # AVS field file
  #
  ndim=2
  dim1=40
  dim2=40
  nspace=2
  veclen=1
  data="http://www.lrz-muenchen.de/services/software/grafik/avs/float
"  field=uniform
  variable 1 file=mydata filetype=binary skip=20 stride=2

Dieses ist geeignet für einen Datensatz in der Datei mydata, in dem 40x40=1600 binäre reelle Zahlen (Fortran: real, C: float) aneinandergereiht stehen (ohne die Recordmarken, die meist bei unformatiertem Schreiben aus Fortran-Programmen entstehen!). Die ersten 20 bytes werden überlesen, danach wird jede zweite Zahl aus der Datei zum Aufbau des Feldes verwendet, die anderen übersprungen. Die Anordnung der Feldelemente wird im Fortran-Stil erwartet (d.h. der erste Index variiert am schnellsten).

Durch die Klassifizierung uniform und das Fehlen sonstiger Maßangaben wird angenommen, daß die Datenpunkte in jeder Achsenrichtung denselben Abstand haben. Das folgende Beispiel einer Beschreibungsdatei für ein dreidimensionales Feld zeigt die Spezifikation von Ausdehnungen des Datensatzes, wie sie z.B. bei Messungen mit unterschiedlicher Auflösung in verschiedenen Achsenrichtungen vorliegen können.

  # AVS field file
  #
  ndim=3
  dim1=512
  dim2=512
  dim3=60
  nspace=3
  veclen=1
  data="http://www.lrz-muenchen.de/services/software/grafik/avs/byte
"  field=uniform
  min_ext=0 0 0
  max_ext=100 100 80
  variable 1 file=mydata filetype=binary
  coord 1 file=mycoord filetype=ascii
  coord 2 file=mycoord filetype=ascii skip=1
  coord 3 file=mycoord filetype=ascii skip=2

Leider genügt die Angabe von minimum extent (min_ext) und maximum extent (max_ext) nicht, um Ausdehnungen in AVS richtig zu berücksichtigen. Die Information muß zusätzlich in Form von Koordinaten angegeben werden. Im vorliegenden Fall eines uniform-Gitters genügen dabei die Eckpunkte in der Datei mycoord:

   0 100
   0 100
   0 80

Bei Ascii-Dateien gibt skip=... an, wie viele Zeilen überlesen werden sollen.

Weitere Beispiele findet man im AVS User's Guide, S 2-17 ff.

Das Modul file descriptor

Mit diesem Modul können wie bei read field Felder im benutzereigenen Format eingelesen werden. Die Beschreibung des Datensatzes wird dabei durch eine graphische Oberfläche bewerkstelligt, außerdem besitzt file descriptor gegenüber read field eine leicht erweiterte Funktionalität (z.B. Verwendung von Variablen und Ausdrücken).

Das Vorgehen ist folgendes:

  • das Modul file descriptor wird auf die Arbeitsfläche des Network Editor plaziert.
  • Ein Fenster erscheint, in dem der Benutzer (hauptsächlich durch Anklicken) eine Formatbeschreibung seiner Daten erstellt.
  • Im control panel von AVS wird mit dem Knopf Browser for File 1 ein Browser für das erste (evtl. einzige) Eingabefile angewählt und dann ein Filename spezifiziert.
  • Der Knopf send data stößt das Einlesen der Daten an
  • evtl. Einlesen weiterer Dateien

Das Modul file descriptor kann vor oder nach dem Einlesen der Daten in ein network eingebaut werden und dient dann als "Lieferant" für Daten im AVS-Field-Format.

Formatbeschreibungen können abgespeichert und später wiederverwendet werden (erst Knopf write form bzw. read form betätigen, dann Filenamen im Browser angeben, die Reihenfolge ist leider wichtig). Liegt schon eine fertige Formatbeschreibung vor, so kann man zum Einlesen auch das Modul data dictionary verwenden.

file descriptor ist unter der Bezeichnung ADIA (AVS Data Interchange Application) ausführlicher beschrieben im AVS Applications Guide (siehe Abschnitt Dokumentation).

Spezielle Datenformate aus anderen Applikationen

Eingabefilter

Für einige gängige Datenformate aus anderen Programmpaketen gibt es sogenannte Eingabefilter. Standardmäßig stellt AVS nur Filter für Geometriedaten und ein Chemiedatenformat bereit, und zwar:

       Brookhaven PDB             (.pdb)
       Mathematica Three Script   (.ts)
       Movie BYU                  (.byu)
       UNC                        (.ppoly)
       Wavefront                  (.wfront)

Die angegebenen Extensionen müssen die Eingabe kennzeichnen. Werden Dateien mit diesen Formaten im Geometry Viewer mittels read object eingelesen, wird der entsprechende Filter automatisch angewendet. (Daneben können die Filter auch auf Shell-Ebene aufgerufen werden und lesen dann von der Standardeingabe.)

Module

Für wenige Datentypen gibt es spezielle Einlesemodule:

       Plot3D-Daten:      read plot3d
       Brookhaven PDB:    pdb to geom

Konversion von Bildformaten

Für einige bekannte Bildformate (z.B. Tiff, GIF, Iris RGB etc.) gibt es ein Konversionsprogramm namens convert, das direkt das Format AVS image schreiben kann. Dieses public domain - Produkt ist im LRZ nicht an allen Rechnern und teilweise auch nicht mit voller Funktionalität installiert. Bitte erkundigen Sie sich ggf. im LRZ (siehe Abschnitt Betreuung).

Eigene Programmierung

Eingabefilter

Für Geometrieformate gibt es oft keine vorgefertigte Lösung für das Einlesen in AVS. Man kann aber eigene Eingabe-Filter schreiben, indem man die Beispielprogramme in $AVS-Dir/filter als Vorlage benutzt. Diese erzeugen mit Hilfe von Bibliotheksfunktionen (libgeom) aus einem in den Programmheadern dokumentierten ASCII-Format eine AVS-Geometrie und sind möglicherweise an das vorliegende Format anzupassen (siehe auch Anhang A).

Module

Besonders für Daten aus Finite-Elemente- und CFD-Modellen oder auch Chemiedaten (mit Ausnahme von PDB) bleibt oft nur das Schreiben eines eigenen AVS-Moduls. Beispiel-Sourcen findet man in

  • $AVS-Dir/examples bzw.
  • $AVS-Dir/examples/chemistry

Weitere Dokumentation: AVS Developer's Guide (siehe Abschnitt Dokumentation).

Public Domain Module

Dank der Verbreitung von AVS kann man oft darauf hoffen, daß innerhalb der aktiven "AVS-Gemeinde" ein ähnliches Problem schon einmal gelöst und veröffentlicht wurde, sei es in Form von Filtern oder selbst erstellten Einlesemodulen. Siehe auch Abschnitt Quellen für public domain Module .

Erweiterungen

Aufgrund seines modularen Aufbaus ist AVS gut zur Erweiterung durch neue Module geeignet. Die Gestaltung einer Bedienoberfläche und die Kommunikation mit anderen Modulen muß dabei nicht vom Benutzer selbst programmiert werden. Etwas Programmiererfahrung in Fortran oder C ist allerdings zu empfehlen.

Erstellen eigener Module

Hilfestellung bei der Erstellung eines neuen Moduls erhält man durch das AVS-Modul Module Generator, dessen Bedienoberfläche nach dem Einladen in den network editor erscheint. Ein- und Ausgabedatentypen sowie Parameter werden mit Knopfdruck spezifiert und dann durch Write Source ein Modul-"Skelett" erzeugt. Mit Edit fügt der Benutzer darin seinen Programmtext ein.

Im Kapitel 2 des AVS Applications Guide (S. 11) wird der Module Generator genauer behandelt.

Quellen für public domain Module

In der letzten Zeit hat eine große Anzahl von AVS-Benutzern aus aller Welt selbst geschriebene Module als public domain-Software, d.h. frei kopierbar zur Verfügung gestellt. Das International AVS Centre (IAC) stellt diese gesammelt als durchsuchbares Archiv zur Verfügung. Siehe dazu

     www.iavsc.org

Public_Domain (rechts neben Supported)

Verteiltes Arbeiten

Durch ihren modularen Aufbau sind AVS-Applikationen gut dafür geeignet, auf verschiedene Rechner verteilt zu werden, um deren besondere Stärken zu nutzen. Man könnte z.B. an der Konsole einer Graphik-Workstation arbeiten, die die Darstellung von Objekten mit Funktionen wie Drehen, Farbe ändern usw. übernimmt, während die vorherige Aufbereitung der zugrundeliegenden Daten oder sogar ihre Erzeugung von einem Supercomputer durchgeführt wird. Natürlich müssen die Daten dann bei der Weitergabe von Modul zu Modul über ein Rechnernetz geschickt werden. Bei AVS braucht sich der Benutzer aber nicht selbst um die Kommunikation zu kümmern, er spezifiziert lediglich beim Aufbau des network, auf welchem Rechner ein Modul ablaufen soll.

Das "Auslagern" von Modulen ist im AVS User's Guide S.8-23 ff beschrieben.

Der Command Language Interpreter CLI

AVS wird zwar von den meisten Benutzern über die graphische Oberfläche bedient, kann aber auch über eine eigene Kommandosprache gesteuert werden. Der Command Language Interpreter (CLI) arbeitet Kommandos ab, die entweder interaktiv oder über fertige Scripts eingelesen werden können. Die Scripts kann man per Editor selbst schreiben oder als Aufzeichnung einer vorhergehenden AVS-Sitzung erzeugen (und ggf. verändern).

Hardcopy-Möglichkeiten

Die durch den image viewer oder geometry viewer auf dem Bildschirm erzeugten Darstellungen können als Postscript-Datei abgespeichert werden, indem man das Modul image to postscript im network an den jeweiligen viewer anschließt. image to postscript arbeitet erst nach Angabe eines Dateinamens. Zu beachten ist, daß sich der Benutzer entscheiden muß, ob er schwarz-weiß oder Farbdarstellung möchte, je nachdem, welche Art von Drucker später verwendet wird.

Soll das Bild später in ein Dokument eingebunden werden (z.B. mit LaTeX), so muß encapsulated postscript angewählt werden.

Im LRZ stehen u.a. Postscript-Drucker für Farbe und schwarz-weiß sowie Möglichkeiten zur Dia-Verfilmung zur Verfügung.

Neben der Umwandlung in Postscript gibt es noch die Möglichkeit, AVS Bilder direkt im AVS image Format abzuspeichern und diese dann mit Hilfe eines public domain Programms wie ImageMagick (Kommando convert) in diverse gängige Formate (z.B. TIFF) umzuwandeln, z.B. zum Zweck der Weiterverarbeitung in DTP-Programmen.

Dokumentation und Betreuung

Folgende Informationsquellen stehen zur Verfügung:

  • In allen AVS Subsystemen und im Network Editor gibt es einen Help - Knopf, der ein neues Fenster mit einer Online-Hilfe erscheinen läßt. Die Online-Hilfe ist auch in japanischer Sprache verfügbar.
  • Module auf der Arbeitsfläche des Network Editor haben rechts neben ihrem Namen einen kleinen quadratischen Knopf. Die rechte oder mittlere Maustaste liefert hier ein Menü mit dem Punkt Show Module Dokumentation.
  • Der Online - Manualeintrag zu avs informiert über Aufrufoptionen.
  • Eine gedruckte Originaldokumentation zu AVS 5 kann auf Anfrage im LRZ eingesehen werden.
  • Kursunterlagen des Manchester Computing Centre
  • News Über das weltweite Internet-Forum "News" können Benutzer untereinander AVS-Fragen diskutieren. News ist in Themengebiete, sog. Gruppen eingeteilt. Die Gruppe

  • comp.graphics.apps.avs

    beschäftigt sich mit AVS.

  • World Wide Web

  • Der WWW-Server des International AVS Centre (IAC) ist erreichbar unter

    http://www.iavsc.org/

    Er bietet diverse Informationen, wie z.B. Schlagwortsuche in alten News-Artikeln, Publikationen etc. und auch sehr gute Kursunterlagen zum Selbststudium, die meist am Manchester Computing Centre der University of Manchester erarbeitet wurden.

Betreuung

Mit Problemen und Fragen zu AVS wenden Sie sich bitte an Jutta Dreer .

Anhang A: Erzeugen von Filtern für Geometriedaten-Files

(Monika Geppert, ehem. Werkstudentin im LRZ)

(Im Folgenden bezeichne $AVS-Dir das Verzeichnis, in dem AVS installiert ist!

Um in AVS Geometriedaten einzulesen, können Filter verwendet werden, die das einzulesende Datenformat in das AVS-interne Geometrie-Format umwandeln.

Für einige Datenformate werden solche Filter automatisch im Geometry-Viewer aufgerufen:

                Filter          Datenformat

            ts_to_geom          Mathematica ThreeScript
           byu_to_geom          Movie BYU
           pdb_to_geom          Protein Data Bank
         ppoly_to_geom          UNC
        wfront_to_geom          Wavefront

         polyh_to_geom          \
         polyg_to_geom           \  siehe
          mesh_to_geom           /  unten
        sphere_to_geom          /
         label_to_geom          (für Beschriftungen)

Die ausführbaren Dateien für die Filter finden Sie in $AVS-Dir/bin, einige Quellcode-Dateien unter $AVS-Dir/filter und Beispiel-Daten unter $AVS-Dir/filter/example.

Die Formate polyh, polyg, mesh und sphere sind AVS-spezifische ASCII- Formate zur Beschreibung von Geometrien. Benutzerdaten können in eines dieser Formate gebracht werden, oder man paßt den zugehörigen Filter auf die eigenen Daten an.

AVS entscheidet aufgrund der Endung des Dateinamens, um welches Datenformat es sich in dieser Datei handelt: Versuchen Sie z.B. eine Datei namens cube.polyg einzulesen, so wird AVS den Filter polyg_to_geom aufrufen. Dieser Filter erzeugt aus cube.polyg die Datei cube.geom, die die Daten im AVS-internen Geometrie-Format enthält. Die Filternamen bestehen also aus 3 Teilen: der Endung der Einabedatei (im Beispiel: polyg), dem String _to_ und der Endung der Ausgabedatei (geom).

Die Datenformate der AVS-spezifischen Filter:

1. polyh:
        Typ (entweder "facet" oder "smooth")
        Anzahl n der Ecken (integer)
          x-, y- und z-Koordinate der Ecke 1 (3*float)
          ...
          x-, y- und z-Koordinate der Ecke n (3*float)
        Anzahl n1 der Ecken im Polygon 1 (integer)
          Index der  1. Ecke im Polygon 1 (integer)
          ...
          Index der n1. Ecke im Polygon 1 (integer)
        ...
        Anzahl np der Ecken im Polygon p (integer)
          Index der  1. Ecke im Polygon p (integer)
          ...
          Index der np. Ecke im Polygon p (integer)
        <EOF>
2. polyg:
        Typ (entweder "facet" oder "smooth")
        Anzahl n1 der Ecken im Polygon 1(integer)
        x-, y- und z-Koordinate der  1.Ecke im Polygon 1 (3*float)
        ...
        x-, y- und z-Koordinate der n1.Ecke im Polygon 1 (3*float)
        Anzahl n2 der Ecken im Polygon 2 (integer)
        ..
        <EOF>
3. mesh
        Typ (entweder "scalar", "vertex", "vertex_and_data",
                "normal", "color" oder "normal_and_color")
        Gittergröße m, n (ergibt ein Gitter von m*n Knoten)
        (falls Typ = "scalar":)
                Skalar 1   (float)
                ...
                Skalar m*n (float)
        (falls Typ = "vertex":)
                x-, y- und z-Koordinate von Knoten 1   (3*float)
                ...
                x-, y- und z-Koordinate von Knoten m*n (3*float)
        (sonst: siehe Quellcode $AVS-Dir/filter/mesh.c)
4. sphere
        xmin ymin zmin (3*float)        \  (alles wird in diesen
        xmax ymax zmax (3*float)        /    Bereich skaliert)
        Anzahl der Objekte (integer)
        x-, y- und z-Koordinate des Mittelpunktes, Radius und
                Rot-, Grün- und Blau-Anteil der Farbe (7*float)
        ...
        <EOF>
  (Objekte vom Typ sphere werden als Oktaeder und  nicht  als
  Kugeln dargestellt!)

Falls die angebotenen Filter nicht ausreichen, können Sie in C oder FORTRAN77 eigene Filter programmieren. Verwenden Sie dabei möglichst die Dateien in $AVS-Dir/filter als Muster. Kopieren Sie sich aus diesem Verzeichnis das C- oder FORTRAN- Programm, das Ihrem Datenformat am nächsten kommt, außerdem das "Makefile" und - falls Sie in FORTRAN programmieren möchten - die Datei option.c.

Das Übersetzen und Binden Ihres Programms erfolgt über das Kommando make nachdem Sie folgende Änderungen im "Makefile" vorgenommen haben:

  • Setzen Sie die Shell-Variable AVS_PATH auf $AVS-Dir, falls sie nicht bereits richtig gesetzt ist.
  • In allen Pfadangaben muß .. durch $(AVS_PATH) ersetzt werden.
  • Die Shell-Variable BINFILES muß genau die zu bearbeitenden Targets enthalten
  • Überflüssige Targets können Sie löschen, Sie müssen aber nicht. (Sie werden dann einfach nicht bearbeitet)
  • Falls noch keine passenden Targets für Ihre Filter vorhanden sind müssen Sie diese selbst erzeugen. Verwenden Sie als Muster polyg_to_geom (für C) oder polyg_to_geom_f (für FORTRAN).
  • Unter .FAILED kann stehen: rm $(BINFILES)

Falls Sie ein FORTRAN-Programm als Vorlage verwenden ist außerdem zu beachten:

  • In INCLUDE-Anweisungen ist .. durch den vollen AVS-Pfad $AVS-Dir zu ersetzen.
  • In einigen Muster-Filtern werden Character-Variable im *-Format eingelesen. Dies entspricht nicht Standard-Fortran und muß u.U. geändert werden.

Versuchen Sie das aus $AVS-Dir/filter kopierte Muster-Programm zu übersetzen, bevor Sie es an Ihr eigenes Datenformat anpassen.

Achtung:

  • Ihr Filter muß auf jeden Fall eine Include-Anweisung enthalten für die Datei $AVS-Dir/include/geom.h (C-Programme) bzw. $AVS-Dir/include/geom.inc (FORTRAN-Programme).
  • Die Musterfilter lesen alle von stdin und schreiben auf stdout!

Die Geometrie-Bibliothek von AVS stellt Ihnen diverse Funktionen für die Erzeugung eines Objekts zur Verfügung. Hier die Wichtigsten für C-Programme:

GEOMcreate_obj (type,extent)
Der Aufruf dieser Funktion liefert ein leeres Objekt (Datentyp: GEOMobj) vom angegebenen Typ type. Als type können Sie z.B. GEOM_MESH, GEOM_POLYHEDRON oder GEOM_SPHERE übergeben, als extent GEOM_NULL.
GEOMcreate_mesh (extent,verts,m,n,alloc)
GEOMcreate_polyh (extent,verts,n,plist,flags,alloc)
GEOMcreate_scalar_mesh (xmin,xmax,ymin,ymax,mesh,colors,n,m,alloc)
GEOMcreate_sphere (extent,verts,radii,normals,colors,n,alloc)
Auch diese Funktionen liefern ein Objekt vom entspr. Typ, im Gegensatz zu GEOMcreate_obj können hier jedoch die Objektdaten direkt übergeben werden.
GEOMadd_disjoint_polygon (obj,verts,normals,colors,nverts, flag,alloc)
Fügt dem Objekt obj (Typ GEOM_POLYHEDRON) einen Polygonzug aus den nverts Ecken verts an. Für normals und colors können Sie jeweils GEOM_NULL übergeben. Flag können Sie u.a. auf GEOM_SHARED oder GEOM_NOT_SHARED setzen (für weiche Farbverläufe oder facettenartige Flächen).
GEOMadd_float_colors (obj,colors,n,alloc)
Damit können Sie den Knoten des Objekts obj Farben zuordnen.
GEOMadd_polygon (obj,nverts,indices,flags,alloc)
Fügt dem Objekt obj (Typ GEOM_POLYHEDRON) einen Polygonzug aus nverts Ecken an, die durch einen entspr. Aufruf von GEOMadd_vertices angefügt wurden. Diese Ecken werden über die indices angesprochen (numeriert von 1 bis n in der Reihenfolge des Anfügens).
GEOMadd_polygons (obj,plist,flags,alloc)
Entspricht GEOMadd_polygon für mehrere Polygonzüge
GEOMadd_vertices(obj,verts,n,alloc)
Fügt dem Objekt obj die n Knoten verts an.
GEOMadd_radii (obj,radii,n,alloc)
Fügt dem Objekt obj (Typ GEOM_SPHERE) die n Radien radii an. n sollte gleich der Anzahl der Knoten in obj sein.
GEOMcreate_normal_object (obj,scale)
Liefert ein Objekt (Datentyp GEOMobj) aus Linien, die die Normalen des Objekts obj repräsentieren.
GEOMflip_normals (obj)
Invertiert die Normalen des Objekts obj.
GEOMgen_normals (obj,flags)
Erzeugt die Normalen des Objekts obj (Typ GEOM_MESH oder GEOM_POLYHEDRON) und fügt sie dem Objekt an. flags kann auf 0 oder GEOM_FACET_NORMALS gesetzt werden.
GEOMwrite_obj (obj,fd,flags)
Schreibt ein Geometrie-File für das Objekt obj. Dabei repräsentiert fd (integer) das Output-device oder -file. flags kann auf 0 gesetzt werden.

In einigen Funktionen taucht der Parameter alloc auf. Er kann in den meisten Fällen auf GEOM_COPY_DATA gesetzt werden. Nur bei sehr großen Datenmengen ist GEOM_DONT_COPY_DATA zu erwägen.

Eine vollständige Liste der Funktionen mit Beschreibung finden Sie im Developer's Guide Seite G-13 ff.

Für Fortran-Programme stehen Ihnen entsprechende Funktionen zur Verfügung. Sie müssen jedoch in den Funktionsnamen den Präfix GEOM... durch geom_... ersetzen. Außerdem müssen die Objekte (Datentyp GEOMobj) als INTEGER definiert sein.