From martin@gpista1.physik.uni-karlsruhe.de Fri Feb 28 06:42:01 PST 1997
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	[nil "Fri" "28" "February" "1997" "15:07:24" "+0100" "martin@gpiwap1.physik.uni-karlsruhe.de" "martin@gpiwap1.physik.uni-karlsruhe.de" nil nil "RE: SeismicJava = JOON" "^From:" nil nil "2" nil nil nil nil]
	nil)
Received: from nz11.rz.uni-karlsruhe.de by spur.Stanford.EDU with ESMTP
	(1.39.111.2/16.2) id AA053010899; Fri, 28 Feb 1997 06:41:39 -0800
Return-Path: <martin@gpista1.physik.uni-karlsruhe.de>
Received: from gpista1.physik.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de with SMTP (PP); Fri, 28 Feb 1997 15:07:35 +0100
Received: by gpista1.physik.uni-karlsruhe.de
	(1.37.109.11/16.2) id AA084408844; Fri, 28 Feb 1997 15:07:24 +0100
In-Reply-To: <28764808@toto.iv>
References: <59751797@toto.iv>
	<199702251925.LAA19338@hessen.Stanford.EDU>
	<61255297@toto.iv>
Reply-To: martin.karrenbach@physik.uni-karlsruhe.de
X-Mailer: GNU Emacs 19.28.1, VM 5.74 (beta)
X-Organization: Geophysical Insitute, Univ. Karlsruhe
From: martin@gpiwap1.physik.uni-karlsruhe.de
To: Matthias Schwab <matt@spur.Stanford.EDU>
Cc: joel%spur.Stanford.EDUmartin.karrenbach@gpisgi1.physik.uni-karlsruhe.de
Subject: RE: SeismicJava = JOON
Date: Fri, 28 Feb 1997 15:07:24 +0100


JAM sounds great !!! I would pick it.

Joel, I owe you a more complete answer to the idvi problems you
have and I will put a complete book example out over the weekend.
In short, my pstexpen does more or less the same thing as yours. 
bibliography stuff (sep.bst,bibunit) also seems to work 
as usual with hyperref. So far I am not using collapsing paragraphs.
I am using activeplot solely (no preprocessing of stuff as opposed
to latex2html.)


>>>>> "Matthias" == Matthias Schwab <matt@sep.stanford.edu> writes:
    Matthias> This letter got longer then attended. I tried hard to
    Matthias> think about opportunities how we can pull off a
    Matthias> promising Java collaboration.  We need to plan this
    Matthias> carefully since we both saw our C++ project fail,
    Matthias> partially because of lack of direct cooperation and
    Matthias> interaction of the main authors .... I might have a
    Matthias> solution to that problem though ...

I agree totally, but this time there is a solution, I think.
( I actually did not find a single soul here that was willing to invest
time in C++, let alone C++ AND F90. ) Luckily there seems to be no
shortage in JAVA knowlegeable and willing students.

    Matthias> She will give birth in Houston, I am afraid
    Matthias> *smiles*. She does trust those Houstonian
    Matthias> Doctors. Nobody seems to care much about what I think
    Matthias> ... the worst part of the morning sickness period is
    Matthias> over (she does not throw up anymore on patients of hers
    Matthias> ... ;*)
great :-)

    Matthias> I hope you understand that I will have to husband my
    Matthias> time and energy this summer very carefully, since I need
    Matthias> to help Pascale and eventually graduate before I turn
    Matthias> grandfather ;*)
even greater :-)
When is yours and Pascale's due date ?
When will you be in Houston then ?

    Matthias> Collaboration:

    Matthias> With respect to time we need a few more weeks before we
    Matthias> distribute stuff. So the timing, I think, is not
    Matthias> perfect. We have plans to rewrite some interfaces and
    Matthias> the indexing of Rsfs. But we are ready to make an
    Matthias> official release in about 1-2 months.
    Matthias> As you know, Long distance collaboration poses is not
    Matthias> easy (as we know from our previous C++ projects and
    Matthias> cooperation with Rice). This is especially true while we
    Matthias> are still changing some of our framework.  (I think the
    Matthias> reason we got (this time) as far as we did, was because
    Matthias> Joel and I constitute a small group with a overall
    Matthias> joined vision of what we were creating
    Matthias> ("no-efficiency-yet, good-interface, reflecting
    Matthias> mathematics, flexible" kind of software) and a good
    Matthias> complementary ability. I was also able to protect our
    Matthias> project from early criticism and deadline pressure. I
    Matthias> would like to keep it this way for at least 2 more
    Matthias> months. Do we share a vision on what Jam should be? What
    Matthias> are your goals when collaborating on this project?

I agree here in all points. Maybe you misinterpreted my remarks about
people here are interested in optimization and efficiency of java.
They are, but for creating their own compilers. This is not what this
project is about! 
We DO share your vision what this project should be about:

    Matthias> ("no-efficiency-yet, good-interface, reflecting
    Matthias> mathematics, flexible" kind of software) and a good
    Matthias> complementary ability.

The current main thrust behind the Karlsruhe side is:  

 1) Is it possible to solve large scale numerical problems using parallelism 
    within pure Java ? 
 2) Can we avoid ugliness using pure threads and remote method invocation ? 
    how far can we incapsulate all of the parallism ?
 3) Efficiency and optimization is not an issue, 
    cleanliness, good-interfacing and flexibility are.
 4) We don't want to reinvent whatever you have done already !


