Re: [GRASS-user] v.net.iso - segmentation fault error
O Ven, 18-11-2016 ás 22:45 +0100, Markus Metz escribiu: > > > On Fri, Nov 18, 2016 at 4:48 PM, Eduardo Corbelle Rico l...@gmx.net> wrote: > > > > > > O Xov, 17-11-2016 ás 08:52 +0100, Markus Metz escribiu: > > > > > > On Wed, Nov 16, 2016 at 7:14 PM, Eduardo Corbelle Rico > > > l...@gmx.net> wrote: > > > > > > > > O Mér, 16-11-2016 ás 15:22 +0100, Markus Metz escribiu: > > > > > > > > > > On Wed, Nov 16, 2016 at 11:44 AM, Eduardo Corbelle Rico > > > > > > > e...@gmx.net> wrote: > > > > > > > > > > > > O Xov, 27-10-2016 ás 14:56 +0200, Markus Metz escribiu: > > > > > > > On Thu, Oct 27, 2016 at 11:16 AM, Eduardo Corbelle Rico > > > > > > > <eduardo.corbe...@gmx.net> wrote: > > > > > > > > > > > > > > > > O Mér, 26-10-2016 ás 23:18 +0200, Markus Metz escribiu: > > > > > > > > > On Thu, Oct 13, 2016 at 9:55 AM, Eduardo Corbelle > Rico > > > > > > > > > <eduardo.corbe...@gmx.net> wrote: > > > > > > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > > > > > > > > > > > I am unable to use v.net.iso because of a > "segmentation > > > > > fault" > > > > > > > > > > error. I > > > > > > > > > > have a script that used to work correctly in GRASS > 6.4 > > > (32 > > > > > > > > > > bit) > > > > > > > > > > but > > > > > > > > > > produces this error after I switched to GRASS 7.0.4 > (64 > > > > > bit). > > > > > > > > > > > > > > > > > > > > If I try to follow both examples shown in https://g > rass > > > .osg > > > > > eo.o > > > > > > > > > > rg/g > > > > > > > > > > rass > > > > > > > > > > 70/manuals/v.net.iso.html (using the Spearfish > dataset > > > for > > > > > > > > > > GRASS 7) > > > > > > > > > > the > > > > > > > > > > same error appears: > > > > > > > > > > > > > > > > > > > > > Building graph... > > > > > > > > > > > Registering arcs... > > > > > > > > > > > Segmentation fault > > > > > > > > > > > > > > > > > > The segmentation fault must happen in the vector > > > libraries. I > > > > > > > > > tested > > > > > > > > > on Linux and can not reproduce the segmentation > fault. > > > > > Valgrind > > > > > > > > > also > > > > > > > > > does not show anything that could cause a > segmentation > > > fault. > > > > > Can > > > > > > > > > you > > > > > > > > > provide a gdb backtrace? > > > > > > > > > > > > > > > > > > Markus M > > > > > > > > > > > > > > > > Thank you Markus, > > > > > > > > > > > > > > > > My system is debian Stretch, and the following lines > > > describe > > > > > my > > > > > > > > attempt at generating a gdb backtrace. Please let me > know > > > if I > > > > > > > > should > > > > > > > > do otherwise. > > > > > > > > > > > > > > So far so good. The module crashes in a library function > that > > > > > comes > > > > > > > from libavl without modifications, but I can still not > see > > > why it > > > > > > > could cause a segmentation fault. Can you recompile with > the > > > > > compiler > > > > > > > debugging option -g? gdb will then be able to provide > more > > > > > > > information: > > > > > > > > > > > > > > make distclean > > > > > > > CFLAGS="-g" ./configure > > > > > > > make > > > > > > > > > >
Re: [GRASS-user] v.net.iso - segmentation fault error
O Xov, 17-11-2016 ás 08:52 +0100, Markus Metz escribiu: > > On Wed, Nov 16, 2016 at 7:14 PM, Eduardo Corbelle Rico l...@gmx.net> wrote: > > > > O Mér, 16-11-2016 ás 15:22 +0100, Markus Metz escribiu: > > > > > > On Wed, Nov 16, 2016 at 11:44 AM, Eduardo Corbelle Rico > > > e...@gmx.net> wrote: > > > > > > > > O Xov, 27-10-2016 ás 14:56 +0200, Markus Metz escribiu: > > > > > On Thu, Oct 27, 2016 at 11:16 AM, Eduardo Corbelle Rico > > > > > <eduardo.corbe...@gmx.net> wrote: > > > > > > > > > > > > O Mér, 26-10-2016 ás 23:18 +0200, Markus Metz escribiu: > > > > > > > On Thu, Oct 13, 2016 at 9:55 AM, Eduardo Corbelle Rico > > > > > > > <eduardo.corbe...@gmx.net> wrote: > > > > > > > > > > > > > > > > Dear all, > > > > > > > > > > > > > > > > I am unable to use v.net.iso because of a "segmentation > > > fault" > > > > > > > > error. I > > > > > > > > have a script that used to work correctly in GRASS 6.4 > (32 > > > > > > > > bit) > > > > > > > > but > > > > > > > > produces this error after I switched to GRASS 7.0.4 (64 > > > bit). > > > > > > > > > > > > > > > > If I try to follow both examples shown in https://grass > .osg > > > eo.o > > > > > > > > rg/g > > > > > > > > rass > > > > > > > > 70/manuals/v.net.iso.html (using the Spearfish dataset > for > > > > > > > > GRASS 7) > > > > > > > > the > > > > > > > > same error appears: > > > > > > > > > > > > > > > > > Building graph... > > > > > > > > > Registering arcs... > > > > > > > > > Segmentation fault > > > > > > > > > > > > > > The segmentation fault must happen in the vector > libraries. I > > > > > > > tested > > > > > > > on Linux and can not reproduce the segmentation fault. > > > Valgrind > > > > > > > also > > > > > > > does not show anything that could cause a segmentation > fault. > > > Can > > > > > > > you > > > > > > > provide a gdb backtrace? > > > > > > > > > > > > > > Markus M > > > > > > > > > > > > Thank you Markus, > > > > > > > > > > > > My system is debian Stretch, and the following lines > describe > > > my > > > > > > attempt at generating a gdb backtrace. Please let me know > if I > > > > > > should > > > > > > do otherwise. > > > > > > > > > > So far so good. The module crashes in a library function that > > > comes > > > > > from libavl without modifications, but I can still not see > why it > > > > > could cause a segmentation fault. Can you recompile with the > > > compiler > > > > > debugging option -g? gdb will then be able to provide more > > > > > information: > > > > > > > > > > make distclean > > > > > CFLAGS="-g" ./configure > > > > > make > > > > > > > > > > optionally make install > > > > > > > > > > Then start GRASS and use gdb for v.net.iso as before. > > > > > > > > > > Markus M > > > > > > > > > > > > > Dear Markus, > > > > > > > > Following those instructions does not seem to have changed the > > > > resulting backtrace info (copied below). Maybe I missed > something > > > along > > > > the way? > > > > > > > > - > > > > > > > > > Is this something Debian specific that debugging symbols must be > > > explicitly activated? Are you using GCC or another compiler? > > > > > > Alternatively, you can also try valgrind: > > > > > > CMD="v.net.iso input=myroads_net output=myroads_net_iso > > > center_cats=1-10 costs=1000,2000,5000 --o" > > > valgrind --tool=memcheck --log-file=v.net.iso.vg.log $CMD
Re: [GRASS-user] v.net.iso - segmentation fault error
O Mér, 16-11-2016 ás 15:22 +0100, Markus Metz escribiu: > > On Wed, Nov 16, 2016 at 11:44 AM, Eduardo Corbelle Rico e...@gmx.net> wrote: > > > > O Xov, 27-10-2016 ás 14:56 +0200, Markus Metz escribiu: > > > On Thu, Oct 27, 2016 at 11:16 AM, Eduardo Corbelle Rico > > > <eduardo.corbe...@gmx.net> wrote: > > > > > > > > O Mér, 26-10-2016 ás 23:18 +0200, Markus Metz escribiu: > > > > > On Thu, Oct 13, 2016 at 9:55 AM, Eduardo Corbelle Rico > > > > > <eduardo.corbe...@gmx.net> wrote: > > > > > > > > > > > > Dear all, > > > > > > > > > > > > I am unable to use v.net.iso because of a "segmentation > fault" > > > > > > error. I > > > > > > have a script that used to work correctly in GRASS 6.4 (32 > > > > > > bit) > > > > > > but > > > > > > produces this error after I switched to GRASS 7.0.4 (64 > bit). > > > > > > > > > > > > If I try to follow both examples shown in https://grass.osg > eo.o > > > > > > rg/g > > > > > > rass > > > > > > 70/manuals/v.net.iso.html (using the Spearfish dataset for > > > > > > GRASS 7) > > > > > > the > > > > > > same error appears: > > > > > > > > > > > > > Building graph... > > > > > > > Registering arcs... > > > > > > > Segmentation fault > > > > > > > > > > The segmentation fault must happen in the vector libraries. I > > > > > tested > > > > > on Linux and can not reproduce the segmentation fault. > Valgrind > > > > > also > > > > > does not show anything that could cause a segmentation fault. > Can > > > > > you > > > > > provide a gdb backtrace? > > > > > > > > > > Markus M > > > > > > > > Thank you Markus, > > > > > > > > My system is debian Stretch, and the following lines describe > my > > > > attempt at generating a gdb backtrace. Please let me know if I > > > > should > > > > do otherwise. > > > > > > So far so good. The module crashes in a library function that > comes > > > from libavl without modifications, but I can still not see why it > > > could cause a segmentation fault. Can you recompile with the > compiler > > > debugging option -g? gdb will then be able to provide more > > > information: > > > > > > make distclean > > > CFLAGS="-g" ./configure > > > make > > > > > > optionally make install > > > > > > Then start GRASS and use gdb for v.net.iso as before. > > > > > > Markus M > > > > > > > Dear Markus, > > > > Following those instructions does not seem to have changed the > > resulting backtrace info (copied below). Maybe I missed something > along > > the way? > > > > - > > > Is this something Debian specific that debugging symbols must be > explicitly activated? Are you using GCC or another compiler? > > Alternatively, you can also try valgrind: > > CMD="v.net.iso input=myroads_net output=myroads_net_iso > center_cats=1-10 costs=1000,2000,5000 --o" > valgrind --tool=memcheck --log-file=v.net.iso.vg.log $CMD > > Markus M > You were right: it was my fault not having grass-core-dbgsym and grass- dev-dbgsym packages installed. I copied below the results of the debugging commands: GRASS 7.0.5 (spearfish60_grass7):~ > gdb `which v.net.iso` GNU gdb (Debian 7.11.1-2+b1) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl .html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/lib/grass70/bin/v.net.iso...Reading sy
Re: [GRASS-user] v.net.iso - segmentation fault error
O Xov, 27-10-2016 ás 14:56 +0200, Markus Metz escribiu: > On Thu, Oct 27, 2016 at 11:16 AM, Eduardo Corbelle Rico > <eduardo.corbe...@gmx.net> wrote: > > > > O Mér, 26-10-2016 ás 23:18 +0200, Markus Metz escribiu: > > > On Thu, Oct 13, 2016 at 9:55 AM, Eduardo Corbelle Rico > > > <eduardo.corbe...@gmx.net> wrote: > > > > > > > > Dear all, > > > > > > > > I am unable to use v.net.iso because of a "segmentation fault" > > > > error. I > > > > have a script that used to work correctly in GRASS 6.4 (32 > > > > bit) > > > > but > > > > produces this error after I switched to GRASS 7.0.4 (64 bit). > > > > > > > > If I try to follow both examples shown in https://grass.osgeo.o > > > > rg/g > > > > rass > > > > 70/manuals/v.net.iso.html (using the Spearfish dataset for > > > > GRASS 7) > > > > the > > > > same error appears: > > > > > > > > > Building graph... > > > > > Registering arcs... > > > > > Segmentation fault > > > > > > The segmentation fault must happen in the vector libraries. I > > > tested > > > on Linux and can not reproduce the segmentation fault. Valgrind > > > also > > > does not show anything that could cause a segmentation fault. Can > > > you > > > provide a gdb backtrace? > > > > > > Markus M > > > > Thank you Markus, > > > > My system is debian Stretch, and the following lines describe my > > attempt at generating a gdb backtrace. Please let me know if I > > should > > do otherwise. > > So far so good. The module crashes in a library function that comes > from libavl without modifications, but I can still not see why it > could cause a segmentation fault. Can you recompile with the compiler > debugging option -g? gdb will then be able to provide more > information: > > make distclean > CFLAGS="-g" ./configure > make > > optionally make install > > Then start GRASS and use gdb for v.net.iso as before. > > Markus M > Dear Markus, Following those instructions does not seem to have changed the resulting backtrace info (copied below). Maybe I missed something along the way? - make distclean CFLAGS="-g" ./configure --with-freetype-includes=/usr/include/freetype2 make sudo make install GRASS 7.0.5 (spearfish60_grass7):~ > gdb `which v.net.iso` GNU gdb (Debian 7.11.1-2+b1) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl .html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/lib/grass70/bin/v.net.iso...(no debugging symbols found)...done. (gdb) run input=myroads_net output=myroads_net_iso center_cats=1-10 costs=1000,2000,5000 Starting program: /usr/lib/grass70/bin/v.net.iso input=myroads_net output=myroads_net_iso center_cats=1-10 costs=1000,2000,5000 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux- gnu/libthread_db.so.1". Building graph... Registering arcs... Program received signal SIGSEGV, Segmentation fault. 0x76c64708 in tavl_probe () from /usr/lib/grass70/lib/libgrass_dgl.7.0.5.so (gdb) bt full #0 0x76c64708 in tavl_probe () from /usr/lib/grass70/lib/libgrass_dgl.7.0.5.so No symbol table info available. #1 0x76c65717 in dglTreeNodeAdd () from /usr/lib/grass70/lib/libgrass_dgl.7.0.5.so No symbol table info available. #2 0x76c5aa0c in dgl_add_edge_V1 () from /usr/lib/grass70/lib/libgrass_dgl.7.0.5.so No symbol table info available. #3 0x00007ffff6c58a62 in dglAddEdge () from /usr/lib/grass70/lib/libgrass_dgl.7.0.5.so No symbol table info available. #4 0x77ba1d69 in Vect_net_build_graph () from /usr/lib/grass70/lib/libgrass_vector.7.0.5.so No symbol table info available. #5 0x5b08 in main () No symbol table info available. (gdb) l 1 ../sysdeps/x86_64/dl-procinfo.c: Non hai tal fich
Re: [GRASS-user] v.net.iso - segmentation fault error
O Xov, 27-10-2016 ás 14:56 +0200, Markus Metz escribiu: > On Thu, Oct 27, 2016 at 11:16 AM, Eduardo Corbelle Rico > <eduardo.corbe...@gmx.net> wrote: > > > > O Mér, 26-10-2016 ás 23:18 +0200, Markus Metz escribiu: > > > On Thu, Oct 13, 2016 at 9:55 AM, Eduardo Corbelle Rico > > > <eduardo.corbe...@gmx.net> wrote: > > > > > > > > Dear all, > > > > > > > > I am unable to use v.net.iso because of a "segmentation fault" > > > > error. I > > > > have a script that used to work correctly in GRASS 6.4 (32 > > > > bit) > > > > but > > > > produces this error after I switched to GRASS 7.0.4 (64 bit). > > > > > > > > If I try to follow both examples shown in https://grass.osgeo.o > > > > rg/g > > > > rass > > > > 70/manuals/v.net.iso.html (using the Spearfish dataset for > > > > GRASS 7) > > > > the > > > > same error appears: > > > > > > > > > Building graph... > > > > > Registering arcs... > > > > > Segmentation fault > > > > > > The segmentation fault must happen in the vector libraries. I > > > tested > > > on Linux and can not reproduce the segmentation fault. Valgrind > > > also > > > does not show anything that could cause a segmentation fault. Can > > > you > > > provide a gdb backtrace? > > > > > > Markus M > > > > Thank you Markus, > > > > My system is debian Stretch, and the following lines describe my > > attempt at generating a gdb backtrace. Please let me know if I > > should > > do otherwise. > > So far so good. The module crashes in a library function that comes > from libavl without modifications, but I can still not see why it > could cause a segmentation fault. Can you recompile with the compiler > debugging option -g? gdb will then be able to provide more > information: > > make distclean > CFLAGS="-g" ./configure > make > > optionally make install > > Then start GRASS and use gdb for v.net.iso as before. > > Markus M Thank you, I'll try. Grass was installed in my system using pre- compiled packages (via apt-get)... Forgive me if this is a silly question: from which folder am I supposed to execute the commands? (or should I download the source files and start all over?) > > > > > > > GRASS 7.0.5 (spearfish60_grass7):~ > gdb `which v.net.iso` > > GNU gdb (Debian 7.11.1-2) 7.11.1 > > Copyright (C) 2016 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses > > /gpl > > .html> > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. Type "show > > copying" > > and "show warranty" for details. > > This GDB was configured as "x86_64-linux-gnu". > > Type "show configuration" for configuration details. > > For bug reporting instructions, please see: > > <http://www.gnu.org/software/gdb/bugs/>. > > Find the GDB manual and other documentation resources online at: > > <http://www.gnu.org/software/gdb/documentation/>. > > For help, type "help". > > Type "apropos word" to search for commands related to "word"... > > Reading symbols from /usr/lib/grass70/bin/v.net.iso...(no debugging > > symbols found)...done. > > > > > > (gdb) run input=myroads_net output=myroads_net_iso center_cats=1- > > 10 > > costs=1000,2000,5000 > > Starting program: /usr/lib/grass70/bin/v.net.iso input=myroads_net > > output=myroads_net_iso center_cats=1-10 costs=1000,2000,5000 > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library "/lib/x86_64-linux- > > gnu/libthread_db.so.1". > > Building graph... > > Registering arcs... > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x76c64708 in tavl_probe () > > from /usr/lib/grass70/lib/libgrass_dgl.7.0.5.so > > > > > > (gdb) bt full > > #0 0x76c64708 in tavl_probe () > > from /usr/lib/grass70/lib/libgrass_dgl.7.0.5.so > > No symbol table info available. > > #1 0x76c65717 in dglTreeNodeAdd () > > from /usr/lib/grass70/lib/libgrass_dgl.7.0.5.so > > No symbol table info available. > > #2 0x76c5aa0c in dgl_add_edge_V1 () > > from /usr/lib/gra
Re: [GRASS-user] v.net.iso - segmentation fault error
O Mér, 26-10-2016 ás 23:18 +0200, Markus Metz escribiu: > On Thu, Oct 13, 2016 at 9:55 AM, Eduardo Corbelle Rico > <eduardo.corbe...@gmx.net> wrote: > > > > Dear all, > > > > I am unable to use v.net.iso because of a "segmentation fault" > > error. I > > have a script that used to work correctly in GRASS 6.4 (32 bit) > > but > > produces this error after I switched to GRASS 7.0.4 (64 bit). > > > > If I try to follow both examples shown in https://grass.osgeo.org/g > > rass > > 70/manuals/v.net.iso.html (using the Spearfish dataset for GRASS 7) > > the > > same error appears: > > > > > Building graph... > > > Registering arcs... > > > Segmentation fault > > The segmentation fault must happen in the vector libraries. I tested > on Linux and can not reproduce the segmentation fault. Valgrind also > does not show anything that could cause a segmentation fault. Can you > provide a gdb backtrace? > > Markus M Thank you Markus, My system is debian Stretch, and the following lines describe my attempt at generating a gdb backtrace. Please let me know if I should do otherwise. GRASS 7.0.5 (spearfish60_grass7):~ > gdb `which v.net.iso` GNU gdb (Debian 7.11.1-2) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl .html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/lib/grass70/bin/v.net.iso...(no debugging symbols found)...done. (gdb) run input=myroads_net output=myroads_net_iso center_cats=1-10 costs=1000,2000,5000 Starting program: /usr/lib/grass70/bin/v.net.iso input=myroads_net output=myroads_net_iso center_cats=1-10 costs=1000,2000,5000 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux- gnu/libthread_db.so.1". Building graph... Registering arcs... Program received signal SIGSEGV, Segmentation fault. 0x76c64708 in tavl_probe () from /usr/lib/grass70/lib/libgrass_dgl.7.0.5.so (gdb) bt full #0 0x76c64708 in tavl_probe () from /usr/lib/grass70/lib/libgrass_dgl.7.0.5.so No symbol table info available. #1 0x76c65717 in dglTreeNodeAdd () from /usr/lib/grass70/lib/libgrass_dgl.7.0.5.so No symbol table info available. #2 0x76c5aa0c in dgl_add_edge_V1 () from /usr/lib/grass70/lib/libgrass_dgl.7.0.5.so No symbol table info available. #3 0x76c58a62 in dglAddEdge () from /usr/lib/grass70/lib/libgrass_dgl.7.0.5.so No symbol table info available. #4 0x77ba1d69 in Vect_net_build_graph () from /usr/lib/grass70/lib/libgrass_vector.7.0.5.so No symbol table info available. #5 0x00401aa9 in main () No symbol table info available. (gdb) l 1 ../sysdeps/x86_64/dl-procinfo.c: Non hai tal ficheiro ou directorio. > > > > > What I am missing? > > > > Thanks in advance. > > > > Greetings. > > > > Eduardo Corbelle > > > > > > > > -- > > Dr. Eduardo Corbelle Rico > > > > Land laboratory (LaboraTe) > > Department of Agricultural and Forest Engineering > > Universidade de Santiago de Compostela > > > > e-mail: eduardo.corbe...@usc.es > > Tel: +34 982 823 324 > > Fax: +34 982 285 926 > > Web: http://laborate.usc.es > > http://masterterra.usc.es > > http://github.com/eduardocorbelle > > ___ > > grass-user mailing list > > grass-user@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.net.iso - segmentation fault error
Dear all, I am unable to use v.net.iso because of a "segmentation fault" error. I have a script that used to work correctly in GRASS 6.4 (32 bit) but produces this error after I switched to GRASS 7.0.4 (64 bit). If I try to follow both examples shown in https://grass.osgeo.org/grass 70/manuals/v.net.iso.html (using the Spearfish dataset for GRASS 7) the same error appears: > Building graph... > Registering arcs... > Segmentation fault What I am missing? Thanks in advance. Greetings. Eduardo Corbelle -- Dr. Eduardo Corbelle Rico Land laboratory (LaboraTe) Department of Agricultural and Forest Engineering Universidade de Santiago de Compostela e-mail: eduardo.corbe...@usc.es Tel: +34 982 823 324 Fax: +34 982 285 926 Web: http://laborate.usc.es http://masterterra.usc.es http://github.com/eduardocorbelle ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] pb. with netCDF row order
Hi Nicolas, it works perfectly now. Thanks a lot again. Eduardo O Mar, 26-10-2010 ás 22:39 +0200, Nicolas Pérenne escribiu: Hi Eduardo, I have downloaded your file and indeed as you guessed there is a way to select the time index, and possibly also a level (altitude or depth) index. It goes through optional positional arguments which are not documented (sorry), because one has to guess that 'l' stands for the time index and 'k' for the level one: bash nc2grass.sh -h Usage: nc2grass.sh [-h] nc2grass.sh [-x axis name] [-y axis name] [-z axis name] [-t axis name] [-m missing value] netCDF file variable imin imax jmin jmax [l [k]] -h: help -x: axis name in input file. Default: longitude -y: axis name in input file. Default: latitude -z: axis name in input file. Default: z -t: axis name in input file. Default: time -m: missing value code in output header. Default: -9.99e+02 Actually in your case 'ncdump -h' shows that the missing value flag is 1.e+30f and you can tell GRASS about it using the -m option; my experience is that you have to provide this flag with the very same formatting given to awk in the script, that is +1.00e+30 (check out the default value). To get the first time index in your file: nc2grass.sh -m +1.00e+30 t2m.mean.KNMI.HA2.nc t2m 1 100 1 80 1 \ t2m_l1.txt latN latS lonE lonW: 74.750 35.250 34.750 -14.750 Or you can automate the extraction like this: bash for l in 1 2 3 4; do nc2grass.sh -m +1.00e+30 t2m.mean.KNMI.HA2.nc t2m 1 100 1 80 $l \ t2m_l$l.txt done latN latS lonE lonW: 74.750 35.250 34.750 -14.750 latN latS lonE lonW: 74.750 35.250 34.750 -14.750 latN latS lonE lonW: 74.750 35.250 34.750 -14.750 latN latS lonE lonW: 74.750 35.250 34.750 -14.750 bash ls t2m_l1.txt t2m_l2.txt t2m_l3.txt t2m_l4.txt t2m.mean.KNMI.HA2.nc One potential shortcoming of the script though is that you may provide a time index, or a time index and a level index, but not a level index alone... a fix could be to provide 'k' and 'l' as options instead of positional arguments. Hope it helps. Le mardi 26 octobre 2010 à 12:48 +0200, Eduardo Corbelle Rico a écrit : Nicolas, I've been struggling with the issue of row order in netCDF files and your post came perfect for me. Thank you very much for it. I still have a problem that surely you or anyone in the list would find trivial: the file I'm trying to convert (downloadable in the Prudence project: http://prudence.dmi.dk/data/seasonal/KNMI/t2m.mean.KNMI.HA2.nc.gz ) has four time bands, which I can't write separately into different ascii files. I'm using the script as... ./nc2grass-0001.bin t2m.mean.KNMI.HA2.nc t2m 1 100 1 80 t2m.txt ...and the four time (seasonal) bands came together in the same ascii line. Should I use any additional argument with the script to be able to get four separate ascii files? Thanks a lot! ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] pb. with netCDF row order
Nicolas, I've been struggling with the issue of row order in netCDF files and your post came perfect for me. Thank you very much for it. I still have a problem that surely you or anyone in the list would find trivial: the file I'm trying to convert (downloadable in the Prudence project: http://prudence.dmi.dk/data/seasonal/KNMI/t2m.mean.KNMI.HA2.nc.gz ) has four time bands, which I can't write separately into different ascii files. I'm using the script as... ./nc2grass-0001.bin t2m.mean.KNMI.HA2.nc t2m 1 100 1 80 t2m.txt ...and the four time (seasonal) bands came together in the same ascii line. Should I use any additional argument with the script to be able to get four separate ascii files? Thanks a lot! -- Dr. Eduardo Corbelle Rico Associate Researcher Research Group 1934-TeBio - Land Lab. Dept. Agric. Forest Engineering University of Santiago de Compostela (SPAIN) e-mail: eduardo.corbe...@usc.es Tel: +34 982252303 ext. 23292 Fax: +34 982285926 Web: http://laborate.usc.es ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
