Having ignored VisAD after testing DisplayTest in the ~bellenot/jdk1.2beta4/visad/examples, we discovered some of the other sample programs require more than just the default setup.
GoesCollaboration is the next program to inspect. The data for this program is not part of the visad tar file we downloaded at the beginning of the year. The files data_obs_1.dat, data_sou_1.dat and goesrtcf were obtain through the ftp site listed in the README file in visad/paoloa (the location of GoesCollaboration.java).
GoesCollaboration requires a Fortran compiler and a C compiler as well as Java. The program uses JNI to access the data files and do some computations. This native code apparently limits the program to only SPARC solaris at the moment. (The C and fortran code end up in a shared library libGoesCollaboration.so which is loaded at runtime in the server side with the command
System.loadLibrary("GoesCollaboration");
and hence the library must be found by the loader. The usual way to
do this is with the LD_LIBRARY_PATH environment variable. We have
created client and
server
sh script wrappers to run these variable and run GoesCollaboration.
As a guess, it looks like only the server side of GoesCollaboration has to be run on SPARC solaris but I haven't checked this. I am also not sure why the native code limits one to solaris. My guess is that the makefile isn't set up to make win32 dll's and perhaps there is endian issues in the fortran code. But again this is just guessing.
Because of the use of RMI, the serialization of the VisAD java objects must match versions. By default, this seems to require the use of the same class files.
Our next goal is to get an example program which is independent of SPARC solaris. Since the main use of JNI in GoesCollaboration is to read data. I modified this program to Coop0.java which has its data manufactored by the Helix parametric curve. There are several interesting points about Coop0.java, perhaps the most surprising is that it gives points instead of lines. But we will fix that in the next version Coop1.java. Here are the other points:
I latter found out why the Point mode. I was thinking the Linear61 set I used for domainT implied a linear topology but apparent it does not. Coop1.java uses a Gridded3DSet for the Data constructed so it is a one dimensional manifold in 3 space.
Gridded3DSet has many constructors one each for the manifold dimensions 1, 2 and 3. The manifold dimension is 1 if the data object is a curve, 2 if the data object is a surface and 3 if it fills a volume. Coop1.java uses the 1-dimensional version and Coop2.java uses the 2-dimensional version.
After modifying Coop1.java to use the Gridded3DSet, it turned out that the setupClient routine no longer worked. A certain amount of experimentation yielded the current working version. There was also a number of variables to remove like domainT and parametricCurve.
The next version Coop2.java plots a torus to test the Gridded3DSet with manifold dimension equal to two. There are now two sliders and they control the number of sample points used in drawing the torus.
It is obvious that we need an "interface" to generate these Gridded3DSets. But since the number of data points and/or the structure of the curve/surface is changing, the old Curve3f idea doesn't quit fit. A good exercise for the student is to fix this obvious need.
There are two additions to note for Coop2.java. The first is that even though the samples are two dimensional for the torus, the samples are passed as a one dimensional array. The second was the automatic scaling of the axis distorted the torus vertically by a factor of three since x and y range from -1.5 to 1.5 but z only ranges from -0.5 to 0.5. We removed the distortion by a setRange on the ScalarMap for the ZAxis.