I will try to test today if I can. 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 Feb 3, 2013, at 5:16 AM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > 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 <michael.bar...@asu.edu> > 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 <hmit...@ncsu.edu> >> 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 <michael.bar...@asu.edu> >>>> 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 <michael.bar...@asu.edu> >>>>> 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 <hmit...@ncsu.edu> >>>>>> 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 <hmit...@ncsu.edu> 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á >>>>>>>>>> <kratocha...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Michael, >>>>>>>>>>> >>>>>>>>>>> On Tue, Jan 1, 2013 at 8:48 PM, Michael Barton >>>>>>>>>>> <michael.bar...@asu.edu> 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á >>>>>>>>>>>> <kratocha...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Michael, >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Dec 5, 2012 at 11:02 PM, Michael Barton >>>>>>>>>>>>> <michael.bar...@asu.edu> 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 >> grass-dev@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev