I have not commented out both gvl_align_data lines (#684 and #1009) in gvl_calc.c, but fixed variable initialization in trunk r54866. Please test.
Markus M On Fri, Jan 11, 2013 at 10:33 PM, Michael Barton <[email protected]> wrote: > Perhaps Windows and Linux--and earlier versions of OS X--ignore the code. > > The header for gvl_calc.c says that the author is Tomas Paudits (February > 2004). Does anyone know if he is still around to ask? > > Michael > ______________________________ > C. Michael Barton > Director, Center for Social Dynamics & Complexity > Professor of Anthropology, School of Human Evolution & Social Change > Arizona State University > Tempe, AZ 85287-2402 > USA > > voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) > fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) > www: http://csdc.asu.edu, http://shesc.asu.edu > http://www.public.asu.edu/~cmbarton > > On Jan 11, 2013, at 1:18 PM, Helena Mitasova <[email protected]> > wrote: > >> >> On Jan 11, 2013, at 2:48 PM, Anna Kratochvílová wrote: >> >>> Hi Michael, >>> >>> On Mon, Jan 7, 2013 at 7:57 AM, Michael Barton <[email protected]> >>> wrote: >>>> So I found a change that would make volumes visible again a week ago. >>>> Anyone have any thoughts about this? Do we need the function/procedure >>>> that sets the memory pointer for volume displays? Or can we simply get rid >>>> of it? Is it needed for Linux? Windows? Any thoughts about what happens >>>> without it? >>> >>> I can confirm that removing those two lines does no harm for me >>> (Linux). However it's clear that we cannot just leave them out without >>> understanding why they are there. Can anyone (for example Glynn) think >>> of a reason why this code is crashing on Mac and not on Linux (no idea >>> about Windows)? >> >> I just tested it on Windows 7 with WinGRASS6.4.3RC2 and I am happy to report >> that it works OK >> - both isosurfaces and crossections. >> >> However, in the same WinGRASS6.4.3.RC2 there is a problem with the path to >> cellheader in G3d_read_window, >> so r3.info and g.region rast3d=myvoxel gives an error that the region is >> invalid. >> >> Also, I finally got a laptop with MacOSX10.8 and I can confirm that in >> GRASS6.4.3RC2 binary >> posted Michael isusrfaces crash wxGUI. I will try to compile myself but I >> expect the result >> to be the same given that it crashed for William as well. >> >> Helena >> >>> And why removing of realloc helps? >>> >>> Regards, >>> Anna >>> >>>> >>>> Cheers >>>> Michael >>>> ____________________ >>>> C. Michael Barton >>>> Director, Center for Social Dynamics & Complexity >>>> Professor of Anthropology, School of Human Evolution & Social Change >>>> Arizona State University >>>> >>>> voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) >>>> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) >>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Jan 2, 2013, at 11:22 PM, Michael Barton <[email protected]> wrote: >>>> >>>>> GREAT NEWS! >>>>> >>>>> Commenting out both gvl_align_data lines (#684 and #1009) in gvl_calc_c >>>>> makes this work. Both slices and isosurfaces display and do not crash. I >>>>> don't know if there would be a problem with larger files or not. But this >>>>> is finally functional again. >>>>> >>>>> BUT the command you sent does NOT work. It gives a segmentation fault >>>>> error: >>>>> >>>>> m.nviz.image elevation_map=JR_2008_ALL_dem@test3d -a mode=fine >>>>> resolution_fine=6 color_map=JR_2008_ALL_dem@test3d >>>>> volume=jr_7408MR_2m_t70@test3d volume_shading=gouraud volume_resolution=1 >>>>> volume_position=0,0,20 isosurf_level=1:18.0 >>>>> isosurf_color_map=jr_7408MR_2m_t70@test3d isosurf_transparency_value=0 >>>>> slice=1:x,1:z >>>>> slice_position=0.000000,1.000000,0.520000,1.000000,0.000000,1.000000,0.250000,0.720000,0.080000,1.000000,0.000000,1.000000 >>>>> slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 >>>>> twist=0 zexag=5.000000 focus=569,593,28 light_position=0.68,0.68,0.80 >>>>> light_brightness=80 light_ambient=20 light_color=255:255:255 >>>>> output=jrvoltest format=tif size=798,545 >>>>> Loading raster map <JR_2008_ALL_dem@test3d>... >>>>> 100% >>>>> Loading raster map <JR_2008_ALL_dem@test3d>... >>>>> 100% >>>>> Translating colors from raster map <JR_2008_ALL_dem@test3d>... >>>>> 100% >>>>> Loading 3d raster map <jr_7408MR_2m_t70@test3d>... >>>>> Segmentation fault: 11 >>>>> >>>>> >>>>> Also, somewhere there is a bug somewhere that is sending progress bar >>>>> text to the screen for any nviz activity (GRASS_INFO_PERCENT: 0...) >>>>> >>>>> So now we have some kind of workaround. I don't know if there are any >>>>> other down sides to bypassing this memory reallocation, but this is a >>>>> good start on fixing this finally. Thanks Anna and Helena. >>>>> >>>>> Michael >>>>> ____________________ >>>>> C. Michael Barton >>>>> Director, Center for Social Dynamics & Complexity >>>>> Professor of Anthropology, School of Human Evolution & Social Change >>>>> Arizona State University >>>>> >>>>> voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) >>>>> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) >>>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu >>>>> >>>>> >>>>> >>>>> On Jan 2, 2013, at 10:45 PM, Helena Mitasova <[email protected]> >>>>> wrote: >>>>> >>>>>> Michael, >>>>>> >>>>>> what you describe sounds as if you had only one depth layer so let us >>>>>> check first that the 3D region is right. >>>>>> If the 3d region is set to the provided 3d raster given here >>>>>> http://skagit.meas.ncsu.edu/~helena/grasswork/JR_7408MR_2m_t70.asci >>>>>> http://skagit.meas.ncsu.edu/~helena/grasswork/JR_2008_ALL.asci >>>>>> (reference 2d raster) >>>>>> it should look like this >>>>>> >>>>>> GRASS 6.4.3svn (nc_spm_05):~ > g.region -p3 >>>>>> projection: 99 (Lambert Conformal Conic) >>>>>> zone: 0 >>>>>> datum: nad83 >>>>>> ellipsoid: a=6378137 es=0.006694380022900787 >>>>>> north: 250690 >>>>>> south: 249502 >>>>>> west: 912791 >>>>>> east: 913931 >>>>>> top: 64.00000000 >>>>>> bottom: 0.00000000 >>>>>> nsres: 2 >>>>>> nsres3: 2 >>>>>> ewres: 2 >>>>>> ewres3: 2 >>>>>> tbres: 8 >>>>>> rows: 594 >>>>>> rows3: 594 >>>>>> cols: 570 >>>>>> cols3: 570 >>>>>> depths: 8 >>>>>> >>>>>> can you then try to run the following command (please adjust the names >>>>>> of the 2d and 3d rasters to your actual names) >>>>>> >>>>>> m.nviz.image elevation_map=JR_2008_ALL@Baseline_JR -a mode=fine >>>>>> resolution_fine=6 color_map=JR_2008_ALL@Baseline_JR \ >>>>>> volume=JR_7408MR_2m_t70@Baseline_JR volume_shading=gouraud >>>>>> volume_resolution=1 volume_position=0,0,20 isosurf_level=1:18.0 >>>>>> isosurf_color_map=JR_7408MR_2m_t70@Baseline_JR >>>>>> isosurf_transparency_value=0 slice=1:x,1:z >>>>>> slice_position=0.000000,1.000000,0.520000,1.000000,0.000000,1.000000,0.250000,0.720000,0.080000,1.000000,0.000000,1.000000 >>>>>> slice_transparency=0,0 position=0.84,0.16 height=356 perspective=20 >>>>>> twist=0 zexag=5.000000 focus=569,593,28 \ >>>>>> light_position=0.68,0.68,0.80 light_brightness=80 light_ambient=20 >>>>>> light_color=255:255:255 \ >>>>>> output=jrvoltest format=tif size=798,545 >>>>>> >>>>>> it should generate an image with isosurfaces and a tilted crossection - >>>>>> it is not quite what I have on the screen, because >>>>>> it apparently uses some default values instead of actual values (e.g. >>>>>> for toggle normal direction and crossection) but it should have some >>>>>> isosurfaces. Let us know whether the command line works and we can go >>>>>> from there. >>>>>> >>>>>> Helena >>>>>> >>>>>> On Jan 3, 2013, at 12:08 AM, Michael Barton wrote: >>>>>> >>>>>>> When I put in values between 15 and 20 I can see the horizontal outline >>>>>>> of a rectangle but not the 3D shape of a box. No isosurfaces display. >>>>>>> No crash either. >>>>>>> >>>>>>> I un-commented line 684 and commented line 1009 in gvl_calc_c to see >>>>>>> what happens to slices >>>>>>> >>>>>>> /* gvl_align_data(pos, slice->data); */ >>>>>>> >>>>>>> A horizontal slice displays and I can manipulate it in the X and Y >>>>>>> direction. But I cannot manipulate it in the Z direction. Also, a Z >>>>>>> dimension slice shows up only as a line. Also, isosurfaces do not >>>>>>> display. But there is no crash for either isosurfaces or slices when I >>>>>>> comment out this line. On the face of it, a memory issue related to >>>>>>> display in the Z dimension is causing a crash. Commenting out calls to >>>>>>> gvl_align_data in gvl_calc_c stops the crash and stops display in the Z >>>>>>> dimension. There is also something called gvl_calc2_c in this folder. >>>>>>> Its code is very similar to gvl_calc_c >>>>>>> >>>>>>> I'm guessing that Martin and Helena know the most about the relevant C >>>>>>> code for lib/ogsf/*. Glynn may have some insight into this too. Anyone >>>>>>> else is welcome to chime in. >>>>>>> >>>>>>> FWIW, the last time gvl_calc_c was touched was by Glynn 4 years ago >>>>>>> (glynn: Fix char/char* mismatch (merge from trunk, r32757)). >>>>>>> >>>>>>> Volume display worked as recently as fall 2011 AFAIK. >>>>>>> >>>>>>> Michael >>>>>>> ____________________ >>>>>>> C. Michael Barton >>>>>>> Director, Center for Social Dynamics & Complexity >>>>>>> Professor of Anthropology, School of Human Evolution & Social Change >>>>>>> Arizona State University >>>>>>> >>>>>>> voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) >>>>>>> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) >>>>>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Jan 2, 2013, at 10:21 AM, Helena Mitasova <[email protected]> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Jan 2, 2013, at 1:34 AM, Michael Barton wrote: >>>>>>>> >>>>>>>>> Testing with GRASS 6.4.3RC2 >>>>>>>>> >>>>>>>>> Rem-ing out line 684 in gvl_calc_c >>>>>>>>> >>>>>>>>> /* gvl_align_data(dbuff[i].ndx_new, dbuff[i].new); */ >>>>>>>>> >>>>>>>>> prevents crashing. But I don't see an isosurface. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Helena, >>>>>>>>> >>>>>>>>> I'm using your test data (jr_7408MR_2m_t70) >>>>>>>>> >>>>>>>>> What is a good value to set for an isosurface to see anything? >>>>>>>> >>>>>>>> anything between 15 to 20 should work. >>>>>>>> You can move the volume a little bit above the surface to see the >>>>>>>> entire isosurface >>>>>>>> Here is an example of settings that I have used (the name of the >>>>>>>> volume raster is slightly different >>>>>>>> but it is the same data). >>>>>>>> >>>>>>>>> m.nviz.image elevation_map=JR_2008_ALL -a mode=fine resolution_fine=1 >>>>>>>>> color=243:243:243 volume=JR_7408MR_2m volume_shading=gouraud >>>>>>>>> volume_resolution=1 volume_position=0,0,20 isosurf_level=1:17.0 >>>>>>>>> isosurf_color_map=JR_7408MR_2m isosurf_transp_value=0 >>>>>>>>> position=0.11,0.07 height=243 perspective=13 twist=0 zexag=6.000000 >>>>>>>>> focus=569,593,17 light_position=0.26,-0.30,0.61 light_brightness=94 >>>>>>>>> light_ambient=55 light_color=255:255:255 output=nviz_output >>>>>>>>> format=ppm size=798,545 >>>>>>>> >>>>>>>> This volume includes no-data because the original rasters were masked, >>>>>>>> I think it would be useful to start with a volume without no-data - >>>>>>>> just use r3.null to replace no-data with 0. >>>>>>>> >>>>>>>> Let me know if it would be useful for me to run same thing in MacOSX >>>>>>>> 10.6 (I still don't have 10.8 machine quite ready), >>>>>>>> (see the slides 12 and 13 here for the isosurfaces at different >>>>>>>> levels, I have the isosurfaces colored by year - I don't think I gave >>>>>>>> you >>>>>>>> that raster, so your isosurfaces should be just a single color). >>>>>>>> http://skagit.meas.ncsu.edu/~helena/publwork/AGU2012lidar6.pptx >>>>>>>> >>>>>>>> Helena >>>>>>>> >>>>>>>>> Slices still crash because they still call gvl_align_data. As before, >>>>>>>>> though initially displaying a slice works fine. It only crashes when >>>>>>>>> I try to change something about the slice and it wants to redraw. >>>>>>>>> >>>>>>>>> Michael >>>>>>>>> ____________________ >>>>>>>>> C. Michael Barton >>>>>>>>> Director, Center for Social Dynamics & Complexity >>>>>>>>> Professor of Anthropology, School of Human Evolution & Social Change >>>>>>>>> Arizona State University >>>>>>>>> >>>>>>>>> voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) >>>>>>>>> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) >>>>>>>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Jan 1, 2013, at 1:24 PM, Anna Kratochvílová <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Michael, >>>>>>>>>> >>>>>>>>>> On Tue, Jan 1, 2013 at 8:48 PM, Michael Barton >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> Hi Anna, >>>>>>>>>>> >>>>>>>>>>> On the slim chance that you are online today, can you tell me where >>>>>>>>>>> gvl_align_data in gvl_calc.c reside in either the source code or >>>>>>>>>>> compiled code? I have a bit of down time and thought I'd see what I >>>>>>>>>>> could find out about the volume display breaking. I don't know C >>>>>>>>>>> but can selectively rem out some things and see what happens. >>>>>>>>>> >>>>>>>>>> It should be here >>>>>>>>>> http://trac.osgeo.org/grass/browser/grass/trunk/lib/ogsf/gvl_calc.c#L685 >>>>>>>>>> >>>>>>>>>> Also, you could try debugging with QtCreator [1] (as an user-friendly >>>>>>>>>> interface to the debugger), it is quite easy, here [2] is some help >>>>>>>>>> for setting up the project. I don't know what method you would like >>>>>>>>>> to >>>>>>>>>> use but this is the easiest I know. I suppose it should work on Mac, >>>>>>>>>> too. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Anna >>>>>>>>>> >>>>>>>>>> [1] http://qt-project.org/downloads >>>>>>>>>> [2] >>>>>>>>>> http://grasswiki.osgeo.org/wiki/Using_QtCreator_for_GRASS_C_development#Debugging >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Michael >>>>>>>>>>> ____________________ >>>>>>>>>>> C. Michael Barton >>>>>>>>>>> Director, Center for Social Dynamics & Complexity >>>>>>>>>>> Professor of Anthropology, School of Human Evolution & Social Change >>>>>>>>>>> Arizona State University >>>>>>>>>>> >>>>>>>>>>> voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) >>>>>>>>>>> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) >>>>>>>>>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Dec 6, 2012, at 12:07 AM, Anna Kratochvílová >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Michael, >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Dec 5, 2012 at 11:02 PM, Michael Barton >>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>> Any suggestions yet on where the crash I documented in >>>>>>>>>>>>> http://trac.osgeo.org/grass/ticket/1736 actually happens in the >>>>>>>>>>>>> code so that >>>>>>>>>>>>> I can take a look at it and see if there is something fixable for >>>>>>>>>>>>> the Mac? I >>>>>>>>>>>>> posted what I hope is the relevant debug output to help identify >>>>>>>>>>>>> this. >>>>>>>>>>>>> >>>>>>>>>>>>> While we may need to think about wxPython 2.9, it seems best to >>>>>>>>>>>>> first look >>>>>>>>>>>>> at what line is actually causing the crash and see if there is a >>>>>>>>>>>>> fix or >>>>>>>>>>>>> workaround. >>>>>>>>>>>> >>>>>>>>>>>> The crash occurs probably in gvl_align_data in gvl_calc.c. The >>>>>>>>>>>> error >>>>>>>>>>>> message 'pointer being realloc'd was not allocated' is quite clear, >>>>>>>>>>>> however it's not clear why it happens on Mac only. Maybe someone >>>>>>>>>>>> with >>>>>>>>>>>> better knowledge of C could understand it more. >>>>>>>>>>>> >>>>>>>>>>>> Anna >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Michael >>>>>>>>>>>>> ____________________ >>>>>>>>>>>>> C. Michael Barton >>>>>>>>>>>>> Director, Center for Social Dynamics & Complexity >>>>>>>>>>>>> Professor of Anthropology, School of Human Evolution & Social >>>>>>>>>>>>> Change >>>>>>>>>>>>> Arizona State University >>>>>>>>>>>>> >>>>>>>>>>>>> voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) >>>>>>>>>>>>> fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) >>>>>>>>>>>>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > > _______________________________________________ > grass-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
