Jest: Frequently Asked Questions
(alright, not so frequently asked questions)
-
Who should use Jest?
-
What is a good solver to start with?
-
Why float rather than double as the default for real numbers?
-
How do I set my classpath?
-
Why not having a single Jest package?
-
Why does Jest not include an Rn vector and a matrix multiplication operator?
We expect our first users to be geophysicists who know Java or are
willing to learn it. Ideally the user's works on small to medium sized
research problems. In the near future, I believe large-sized
research will become feasible as Java's overall performance improves
and we built efficient implementations of Jest components (e.g. an
out-of-core Rsf with methods that call native Fortran subroutines).
Ideally applied mathematicians would join the development effort and
implement sophisticated solvers. Possibly these mathematicians would
collaborate directly with a geophysicist.
We hope that programmer's and researcher in scientific and computational
fields besides geophysics would take advantage of the package by extending
it to their specific vector and operator implementations.
We can envision, a Matlab interface to Jest (we believe Jest can do
anything Matlab can do) or a mechanism in which a
programmer supplies an operator's image function in form of an operator
and otherwise assembles his overall inversion strategy through a graphics
user interface. Such extensions would make it possible for a researcher
to use Jest without learning Java. However, at this point, we do not
intend to implement these extensions.
We make the software available to anyone. Jest is not a frozen finished
product, but a proposal and an open environment. Anyone who wants to help
make Jest more useful is welcome to help.
The simulated annealing solver might be a good place to start
since it works for very simple operators. I have the feeling there
are better simulated annealing algorithms out there.
Next solver might be the CGSolver that requires a linear operator.
Obviously, we would like to have the additional precision that double
number representation offers.
I plan to change to a double version (I hope a script can simply
translate the future double version to a float version).
However, for seismic imaging
we prefer floats since our data set size already stretches our storage
capabilities (A seismic 3-D data is at least several Gigabytes large).
Since my primary applications concern seismic processing, I implemented
a float version first.
I have the package stored in /home/matt/jest. Consequently, I add
:/home/matt/jest/: to my classpath.
All the import statements then define the
packages relative to that directory,
e.g. /home/matt/jest/jam/vector/Vector.java is found by having a
classpath /home/matt/jest/ and by having an import statement
import jam.vector.*;.
If you need an import statement
import jest.*; or
import jest.jam.*;
you do something different from what I do in my setup. I am not sure
what though.
Obviously including and searching many packages is ugly and inefficient.
However, Jest currently uses many packages
(jam.vector.*; jam.operator.*; etc).
I will reduce the number of packages for standard classes in the future.
However, controversial or prototype classes I will contain in individual
packages so that they can easily be exchanged, left out, or deinstalled.
I believe this modular approach will make Jest more attractive to more
users. At this early development stage almost all classes are controversial
and prototypes. Consequently, I have many packages. As these packages
mature I will unite them to bigger bins.
Additionally, I believe in reproducible research (for more information
visit the corresponding SEP
web page).
In my current design a research project and its document map into
individual Java packages. I will explain this soon somewhere else.
I had matrix multiplication and Rn vectors in an earlier version but
I have not implemented them yet in the current package. Honestly,
Rn does not appear in my research. I usually use a more sophisticated
package Rsf that includes Rn. It adds descriptions of the physical
dimensions to Rn.
Matrix multiplication again is not an operator I encounter in my research
in its pure form. Our linear operators are such sparse matrices, that we
never implement them as explicit matrices.
However, I agree, it would be nice to have these packages. So if you
implement them, store them in an individual package and I will add
it to my distribution. That is easy because of the modularity of
Jest's packages that I discussed above.