I suggest first a loose, then a closer collaboration (how salomonic:-) :

    Matthias> (1) loose collaboration

    Matthias> We would, of course, be happy if you down load and use
    Matthias> our software as soon as it is released. We can make a
    Matthias> sneak preview package available if you want to start
    Matthias> within the next 2 weeks. And we, of course, want to have
    Matthias> a look at your results and fix our original version, but
    Matthias> there would be no guarantees and no obligations.  Since
    Matthias> the distance to Karlsruhe makes it hard to negotiate
    Matthias> differing views etc., such a loose collaboration might
    Matthias> the most practical format.

In order to get the student here into the matter quickly we would be \
happy if you could pop out one reproducible document with one working
example as soon as possible. Eg. a simple velocity inversion with hestenes.
We could then try to see how the parallelism can be put in.
At the moment, we have some basic classes of which portions are 
living in different places (machines). The class knows how to communicate
and when to syncronize. The list of places is a system property.
I would think there would be a parallel Rsf and hopefully only minor
modifications in the operator itself.

For this stage only your main structure should be in place,
but everything else could change at your will.

We probably play around a lot at this stage and then come back to 
you with a hopefully acceptable solution for both sides.

At which point I would hope we can do a closer collaboration.
Then I would also CLEARLY define how the other Matthias
has to proceed, in what time frame and agree on the interfaces.
(The student has about 6 month here to do his Masters Thesis,
so that we need to be well organized and structured on the Karlsruhe side.)

    Matthias> (2) closer collaboration

    Matthias> Closer collaboration is feasible if we can define a
    Matthias> clear software interface between the areas we are
    Matthias> working on (basically encapsulation). The interface has
    Matthias> to cleanly separate the work at SEP and the work at
    Matthias> Karlsruhe.

    Matthias> To illustrate my point, let us assume you you were to
    Matthias> work on graphics. In this case, we only would need to
    Matthias> agree on a data format (e.g. Rsf - SEPcube) and one
    Matthias> group could develop how to display things as the other
    Matthias> group (entirely independent) could work on the
    Matthias> processing. From time to time we would release new
    Matthias> versions to each other. We only would have to ensure
    Matthias> that the "interface" (in this case the Rsf
    Matthias> implementation) does not change.

This should be done in the longer-term future, ie. when Rsf is fixed.

    Matthias> Another example of separate (encapsulated) research
    Matthias> could be a data base solution to seismic data. We would
    Matthias> add a method to the Rsf class that would read from a
    Matthias> database. How the database store the data, how databases
    Matthias> exchange data etc is all hidden from the processing
    Matthias> software.  I have some ideas about such a database,
    Matthias> mostly revolving around Java's jdbm (sp?) package.

That clearly would be desirable and maybe could be another
computer science / geophysics project.

    Matthias> Maybe you can think of alternative projects that could
    Matthias> be easily encapsulated and that you are interested in!?
You mentioned already graphics and database support. 
These are nice to have at some point.
To make it more universal for other geophysical people,
methods to read and write segy. 


    Matthias> I am leery to optimize a software package to early (look
    Matthias> at the citation on my home page). I am also afraid to
    Matthias> complicate the simple standard Java code we currently
    Matthias> write with parallelization constructs that might be
    Matthias> different from future standards for parallelization of
    Matthias> Java.  Obviously, all this is not a problem if we can
    Matthias> encapsulate the parallelization.

As stated above optimization and efficiency is not an issue. 
It is basically a feasability study for how to introduce and hide
parallelism for large-scale numerical realistic problems.

    Matthias> I suggest, you talk with your Java expert. Show him our
    Matthias> code.  Explain him our constraints. Let him address our
    Matthias> concerns and let him make a suggestion on how to
    Matthias> implement parallel code for this framework. You may want
    Matthias> to ask him if there are alternative "encapsulated"
    Matthias> projects that he might be interested in. I would love to
    Matthias> look at his suggestions and we take it from there.

    Matthias> Pstexpen: Do you have a pstexpen that produced
    Matthias> encapsulated Postscript?  Where can we get a copy if you
    Matthias> do? (idvi works for us now after we found that the
    Matthias> bounding box statement seems to want integers always).

