Thanks a second time,
Bill Hibbard wrote:
Hi Olav,
. . .
This is no problem with flow rendering. With the Ball data this error in
the far field occurs only one time. I have used the picture only for
clarification. There are two problems. The cutplane arround the surface
shows always errors (see error_in_cutplane_rgb.png).
This isn't really an error - just the resampling quantization.
Resampling to a GriddedSet the edges of the no-data area will
always look gridded ike that. The only suggestion is to increase
the resolution of the grid, to make the grid teeth smaller.
Error was the wrong word. What i meant was, that an error in the
visualized plane occurs and to ask if there is a possiblility to
overcome or reduce it with the built-in functionality (Increasing the
grid resolution doesn't work. I have tested a plane with 1,000,000
points and the problems are always there). My idea was also that this is
a problem with the quantization and the no-data area. But this problem
comes in place near the surface. The other problem is the error in the
far field arround the no-data zone that is exemplary shown in the
picture "error_in_cutplane.png" from my first email. The area with no
data should not effect the quantization of this regions.
. . .
I can send you the test program. That is no problem. Problem is the data
file. The file with the ball is also now problem (i have send it to you
several month ago "Sphere.plt"), but their you can see normally only the
error near the surface. With the data for the complex geometries it is
different. I am not allowed to send out this data. Let me hnow, if you
are interested in the test case with the ball. If you don't have the
data file anymore then i will send this also (arround 4MB compressed) to
you.
I no longer have the Sphere.plt file. I'll look into the problem
if you send me the file plus a program I can run that generates
the problem. Please don't CC visad-list since the file is big.
One last question. Due to the problems with the cutplane i thought about
a resample method that uses an analytic plane to cut through the
volume. The output grid then will have the intersection points between
the analytic plane and the grid edges as it's domain. Where do you think
is the best place to do this? Generating the cutplane grid in a
preprocessing tasks and then use FlatField.resample() or should it be
better to overide the resample method.
I assume you mean a plane specified by an equation like
ax+by+cz=d by 'analytic plane'. This is an interesting
idea, although the implementation will be a bit tricky
(as you say, finding the intersection of edges of the
Irregular3DSet's tetrahedra with the plane, then
interpolating values between the vertices at each end
of those edges). This wouldn't fit naturally in resample().
I'd suggest just calling FlatField.getDomainSet() to get
the Irregular3DSet, then get its set.Delan (which will be
its Delaunay), then use Delan.Tri and possibly Delan.Edges
plus set.getSamples() to do the computational geometry
to derive the cutplane grid as an Irregular3DSet with
manifold dimension = 2 (the intersection of edges of the
Irregular3DSet's tetrahedra with the plane will not produce
a GriddedSet).
You are right with your assumption for the analytic plane. The idea to
override the resample method comes in mind while it would be easy to
calculate the range values at the same time as calculating the point
values on the plane. The time consuming task is always finding the
involved vertices, edges, and cells (tetrahedra, hexahedra, etc.). if i
generate a grid in a pre-processing task and pass it into resample then
the code has to make the search twice. Once by generating the grid and a
second time during the resampling. the output will always a
Irregular3DSet with manifold dimension = 2, that's right. But if i write
it in a pre-processing task i would use the original data. I have to
deal with structured multiblock grids and unstructured grids with any
type of cell (tetrahedra, pyramid, prism, hexahedra, and a mixture of
them). If i use the data from an Irregular3DSet this cells have first to
be decomposed into tetrahedra that results in a large amount of cells.
For hexahedra it is a factor between five and six (mostly = 6) for the
cell number. Another reason is to present the user a grid view of the
original data. Grid quality has a mayor impact on computing time and the
accuracy of the result. I would like to do this work in a way that fits
into VisAD, so that, if no law or contract restrict it, the code can go
into VisAD under LGPL. At this point i have a little different question.
Are there any Use Case diagrams available, to see the interaction
between the diferent classes and methods, for VisAD? This would reduce
the amount of time to find the right methods that has to be extended for
my requirements.
At least to Bill. I will prepare the testcase and send it with the data
file to you.
Olav
Good luck,
Bill
