Lieber Steffen, Lieber Dietmar, Lieber Joachim (Alter vor Schoenheit!!!) ich schicke diese e-mail an Euch beide (Drei), da ja Steffen jetzt erstmal im Urlaub ist. Es geht alles ein bisschen durcheinander, da ich die Fragen aus Euren e-mails beantworten moechte. Steffen druecke Dich bitte ein bisschen ausfuehrlicher und praeziser aus, wenn Du ein Problem beschreibst!!!- Drei in waagerecht aufeinanderfolgende Punkte nuetzen mir recht wenig. Also hiermit habt Ihr jetzt eine Version in der Hand, in der ich die geometrische Anistropie und die zonale Anisotropie getestet habe. die Testfiles stehen unter ../krige/data/*. Das File main.prj enthaelt verschiedene Versionen, die Ihr nachvollziehen koennt. Dabei ist vor allem der manchmal verheerende Einfluss von anisotropen Modellen in Verbindung mit Gradienten zu sehen (OJO!). Wenn man genuegend Gradienten hat (GEOID) sind anisotrope Modelle praktisch ohne Wirkung auf das Vorhersageergebnis, ich bleibe bei dieser Aussage. Ich wuerde vorschlagen, dass Steffen, um ein Gefuehl fuer das Vorhersageverhalten zu bekommen, in diesem Beispiel mal versucht, verschiedene Gradienten bzw. Stuetzpunkte wegzulassen und dabei die Richtung der Anisotropie jedesmal ueber den moeglichen Bereich von 0 bis 199 gon zu variieren. Seltsame Offenbarungen werden jenem zuteil werden (aber weder die von Johannnes noch die von Mattaeus). Aber es ist alles erklaerbar. Files: kreispu.dat ( 9 Stuetzpunkte, kreisfoermig, einer im Zentrum) kreisgr.dat ( 8 Gradienten, kreisfoermig) 1.) Fehlermeldung beim Compilieren in readmode.c auf HP: Ich habe noch eine File readmoal.c hinzugefuegt. Das ist eine Kopie von readmode.c, nur dass ich dort die Makroaufrufe (pstr_2) zwischen den ASWBEL-Konstrukten geloescht habe. Ihr muesstet also readmoal.c in readmode. umbenennen und dann ganz normal kompilieren. Vielleicht geht es dann. Die Fehlerausschriften enthalten dann nicht den Namen des ausgefuehrten Programmes. Das ist der ganze Unterschied. Viel Glueck! 2.) Differentiation am Messpunkt funktioniert nicht: Naja, die ID scpfnn ist weder in meinem Sinne noch im Sinne der Doku richtig spezifiziert. Also OJO! alle beide: scpfnn filename.dat erste_Zeile letzte_Zeile SP_Bez SP_Hw SP_Rw SP_Hoehe SP_Zeit SP_Messwert Anzahl_Spalten Kopf_ja_nein Undef undef_min undef_max (also inclusive ID 25 Werte) Also Dietmar koenntest Du an der Stelle die DOku aendern, denn auf Seite 35 scpfnn ist keine Kopie!! Mensch, das ist doch meine ID :-)) 3.) Einige Unklarheiten mit der Doku: Dietmar koentest Du folgende ID's ueberpruefen und mir mitteilen, ob Du sie schon angepasst hast: scpfnn siehe 2.) method (ist zahr nicht wichtig, aber: Multiquadratik geht jetzt in Kernschaetzern auf Tiefpassfilterung faellt weg Bayes teilt sich in kurze und langwierige Versionen (Joachim weiss bescheid) akornn Die Modellfunktionen sind jetzt erweitert worden ( in der Dokumentation steht dann auch drin, welche mit welcher Nummer belegt sind. Es handelt sich v.a. um Kernschaetzer (z.B. Multiq = 10 sinc = 15) cmnnpp faellt weg suchnn habe ich Dir schon gegeben, alles geaendert? diffab Art_der_Diff Abst_im_Hw AB_Rw AB_Hoehe Ab_Zeit 3.) Zahlenformat: Es gibt eine ID zahfmt, wahrscheinlich hat sie Dietmar noch nicht implementiert. No sé. Dazu ein Hinweis: wenn die Exponentialdarst. gewaehlt ist, dann ist die Zahl der Nachkommastellen entscheidend. Das heisst die Insgesamtanzahl is' wurscht 4.) Wahl von Kernfunktionen Sie werden natuerlich mit neuen ID's ausgewaehlt und spezifiziert. Den prinzipiellen Aufbau und die Schmaeckerchen spare ich mir fuer die beruehmte DOKU auf. Hier nur die neuen ID's:(OJO! Dietmar) Bei Kernschaetzern muss ganz normal eine Kov-fktn wie immer spezifiziert werden. Es kommen zu jedem File (bisher akornn, mp1mnn usw) noch die vier mp3mnn hinzu mp3mnn Nr_desModells Glaettungsfaktor Teiler_duch_Hw Teiler_durch_Rw Teiler_duch_Hw und Teiler_durch_Rw sind Groessen, die z.B. bei der sinc-Funktion oder anderen gebraucht werden. Mit ihnen wird der jeweilige Koord.-unterschied in der Modellformel geteilt. In jeder Kernfunktion!!!! Bei Kernschaetzern gibt es auch eine Art "Kreuzkorr", deshalb muss analog zu amnnpp, bmnnpp jetzt eine NEUES(anderes) cmnnpp fuer Kernfunktionen spezifiziert werden: cmnnpp Nr_desMOdells Glaettungsfaktor Teiler_duch_Hw Teiler_durch_Rw (Erklaerung wie vorher) Also Steffen, Du hast eine normale Kov-fktn. und darueber hinaus die eben vorgestellten ID's zu spezifizieren, nicht mehr. 5.) Anisotropie 5.1) Modell- und Kernfunktionen Alle Modelle, wirklich aaaaaaallleeeeee sind in modell2.c (fuer 2D) programmiert. Alle Programme nutzen physisch diese Modelle. Es gibt keine Kopien. Im gleichen File sind auch gleichzeitig die anisotropen Modelle ausprogrammiert. Also am Anfang stehen die ganzen isotropen Modelle einschliesslich der Kernfunktionen, dann folgen ohne Unterbrechhung in der gleichen Reihenfolge die anistropen Modelle. Das muss so sein. fuegt man istrope Modelle (einschliesslich Kernfunktionen, ich mache jetzt keinen Unterschied mehr!!) hinzu MUSS die Konstante ANZISOMOD in define.h veraendert werden. (ANZISOMOD ist die Anzah der isotropen Modelle). Macht man das nicht werden im Falle der zonalen Anisotropie die falschen Modelle benutzt bzw. das Programm bricht mit der Meldung unspez. Funktion ab, wenn man Glueck hat!! Deine Frage nach den neuen Modellen mit geometr. Ansitropie ist ganz schoener Quatsch, da man ja eine Koor.-transformation vornimmt, um die istropen Modelle zu benutzen. Aber das weisst Du sicher selbst. Neue Kernfunktionen fuegst Du als Modelle ein, wie gehabt schaue Dir einfach meine Beispiele an. Uebrigens kann man die Formeln fuer die von mir programmierten Modelle der Surfer-Dokumentation (bei LEO-MAUS) entnehmen, ich verwende selbsterklaerende Namen. 5.2) Anisotropie in Kernfunktionen Nuja, dat muesste am Ende genau wie bei den Korr.modellen laufen. Es gibt aber beim jetzigen Stand etwas zu beachten. Erstens koennte man sich ja.... Neee jetz wollte ich Quatsch schreiben.... Also! Das geschieht einfacherweise ueber eine Koordinatentransformation. Die umhuellenden Programme habe ich jedoch noch nicht geschrieben (z.B qmn2grnn.c). Das is' nich ausserordentlich viel Arbeit, aber ich kann erstmal nichts versprechen, da sich auch viele kleine Sachen zu einem Gebirge auftuermen koennen. Bei genauem Vergleich der Krigedateien (kmn2grnn.c <-> kmn2grnn.c) koennte ein geschickter Mensch es auch selber machen, da man nur die Module hernehmen muss. Im install.all Script ist schon alles vorgesehen. Aber hier waere eine Absprache mit Joachim dringend erforderlich. Also kurz und gut mit dem jetzigen Stand koennt Ihr keine anisotropen Kernfunktionen benutzen. Das ist ja erst alles im Dezember entstanden, nachdem ich aus Aethiopien zurueck war. 6.) scheinbar schlechte Kondition, bei 3facher Reichweite Da hilft nur ein Blick auf die Matrizen. Auf alle Falle wird es so sein, dass die Teilmatrizen, in denen die ersten Ableitungen stehen, durchgaengig NULL sind. D.h. bei einem Stuetzpunkt sind das zwei Zeilen (Teile von Zeilen!!). Auf keinen Fall aendern sich irgendwelche Berechnungsansaetze, es werden immer die gleichen Algorithmen benutzt. Manchmal hift auch die Vergroesserung von DIFFQUOT in ablei2d.h; das werde ich auf alle Faelle ueber eine neue ID mit einbauen, da die numerische Differentiation des Modells( OJO! das ist etwas anderes als die numerische Diff. des Merkmals) manchmal ins Wackeln kommen kann. Da hilt machmal schon eine minimale Vergroesserung von DIFFQUOT. Das ist 100% eine wesentlich geringere Verfaelschung als die Additionskonstante. Hilft aber nur, wenn die numerische Differentiation wackelt. Ich ueberlege schon ob ich ein kleines Hilfsprogramm schreibe, (eigentlich habe ich es schon fertig, man musste sich nur ueber die ID und die Datenuebergabe einigen) das die numer. Ableitungen innerhalb der anderthalbfachen Reichweite mit den aktuellen Parametern berechnet, um sie dann darzustellen. So haette man eine optische Kontrolle ueber diesen Aspekt und koennte schoen regeln. 7.) Da ich schon immer JAVA lernen wollte, habe ich mich den letzten Monat hingesetzt, um mir die Grundbegriffe beizubringen. Dazu habe ich mir ein Beispiel gesucht. Ich habe die graphische Ausgabe des Fitting by MENZ programmiert, so wie es eigentlich in IDL geschehen sollte. JAVA ist natuerlich ein verdammt niedriges Level der Graphikprogrammierung. Bis zur Koordinatenleiste mit Beschriftung ist alles zu programmieren, ganz schoen hart. Ihr koennt dieses Prograemmlein nutzen, wenn Ihr Euch den Javainterpreter (java) oder gleich die ganze JAVA-Umgebung besorgt und installiert (http://java.sun.com/). Fuer MS-DOOF (respektive WINDOWS) gibt es sie uebers Internet. Ich habe sie auf meinem LINUX-Rechner auch. Ganz umsonst und laueft und laeuft.... Ich habe meinen LINUX-Kernel jetzt so uebersetzt, dass ich keinen Interpreter mehr brauche, das uebernimmt jetzt der Kernel. Daran koennt ich mich wieder begeistern. Also in einer naechsten e-mails bekommt ihr dann eine Fitting by Menz Version, in der dieses Prograemmlein aufgerufen werden kann. Kuemmert Euch!! Erwarte Antwort. 8.) Steffen, der gridder muesste normal funktionieren, Du musst natuerlich die neueste Version aus ../grille/util benutzen (ueberpruefe welchen Du aufrufst, loesche und ersetze ihn unter UNIX > which gridder Hasta ahí por ahora! Wahrscheinlich habe ich die Haelfte vergessen, aber ich bin ja nicht ausser der Welt. Nur am Ende der Welt. Testet schoen, auf dass die Programme fehlerfrei werden :-)) Viele herzliche Gruesse von Andree Heute ist Dienstag, der 18.08.1998 Ich konnte gestern die e-mail nicht schicken, da die Diskette, mit der ich das eingepackte File zu einem adaequaten Rechner trug, kaputt war. So ist das halt. Aber dadurch hatte ich genug Zeit, die versprochene JAVA-Applikation "fertigzustellen" und sie hier beizugeben. Sie ist unter ../grille/java/FitMenz zu finden. Uebrigens, Joachim deutete am Telefon an, dass man keine dritte Struktur spezifizieren kann, ES muss!!! gehen, es sind dieselben Algorithmen!!! Also jetzt zu den neuen features bei Fitting by MENZ. Da sind jetzt einige Aspekte veraendert worden, die vor allem auch Nikolai und Joachim interessieren werden. Auf alle Faelle muessten die Programme ueberall neu uebersetzt werden, damit es zu keinen Problemen kommt. Eine zentrale Rolle spielt jetzt die Datei "grtmpfit.tmp". Sie wird unter diesem Namen immer im aktuellen Arbeitsverzeichnis von vom aufgerufenen Programm angelegt. Das ist jetzt vielleicht (bestimmt) problematisch, da ich nicht weiss aus welchem Pfad kmnifnn.exe in IDL aufgerufen wird. Auf alle Faelle muessen dort Schreibrechte vorhanden sein. Also entscheidend ist, aus welchem Pfad das grille-Programm aufgerufen wird. Meine grille-Programme schreiben in diese Datei immer: 1.Zeile: es wurde schon automat. angepasst (11) oder nicht (10) 2.Zeile: Gesamtstreuung 3.Zeile: Nuggeteffekt 4.Zeile: Reichweite der ersten Struktur (das bezieht sich auf Isotropie und ein Stuetzpunktfile) Ich koennte natuerlich eine temporaere Datei anlegen, aber dann kommt man nicht unabhaengig von der Visualisierung, die ich ja aus meinem Programm direkt aufrufe, an diese Daten. Aber ich koennte mir vorstellen, dass Nikolai bei seinen Untersuchungen einiges automatisieren will, und dann muss er an die Unterschiede, die durch die automat. Anpassung gemacht werden, ran. Also in dieser Datei stehen dann schon die neuen Modellparameter, wenn eine automat. Anpassung gemacht wurde. Man muss sich also die Eingangsparameter immer aufheben. Also jetzt der Reihe nach. Erstmal zu den ID's wo die Reichweiten spez. werden. Wichtig ist ausserdem, dass bei Isotropie die maximalen Reichweiten (respektive kleine alpha) als gueltige Modellparameter zaehlen. Besetze also beide mit dem gleichen Wert, dann geht nichts schief. Das hat mit der Umstellung von alpha auf Reichweite zu tun. Tu' mir den Gefallen, Dietmar. Die ID fitmnz sieht jetzt folgendermassen aus: fitmnz Radienfilename flag_Boundary flag_autom_ANpass Maschwei flag_visu zu Erklaerung: Radienfilename - wie gehabt flag_Boundary - wie gehabt flag_autom_ANpass - 0 keine autom. Anpassung; 1 automat. Anpassung Maschwei - double Maschenweite fuer die Automat. Anpassung flag_visu - soll visualisiert werden oder nicht (0,1) Bei der autoAnp ist zu beachten, dass nicht mit allen Modellen gerechnet werden kann (nur mit Gauss und expon.), die anderen Formeln habe ich noch nicht (Es existiert eine Fehlermeldung). Im Falle der autoAnp werden in grtmpfit.tmp die bereits veraenderten Werte ausgegeben (de nuevo). Damit visualisiert werden kann, muss die Software natuerlich entsprechend uebersetzt werden. Dazu kann jetzt bei der Installation ausserdem waehlen, ob man mit oder ohne Visualisierung der Fehlerkurven uebersetzen will. In Abhaengigkeit von der Uebersetzung und von der Spezifikation von flag_visu sind vier Moeglichkeiten der Reaktion realisiert: 1.) uebersetzt mit Visualisierung; flag_visu=1 es wird versucht das Java-Programm FitMenzDemo aufzurufen und in Abhaengigkeit von der Rueckgabe dieses Javaprogramms wird weiterer Code ausgefuehrt (siehe weiter unten) 2.) uebersetzt mit Visualisierung; flag_visu=0 es werden emp. und theor. Kurven berechnet im Loesungsfile abgespeichert und das Programm wird verlassen 3.) uebersetzt ohne Visualisierung; flag_visu=1 Es gibt eine Fehlermeldung (Schreiben in *.log) mit Pause, danach werden emp. und theor. Kurven berechnet im Loesungsfile abgespeichert und das Programm wird verlassen 4.) uebersetzt ohne Visualisierung; flag_visu=0 es werden emp. und theor. Kurven berechnet im Loesungsfile abgespeichert und das Programm wird verlassen. Moeglichkeiten 2 bis 3 entsprechen dem bisherigen Stand, man konnte keine Anpassung der theoret. Kurve ueber die synthetischen Punkte vornehmen. Interessant ist also nur noch das Verhalten mit Visualisierung. Zur Visualisierung wird in eine temp.Datei die Radien, emp. und theor. Fehler sowie Anzahl der Schaetzpunkte geschrieben und an das JAVA-Progamm uebergeben. Dort wird diese Datei und grtmpfit.tmp eingelesen. Es stellt die Kurven dar und bietet ein kleines Menue, um Nuggeteffekt, Gesamtstreuung und Reichweite zu veraendern. Ausserdem erscheint ein rotes Feld mit der Ausschrift "autom. ANGEPASST !", wenn bereits eine autom. Anpassung erfolgte, ansonsten steht an dieser Stelle nichts. Wenn das rote Feld erscheint (flag_autom_ANpass == 1 ist Voraussetzung) sollte keine Anpassung der theoretischen Kurve (Fit) gemacht werden. Entweder OK oder die Neuberechnung der beiden Fehlerkurven (Cal), da ja die Kurven sich noch auf die urspruenglichen Modellparameter beziehen. Die Modellparameter in dem Menue sind aber schon die neuen autom. angepassten. [Ein Einschub zur Erklaerung: das grille-Programm hat nur einen Subprozess gestartet und wartet, dass dieser Subprozess (JAVA-Programm) beendet wird, um fortfahren zu koennen. ] Auf der rechten Seite erscheinen vier Knoepfe, die zur Steuerung des weiteren Ablaufs im grille-Programm dienen: OK : Abspeicherung der Fehlerkurven in der *lsg-Datei (resulv) und Ende, d.h. eventuell zurueck zur Oberflaeche Cancel: Keine Abspeicherung und Beenden des Programms, d.h. eventuell zurueck zur Oberflaeche Fit : zurueck zum Programm, Berechnung der theoretischen Fehlerkurve mit den Modellparametern, die im kleinen Menue eingegeben wurden und dann erneute Darstellung der neuen theor. und alten emp. Fehlerkurve (das ist dann eine erneuter Aufruf des JAVA-Programmes) Cal : zurueck zum Programm, Berechnung der theoretischen und empirischen Fehlerkurve mit den Modellparametern, die im kleinen Menue eingegeben wurden und dann erneute Darstellung der neuen theor. und neuen emp. Fehlerkurve Ein Betaetigen einer der vier Knoepfe bedeutet immer Beenden des JAVA-Programmes, waehrend dessen das grille-Programm immer nur wartet ohne beendet zu sein. Der untere Knopf mit der grille sollte nicht betaetigt werden, da noch immer komische Reaktionen zu verzeichnen sind, es sollte eine kleine Ueberraschung werden. Ist mir aber jetzt erstmal egal. Das musste eigentlich reichen, hoffe ich. Ich glaube, Dietmar, ein solch ausfuehrlich Beschreibung haettest Du Dir bestimmt von allen meinen Superprogrammen gewuenscht. HiHi.... Nun noch zu den Systemvoraussetzungen. Wenn Ihr mit Visualisierung uebersetzt, mussen einige Voraussetzungen erfuellt sein. 1.) Es muss ein JAVAinterpreter existieren und er muss als ausfuehrbares File gefunden werden!!! (http://java.sun.com/) 2.) In der Umgebung muss die Variable CLASSPATH definiert sein, in UNIX muss es eine exportierte sein. In der bash wird es zum Beispiel so gemacht: declare -x CLASSPATH="/usr/schnuffta/roettig/java/FitMenz" Etwas aehnliches muss auch in der autoexec.bat (oder wie dat Ding unter WindowsNT heissen mag) geschehen. Im speziellen brauch mein JAVAprogramm diese Variable, ich werte sie aus, damit meine Klassen an einem beliebigen Ort stehen koennen und damit die Images gefunden werden, das waere eigentlich nicht notwendig, aber ich wollte moeglichst viel ausprobieren. Die Klassen von FitMenzDemo muessen in einem Pfad stehen, der die Zeichenfolge "FitMenz"!!!!! enthaelt, der Ort ist egal. In CLASSPATH brauchen nicht die anderen Standardpfade zu stehen. Aber nochmal, wenn man meine Klassen in die Standardpfade kopiert geht es auch nicht, da die Zeichenfolge "FitMenz" fehlt. 3.) Ihr koennt die Klassen so benutzen, wie ich sie uebersetzt habe. Es ist Bytecode, den jeder Bytecodeinterpreter (java) verstehen sollte. Hier wird sich zeigen ob der Code wirklich maschinenunabhaengig ist. Aber bitte keine alte Version von Java benutzen. Ich habe mich an den neuen Standard gehalten. Leider kann man die Applikation nicht mehr ohne weiteres im Browser laufen lassen, da die Applikation auf die Platte zugreift, und das ist im Internet natuerlich fast strickt (Ausnahmen sind cookies) verboten. Ansonsten haette man eine schoenes Beispiel zur Praesentation gehabt. Bevor ich die Plattenzugriffen eingebaut hatte, konnte man das Programm als Applet und als eigenstaendige Applikation laufen lassen. Das verhindert jetzt der Bytecodeverifier. 4.) wenn die Visualisierung wegen der ungenuegenden Systemvoraussetzungen nicht durchgefuehrt wird, gibt es Fehlermeldungen; von mir und auch von JAVA selber also OJO! das Terminal duerfte immer ein bisschen stehen bleiben. Aber im Fall der Faelle, das heisst undefinierte Programmablaeufe: loescht das File grtmpfit.tmp. Wenn keine Fehlermeldung von JAVA kommt und trotzdem nichts erscheint dann werden hoechstwahrscheinlich die gifs nicht gefunden. Das habe ich noch nicht abgefangen. Man muss eben die Systemvoraussetzungen schaffen :-)=) 5.) Ich habe alles mit dem Beispiel Kehmstedt ausprobiert. Ihr braucht in ../grille/krige/data/kehm.prv nur die Pfade zu aendern. 6.) To Do: wenn ich Lust und Musse habe, werde ich einen Schalter zum wahlweisen Anzeigen oder Nichtanzeigen der Anzahl, der zur Berechnung der Fehler verwendeten Schaetzstellen einbauen. Sie stehen bisher nur im Loesungsfile. ----> diese Liste ist erweiterbar 7.) Mir ist noch mehr eingefallen. Die IDs in den input-Files fuer die Installation muessen!! um die ID visfit erweitert werden z.B.: visfit 0 0 bedeutet mit Visualisierung uebersetzen; 1 bedeutet das Herkoemmliche ohne Visualisierungsmoeglichkeit Bei Benutzung des html-Install-Skripts gibt es keine Probleme, dort ist dieser Punkt bereits eingefuegt. ALso OJO! mit alten input-Files. Katastrofengefahr! -> neuer Duden, sieht lustig aus; ist aber fuer mich kein Problem mehr, da die Spanier alles Verspanisieren: z. B. la catastrofe, man weiss immer, wie etwas geschrieben wird, naemlich genau wie man es spricht. Das is jut :-) 8.) weiter zu den Input-Files, die durch das HTML-Skript erzeugt werden. Ich bin mir jetzt nicht sicher, welche Input-Files ihr habt. Nein; anscheinend ist alles gut, ich wollte mich auf die Files im Verzeichnis ../grille/instinpu beziehen; sie sind so gestaltet, dass alle moeglichen Variationen installiert werden. Sie sind durch die Veraenderungen meinerseits natuerlich obsolet geworden. la catastrofe! Ich habe gerade eine Inkonsistenz zwischen install.htm und install.all entdeckt, das betraf die Bayes-Programme. Ich weiss nicht, wie das zustande gekommen ist!? Auf alle Faelle, waren die Beispiel-Inputs in Ordnung. Seltsam,Seltsam! Ich werde auf alle Faelle nochmal alles durchchecken, wenn ich ich mit der gewuenschten Bayes-Erweiterung fertig bin. Dann stehen dort, aktuelle Input-Files, mit denen man alle realisierten Moeglichkeiten uebersetzen kann. ALso wenn bei den letzten Versionen keine Bayes-Programme entstanden, dann durch besagte Inkonsistenz. Vielleicht habe ich mal ein "Suche-Ersetzen" gemacht!? Da ja die Vereinbarung besteht, dass ich nicht in die Projektdateien schreibe, musste ich diesen Umweg ueber eine neue Datei waehlen. Aber im Hinblick auf eine Modellanpassung mit allen Moeglichkeiten muesste wahrscheinlich das ganze mit IDL nochmal geschrieben werden und statt dem Minimenue Deine Oberflaeche zur Verfuegung gestellt werden. So war es von mir eigentlich mit den Wendelfunktionen geplant gewesen. Auf alle Faelle ist das ein Weg, der ausbaufaehig ist. Allerdings muesste man natuerlich die grosse Linie kennen. Nikolai kann clevererweise diese grille-Programme ohne Oberflaeche nutzen, um so viele Duchlaeufe z.B. durch ein awk- oder Shellskript zu automatisieren. Er braucht doch nur ein einmal erstelltes modulspez. Projektfile veraendern und ueber das Hauptprojektfile immer wieder dem Programm uebergeben. Da ich noch immer Speicherprobleme in meinen Programmen vermute, sollte die Stapelverarbeitung ueber das Hauptprojektfile erstmal vermieden werden. Also raus aus dem Programm und erneut starten, dann duerfte es keine Probleme geben. Eventuell wird nicht aller Speicher ordnungsgemaess am Ende freigegeben, aber das waere Voraussetzung fuer eine Stapelverarbeitung innerhalb eines einzigen Aufrufes von dem grille-Programm. Vielleicht geht es auch. Die Probleme bekam ich erst unter LINUX mit. Erst am Wochenende habe ich wieder eine Wanzenjagd hinter mir. Das Mistvieh hatte sich gut versteckt, deshalb bin ich jetzt etwas pessimistischer was die "Nichtnotwendigkeit" eines Kammerjaegers anbelangt. Das ist der Preis fuer "geniale" Programme. Achso, diese e-mail geht nur an Dich Dietmar. Gebe bitte dem Schwaetzer die neue Version. So noch einmal Ciau von Andree. Bitte installiert JAVA und nutzt die Moeglichkeiten, die ich muehsam programmiert habe. Heute ist Mittwoch, der 19. 08. 1998 Also noch nicht Ciau. Ich habe noch ein wenig fuer den Schwaetzer und sein BAYES-Kriging programmiert. Ich habe noch keine richtige Idee wie ich es im Installskript und ueberhaupt integriere, deshalb hier eine kleine Instruktion, wie er sich so eine Programm erzeugen kann. Ich habe fuer den ersten Durchgang des BAYES-Krigings 2D (bmn2irnn) das Einlesen eines Files programmiert. der unterschied liegt im File bunkt2d.c. Ermuss nur das File bunkt2df.c in bunkt2d.c umbenennen und dann uebersetzen. Die ursruengliche Version von bunkt2d.c heisst jetzt bunkt2dn.c. Also don't panic! Wie ich es am Ende realisiere, weiss ich noch nicht. Es ist die ausfuehrliche Form des B-Krggs. OJO! Dietmar: Fuer das Bayeskriging muessen immer zwei projektspezifische Projektfiles erzeugt werden. Das erste ist fuer die Berechnung von mue-Null T-null bzw. die Normalgleichungsmatrix N-null. Das zweite ist fuer den "richtigen" Datensatz. Im Fall der Faelle kann man z.B. wie ich es im Beispiel mache, zweimal das gleiche angeben, dann kommt das gleiche (nur die Varianz wird kleiner) heraus. Also vsel01 fuer den ersten Durchgang und vsel02 fuer den zweiten Durchgang. Dietmar, die zwei Berechnungsdurchlaeufe musst Du nicht verstehen, nur soviel dass ich das Programm nicht verlasse und somit meine angedeuteten Speicherprobleme loesen muss. In meinem Paradebeispiel funktioniert es zumindest. Aber ich bin noch nicht ueberzeugt. (ALso unter ../grille/bayes/data findet Ihr ein Beispiel mit dem es ging. Es muss dasselbe wie in 123mnz.lsg.vergl herauskommen.) Das File file.bay ist wie folgt aufgebaut: Fuer jeden Schaetzpunkt muss mue-null und N-null spezifiziert werden. Die Dimension ist wurscht, sie sollte nur mit dem im File-Zwei spezifizierten Trend uebereinstimmen, da bei Nichtuebereunstimmung der Dimension von mue-null und mue eine einfache Kollokation gerechnet wird. ALso im File steht fuer jeeeeedeeeeen Schaetzpunkt in der Reihenfoge seines "Auftretens": Dimension von mue-null Normalgleichungsmatrix-null;N-null im Format der meschach-Bibliothek mue-Null im Format der meschach-Bibliothek HINWEIS: ftp://ftpmaths.anu.edu.au/pub/meschach/meschach.html ich habe noch einige Files mit anderen Dimensionen beigegeben, somit duerfte sich das Format erschliessen. Wenn etwas nicht funktioniert, dann schaut im logfile nach. Wenn dort etwas wie eine Fehlermeldung von der meschach aussieht, dann habt Ihr im File einen Fehler gemacht. Meine Fehlermeldungen kennt Ihr ja (programm-name\n--->). :-) Wichtig ist, dass man im ersten Projektfile mindestens fuer ein Stuetzpunktfile, auch wenn es nicht gebraucht wird, die Spezifikation macht (es kann ja die aus dem zweiten Durchgang sein, ist also kein Extra-Aufwand). Um das File zu spezifiezieren gibt es eine neue vorlaeufige ID: bayes1 int-Wert filename int-Wert bedeutet einfach, dass es verschiedene Varianten des ersten Durchlauf geben kann (0: herkoemmlich; 1: mit Vorgabe von mue-null und N-null); mehr nicht. Am Ende von file8.bay gibt es einen kleine Hinweis von mir, ich habe es natuerlich noch nicht ueberprueft. Nun wirklich Ciau. Ich packe zusammen und trage erneut eine Diskette zum Rechner.