see above.

    Matthias> HyperRef: We have not installed it yet, since it
    Matthias> conflicts with our reference work. But we will install
    Matthias> it soon and have a flag to choose between good
    Matthias> references or wonderful links. If you find a solution to
    Matthias> how to integrate both, please let us now!

I don't quite understand, can you give me an example ? 
I think I went for "links to the usual in-text references".



    Matthias> Schedule:

    Matthias> My schedule is (as usual) probably unrealistic,
    Matthias> especially after Joel leaves in about 2 weeks.

    Matthias> Here is what I want to do next:

    Matthias> (1) I want to get things wrapped up until report time (a
    Matthias> release of a reproducible document (web and paper
    Matthias> version), a tar file of all the code, etc. This may take
    Matthias> a bit longer than report time, but report time is our
    Matthias> current goal. Maybe even preparing something for a
    Matthias> publication.  (Biondo suggested to present something to
    Matthias> a SIAM meeting this summer, but this is not yet
    Matthias> official).
I would not rush with it, rather get it in a solid state where YOU
are happy about it. Time for press releases will come for sure later :-)

    Matthias> (2) Afterwards, I am planning to present Jam (our name
    Matthias> under consideration: java and applied mathematics) to
    Matthias> Symes and Gockenbach: I hope that they want to
    Matthias> collaborate, too. I will try to collaborate closely (if
    Matthias> we can find an encapsulated division of the software
    Matthias> responsibility, e.g. they could write solvers) or
    Matthias> loosely. However, they may have too much stake in the
    Matthias> C++ project already.
I am afraid you have a hard time to convert them from C++.
This is what I have found here:
	C++ lovers pity Java lovers
	Java lovers pity C++ lovers

    Matthias> (3) Furthermore, I want to finish my thesis within the
    Matthias> Jam framework.  I am about to do some realistic
    Matthias> problems. I hopefully have a chapter coded this weekend
    Matthias> (my first).

good. when are you graduating ? Before summer ? Before Christmas ?

    Matthias> (4) If possible, I would like to find a junior SEP
    Matthias> student (maybe 2) to use and continue the software
    Matthias> package. Ideally, we would work on a joint small
    Matthias> research project that we would implement in Jam.  I
    Matthias> would like to hand-pick that student and I am currently
    Matthias> unsure who to choose.  I want someone o with a similar
    Matthias> vision of Jam's goals o with good presentation skills o
    Matthias> good programmer Of all the SEP students, nobody seems to
    Matthias> fit the bill quite right. I will raise the issue with
    Matthias> Jon as soon as I have some geophysical results.

I would definitely not rush this either. Maybe one of the incoming
students can be selected to fit your criteria. The current students
will only be converted once they see the geophysical benefit and
even then I am not sure ...
Most important don't let Jon force other students to work with it,
or push your JAMmed time frame.

    Matthias> (5) Jon is considering hiring a undergraduate student
    Matthias> for the summer.  We have not considered any details. A
    Matthias> Stanford undergraduate may be available for long term
    Matthias> collaboration and I can interview them and choose them
    Matthias> myself.  However, Jon and I agree that I should attempt
    Matthias> to finish my PhD soon.  There might be more Jam work
    Matthias> after my graduation.
that should be a good route.

    Matthias> Joel is probably leaving within the next few weeks (2
    Matthias> maybe 3). It probably won't be realistic to have
    Matthias> Matthias visit while he is still here (Especially since
    Matthias> we are already gearing up for the SEP meeting).

That would definitely be too soon for us.
We should study your prototype example and have a parallel suggestion
before he would come. Then at Stanford discussion about further strategy 
could be done directly with you, if you like.

    Matthias> About Jon (or the management abstract):

    Matthias> If Jon were to ask me, I would tell him exactly what I
    Matthias> said in this letter: This summer, I have to husband my
    Matthias> time and energy to finish my thesis.  Long distance
    Matthias> collaboration is difficult and SEP should consider
    Matthias> putting its resources into local-longterm collaboration.
    Matthias> However, since Karlsruhe has great Java expertise, and
    Matthias> since you know SEP and SEP applications, we should
    Matthias> seriously consider your offer.  In summary, if we find a
    Matthias> good software separation so that despite the long
    Matthias> distance, both groups can work on "their" parts of the
    Matthias> code independently, then I would be all in favor of
    Matthias> it. I am looking forward to hearing from Martin what
    Matthias> kind of software separation his graduate student has in
    Matthias> mind.

That is fair.



What do you think ? Hope to hear soon from you.


Bye for now.

	Martin


