Hello and Happy New Year,
I've been away from the g3d work for a while on less interesting stuff (grant applications, hiring co-op students etc 
but I've now had a chance to try out the revisions made by AV - particularly in r3.out.v5d
We have been running production data through the system partly for a presentation tomorrow, but also to get ready for a trade show (Mineral Exploration and Mining) later this month in Vancouver, Canada. We will be high-lighting Grass and related tools at our booth. The block of (real) data I've been working with unfortunately has topographical features that as as close to N-S as makes no difference! This resulted in lots of fun 
trying to check if the N-S axis was being reversed!
1) We can confirm that work done by AV in r3.out.v5d has fixed the problem with non-square (x dim = y dim) grid3s being exported incorrectly. r3.showdspf and vis5d now have equivalent display.
2) The Gmakefile for r3.showdspf.openGL in 5.0.0 exp is missing -lGLw and -lXm in the OGLLIB line. This has been fixed in the release source, but not in the exp.
3) Importing 2d elevation data does not result in the same display as importing equivalent data with a 3d site approach. I'm fairly sure the fault lies in s.vol.idw - (yes, I know it was recommended that we use s.vol.rst, but I have yet to get the 3d one to run without crashing.) For a smooth 3d block model the idw approach is good enough for testing. Both Z (elevation) and Y (northing) are reversed when displayed after importing. With the storage order being the reverse of physical coordinates for Y and Z its not hard to accidentally reverse the storage in a loop. I think AV may have done two fixes in the code that cancelled each other I'll check that in more detail and report later.
4) r3.mask is crashing as follows:
r3.mask maskvalues=-1 grid3=test.20-t
FATAL ERROR: G3d_getDoubleRegion: error in G3d_getTilePtr
I have not had a chance to start exploring the error message. It may be a bug in the operator. Since I have not been able to create a 3d mask, so that may be why s.vol.rst is failing and complaining about too few points?
I have not entered any of these as bug reports because I'm actively working on them, and in the spirit of Open Source hopefully I'll have a fix to post with the bug!
Cheers,
John Harrop
3) Importing 2d elevation data does not result in the same display as
importing equivalent data with a 3d site approach. I'm fairly sure the
fault lies in s.vol.idw - (yes, I know it was recommended that we use
s.vol.rst, but I have yet to get the 3d one to run without crashing.)
do you use the 5.0.0 version or the one in exp ? Where does it crash and
what
it says? It used to run OK although Jaro recently reported that the
version
in the 5.0.0 release gives segmentation fault if the sites
are not exactly in the format x|y|z|#n %value (for example sites
x|y|z|%value
make it crash with segmentation fault which is obviously a bug but we
did not have
time to look into it).
thanks,
Helena
For a smooth 3d block model the idw approach is good enough for
testing. Both Z (elevation) and Y (northing) are reversed when
displayed after importing. With the storage order being the reverse of
physical coordinates for Y and Z its not hard to accidentally reverse
the storage in a loop. I think AV may have done two fixes in the code
that cancelled each other I'll check that in more detail and report
later.
Now the recent panic for getting products out is over I've had a chance to look at the cause of the problem a little more. If I narrow down the region and make it completely sub-surface, the program completes without any problems. We are working with a medium size regular block model 134x90x60 with cells of varying size. Some of the cells, perhaps 10%, are air and have null values. I've tried with and without the air blocks. I would prefer to exclude them from the site file altogether, but I thought that perhaps s.vol.rst was failing when it tried to interpolate in a region of all or mostly air.
I'm now trying a 20x95x45 block well inside our data, which currently includes -1 values for air cells. (All subsurface values are positive). The processing reaches about 26% before failing with a segmentation fault. I may well be failing to set some parameters correctly, but that shoudl not be causing a segmentation fault.
I gather from the man page that s.vol.rst is not doing 3d masking, but rather projecting a 2d mask through all the depths. Is there a way to mask cells above the surface?
Command line and messages follow:
-----------------------------------------
s.vol.rst input=block3.chg elev=rst.test.2
Warning: some points outside of region -- will ignore...
Warning: strip exists with insufficient data
Processing all selected output files
will require 7600 bytes of disk space for temp files
Warning: there are points outside specified region--ignored 450036 points
Percent complete:
Warning: taking too long to find points for interpolation--please change the region to area where your points are
Segmentation fault
-----------------------------------------
Regards,
John Harrop
Helena wrote:
3) Importing 2d elevation data does not result in the same display as
importing equivalent data with a 3d site approach. I'm fairly sure the
fault lies in s.vol.idw - (yes, I know it was recommended that we use
s.vol.rst, but I have yet to get the 3d one to run without crashing.)
do you use the 5.0.0 version or the one in exp ? Where does it crash and
what
it says? It used to run OK although Jaro recently reported that the
version
in the 5.0.0 release gives segmentation fault if the sites
are not exactly in the format x|y|z|#n %value (for example sites
x|y|z|%value
make it crash with segmentation fault which is obviously a bug but we
did not have
time to look into it).
thanks,
Helena
For a smooth 3d block model the idw approach is good enough for
testing. Both Z (elevation) and Y (northing) are reversed when
displayed after importing. With the storage order being the reverse of
physical coordinates for Y and Z its not hard to accidentally reverse
the storage in a loop. I think AV may have done two fixes in the code
that cancelled each other I'll check that in more detail and report
later.