[GRASS-dev] Difficulty compiling GRASS on Mac

[Seth Price]

Hey all, I'm trying to compile GRASS on Mac 10.13.4 so I can compile and
link to the GRASS libraries. I don't need most of the GIS features, just
enough to create and run my own C++ modules. I'm having some troubles with
grass-7.4.0 and grass-7.4.1RC1. The first problem I'm having is an error
linking libgrass_gis.7.4.1RC1.dylib. I get this error:


Undefined symbols for architecture x86_64:

  "_libiconv", referenced from:

  _print_escaped_for_xml in parser_interface.o

  "_libiconv_close", referenced from:

  _print_escaped_for_xml in parser_interface.o

  "_libiconv_open", referenced from:

  _print_escaped_for_xml in parser_interface.o

ld: symbol(s) not found for architecture x86_64


I can rerun the command and manually add the correct linking path for
iconv, and it works. I'm not sure why it wouldn't find iconv otherwise, but
it is what it is. This is the initial configure command that I'm using:

./configure --with-opengl=aqua --with-prefix=/usr/local --enable-shared

I've found that I can change the configure command and fix that problem:

./configure --with-opengl=aqua --with-libs=/usr/local/lib
--with-prefix=/usr/local --enable-shared

However, then it progresses and returns this error while compiling many
modules:

dyld: Library not loaded:
/usr/local/grass-7.4.1RC1/lib/libgrass_gis.7.4.1RC1.dylib

  Referenced from:
/usr/local/grass/grass-7.4.1RC1/dist.x86_64-apple-darwin17.5.0/bin/g.parser

  Reason: image not found

make: *** [d.correlate.tmp.html] Error 1

The dylib looks like it's been successfully compiled at
dist.x86_64-apple-darwin17.5.0/lib/libgrass_gis.7.4.1RC1.dylib and just the
linking path for the libraries is wrong. I can't seem to shake it with any
of the online GRASS compiling instructions I've found. What might cause
this? Are there any current instructions for getting the shared libraries
compiled and installed?


Also, I'm able to install via homebrew, but then I have this problem when
compiling my modules against GRASS:

*sources/CameraOptic.cpp:33:23: **error: **use of undeclared identifier
'PACKAGE'*

G_verbose_message(_("(%5d) Camera optical adjustment..."),

*  ^*

*/usr/local/opt/grass7/grass-base/include/grass/glocale.h:10:26: note:
*expanded
from macro '_'

#define _(str) G_gettext(PACKAGE,(str))

I've never seen it before and can only guess that it would be fixed by a
fresh install of GRASS from source. Identical code compiles fine under
Ubuntu. Does anyone know what might be causing this? Or what might I do to
fix it?

Thanks,
Seth
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS GIS raster files: LZW compression?

[Seth Price]

Also, it's worth remembering that LZ4 is not intended for file size. It's
there because it decompresses at least an order of magnitude faster than
LZW.

On Thu, Oct 26, 2017 at 10:23 AM, Even Rouault 
wrote:

> On jeudi 26 octobre 2017 18:57:10 CEST Markus Neteler wrote:
>
> > On Thu, Oct 26, 2017 at 9:25 AM, Markus Metz
>
> >
>
> >  wrote:
>
> > > On Wed, Oct 25, 2017 at 10:40 PM, Markus Neteler 
> wrote:
>
> > >> Hi devs,
>
> > >>
>
> > >> while playing with the SRTM 30m world I see that there is a difference
>
> > >> of 66GB in size between LZ4 (larger) and DEFLATE (smaller). While this
>
> > >> is not a surprise I was wondering if LZW compression could be brought
>
> > >> back. AFAIK the license issue is gone for a while and indeed GRASS got
>
> > >> a special permit back in 1988 according to the old source code.
>
> > >>
>
> > >> Would that make sense?
>
> > >
>
> > > You could test with compress (LZW) and gzip (DEFLATE based on LZ77) if
>
> > > that
>
> > > would make sense.
>
> > >
>
> > > Implementation would be a bit of an effort: either adapt from the
> source
>
> > > code of compress or from GDAL's LZW compression for Tiff.
>
> >
>
> > I thought to remember that the LZW compression was in libgis some
>
> > decades ago but did not find any trace so far.
>
> > At that point I happily abandon this idea - no need to waste energy here
> :-)
>
>
>
> Another option would be to consider the zstd / zstandard compression method
>
> ( https://github.com/facebook/zstd ), that has roughly the compression
> ratio of DEFLATE / LZ77 with a compression and decompression speed 3 or 4
> times faster. This is in my todo list of things to experiment as a libtiff
> compression method.
>
>
>
> Zstd has been added recently as a compression method in the Linux kernel:
>
> https://www.phoronix.com/scan.php?page=news_item&px=ZSTD-
> Linux-Kernel-Image
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 

*Seth Price*

Director of Putting the Pixels Where They Belong
Satellitenfernerkundungsspezialist

*Planet Labs*

Email: s...@planet.com
Phone: (608) 335-8068
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] I've tripled GRASS's I/O speed

[Seth Price]

I figured it out. I had to `make clean && make && sudo make install` to get
unit tests working as expected.

I just uploaded a new version of the code that shouldn't fail any
additional unit tests, and I've added unit tests to r.compress that test
reading/writing the different compression schemes.
~Seth

On Tue, Oct 6, 2015 at 5:54 AM, Vaclav Petras  wrote:

>
> On Tue, Oct 6, 2015 at 1:42 AM, Seth Price  wrote:
>
>> Sorry for derailing my own thread, but here we go again...
>> I'm having a hard time reproducing anything with the unit tests. There
>> seems to be some state that exists between unit test runs.
>>
>
> What are the actual errors in the HTML report?
>
>
>> I ran it with my updated code, and I got 30% failed. Then I ran the new
>> code with the tests, and I'm getting 30% failed. So I deleted the basic
>> location directory and re-decompressed it. Now I'm getting 31% failed in
>> both directories.
>>
>
>
>> Using these commands, as shown above, resulted in 21% failed. I'm running
>> `make && sudo make install` when I switch directories. Then I delete &
>> refresh the location files. Then I run the unit tests as `python -m
>> grass.gunittest.main --location nc_basic_spm_grass7 --location-type nc`.
>> What's wrong with my test procedure?
>>
>
> Sorry, I don't understand what is the difference between new code and
> updated code. When you get 30, 31 21%? What are the actual commands you are
> running?
>
> If you are concerned about reproducibility, use VM or Docker, e.g. with
> Ubuntu [1]. In this way, we can see if it is a local or Mac issue or not.
>
> [1] https://github.com/wenzeslaus/grass-gis-docker
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] I've tripled GRASS's I/O speed

[Seth Price]

Sorry for derailing my own thread, but here we go again...
I'm having a hard time reproducing anything with the unit tests. There
seems to be some state that exists between unit test runs. I ran it with my
updated code, and I got 30% failed. Then I ran the new code with the tests,
and I'm getting 30% failed. So I deleted the basic location directory and
re-decompressed it. Now I'm getting 31% failed in both directories.

Using these commands, as shown above, resulted in 21% failed. I'm running
`make && sudo make install` when I switch directories. Then I delete &
refresh the location files. Then I run the unit tests as `python -m
grass.gunittest.main --location nc_basic_spm_grass7 --location-type nc`.
What's wrong with my test procedure?

On Mon, Oct 5, 2015 at 3:57 PM, Vaclav Petras  wrote:

>
> On Mon, Oct 5, 2015 at 6:41 PM, Seth Price  wrote:
>
>> The tests are without my changes on 64 bit Mac v10.10.5, Mac Pro with 64
>> GB of RAM.
>
>
> Good, I hope now you are ready to run tests with your changes as well.
>
> BTW, great that you run tests on Mac!
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] I've tripled GRASS's I/O speed

[Seth Price]

The tests are without my changes on 64 bit Mac v10.10.5, Mac Pro with 64 GB
of RAM.

./configure  --with-freetype
--with-freetype-includes=/usr/local/include/freetype2 --with-opengl=aqua
--with-libs=/usr/local/lib --enable-64bit --with-sqlite --with-postgres
--with-postgres-includes=/usr/local/pgsql/include


On Mon, Oct 5, 2015 at 3:34 PM, Vaclav Petras  wrote:

>
>
> On Mon, Oct 5, 2015 at 6:23 PM, Seth Price  wrote:
>
>> Ah, I see now. I have failed tests at 24% & 21% on a recent snapshot now:
>>
>> GRASS 7.1.svn
>> (ncarolina_smp_base0.3.2):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19
>> > python -m grass.gunittest.main --location ncarolina_smp_base0.3.2
>> --location-type nc
>>
>> test_assertions_vect from ./lib/python/gunittest failed (1 test failed)
>>
>> test_doctests from ./lib/python/pygrass failed (3 tests failed)
>>
>> [...]
>>
>> test_v_net from ./vector/v.net failed (4 tests failed)
>>
>> test_vwhat_ncspm from ./vector/v.what failed (4 tests failed)
>>
>>
>> Executed 127 test files in 0:24:05.986559.
>>
>> From them 96 files (76%) were successful and 31 files (24%) failed.
>>
>> GRASS 7.1.svn
>> (ncarolina_smp_base0.3.2):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19
>> >
>>
>> or
>>
>> GRASS 7.1.svn
>> (nc_basic_spm_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19
>> > python -m grass.gunittest.main --location nc_basic_spm_grass7
>> --location-type nc
>>
>> test_assertions_vect from ./lib/python/gunittest failed (1 test failed)
>>
>> test_doctests from ./lib/python/pygrass failed (3 tests failed)
>>
>> [...]
>>
>> test_raster3d_algebra from ./temporal/t.rast3d.algebra failed (6 tests
>> failed)
>>
>> test_vector_algebra from ./temporal/t.vect.algebra failed (14 tests
>> failed)
>>
>>
>> Executed 127 test files in 0:24:47.877746.
>>
>> From them 100 files (79%) were successful and 27 files (21%) failed.
>>
>> GRASS 7.1.svn
>> (nc_basic_spm_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19
>> >
>>
>> Is this expected?
>>
>
> This looks quite OK actually. Probably most of the failing tests are
> temporal algebra which depends on Python PLY:
>
> https://grass.osgeo.org/grass70/source/snapshot/REQUIREMENTS.html
>
> This should be visible in the HTML reports (the aforementioned
> testreport/index.html) which give the actual reasons why the test failed.
>
> This is the result you will get today in best case (on 64bit):
>
>
> http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-10-05-07-00/report_for_nc_basic_spm_grass7_nc/testfiles.html
>
> Was this result with or without your changes?
>
>
>>
>> On Mon, Oct 5, 2015 at 2:13 PM, Vaclav Petras 
>> wrote:
>>
>>>
>>> On Mon, Oct 5, 2015 at 5:07 PM, Seth Price  wrote:
>>> >
>>> > --location /usr/local/grass/nc_basic_spm_grass7/
>>>
>>> python -m grass.gunittest.main --location locname --location-type nc
>>>
>>> where locname is a name of location in current GRASS GIS data(base)
>>> directory (GISDBASE) and nc is a location specified by individual test
>>> files (the later is not yet fully implemented, so just put there nc every
>>> time).
>>>
>>> [
>>> https://grass.osgeo.org/grass71/manuals/libpython/gunittest_running_tests.html#running-tests-and-creating-report
>>> ]
>>>
>>> or:
>>>
>>> grass71 --exec python -m grass.gunittest.main --help
>>> ...
>>>   --location LOCATION   Name of location where to perform test
>>>
>>> I hope this helps.
>>>
>>> Have you found the HTMl output?
>>>
>>
>>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] I've tripled GRASS's I/O speed

[Seth Price]

Ah, I see now. I have failed tests at 24% & 21% on a recent snapshot now:

GRASS 7.1.svn
(ncarolina_smp_base0.3.2):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19
> python -m grass.gunittest.main --location ncarolina_smp_base0.3.2
--location-type nc

test_assertions_vect from ./lib/python/gunittest failed (1 test failed)

test_doctests from ./lib/python/pygrass failed (3 tests failed)

[...]

test_v_net from ./vector/v.net failed (4 tests failed)

test_vwhat_ncspm from ./vector/v.what failed (4 tests failed)


Executed 127 test files in 0:24:05.986559.

>From them 96 files (76%) were successful and 31 files (24%) failed.

GRASS 7.1.svn
(ncarolina_smp_base0.3.2):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19
>

or

GRASS 7.1.svn
(nc_basic_spm_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19
> python -m grass.gunittest.main --location nc_basic_spm_grass7
--location-type nc

test_assertions_vect from ./lib/python/gunittest failed (1 test failed)

test_doctests from ./lib/python/pygrass failed (3 tests failed)

[...]

test_raster3d_algebra from ./temporal/t.rast3d.algebra failed (6 tests
failed)

test_vector_algebra from ./temporal/t.vect.algebra failed (14 tests failed)


Executed 127 test files in 0:24:47.877746.

>From them 100 files (79%) were successful and 27 files (21%) failed.

GRASS 7.1.svn
(nc_basic_spm_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19
>

Is this expected?


On Mon, Oct 5, 2015 at 2:13 PM, Vaclav Petras  wrote:

>
> On Mon, Oct 5, 2015 at 5:07 PM, Seth Price  wrote:
> >
> > --location /usr/local/grass/nc_basic_spm_grass7/
>
> python -m grass.gunittest.main --location locname --location-type nc
>
> where locname is a name of location in current GRASS GIS data(base)
> directory (GISDBASE) and nc is a location specified by individual test
> files (the later is not yet fully implemented, so just put there nc every
> time).
>
> [
> https://grass.osgeo.org/grass71/manuals/libpython/gunittest_running_tests.html#running-tests-and-creating-report
> ]
>
> or:
>
> grass71 --exec python -m grass.gunittest.main --help
> ...
>   --location LOCATION   Name of location where to perform test
>
> I hope this helps.
>
> Have you found the HTMl output?
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] I've tripled GRASS's I/O speed

[Seth Price]

Thanks, I think I'm still getting the same issue. Here is me trying to run
tests with both "nc_basic_spm_grass7" and "ncarolina_smp_base0.3.2":

seths-mbp:grass-7.1.svn_src_snapshot_2015_09_19 sprice$ grass71 --text
../nc_basic_spm_grass7/PERMANENT/

Cleaning up temporary files...
[...]

GRASS 7.1.svn
(nc_basic_spm_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19
> python -m grass.gunittest.main --location
/usr/local/grass/nc_basic_spm_grass7/ --location-type nc

test_g_list from ./general/g.list failed (1 test failed)

test_g_remove from ./general/g.remove failed (2 tests failed)

test_overwrite from ./general/g.rename failed (3 tests failed)

toolboxes from ./gui/wxpython/core failed
[...]

test_vto3d from ./vector/v.to.3d failed (1 test failed)

test_vwhat_layers from ./vector/v.what failed (1 test failed)

test_vwhat_ncspm from ./vector/v.what failed (4 tests failed)


Executed 127 test files in 0:00:50.862606.

>From them 12 files (9%) were successful and 115 files (91%) failed.

GRASS 7.1.svn
(nc_basic_spm_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19
> exit
[...]

seths-mbp:grass-7.1.svn_src_snapshot_2015_09_19 sprice$ grass71 --text
../ncarolina_smp_base0.3.2/PERMANENT/
[...]

GRASS 7.1.svn
(ncarolina_smp_base0.3.2):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19
> python -m grass.gunittest.main --location
/usr/local/grass/ncarolina_smp_base0.3.2/ --location-type nc

test_g_list from ./general/g.list failed (1 test failed)

test_g_remove from ./general/g.remove failed (2 tests failed)

test_overwrite from ./general/g.rename failed (3 tests failed)

toolboxes from ./gui/wxpython/core failed
[...]

test_v_net from ./vector/v.net failed (8 tests failed)

test_vto3d from ./vector/v.to.3d failed (1 test failed)

test_vwhat_layers from ./vector/v.what failed (1 test failed)

test_vwhat_ncspm from ./vector/v.what failed (4 tests failed)


Executed 127 test files in 0:00:46.315482.

>From them 12 files (9%) were successful and 115 files (91%) failed.

GRASS 7.1.svn
(ncarolina_smp_base0.3.2):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19
>





On Mon, Oct 5, 2015 at 1:18 PM, Vaclav Petras  wrote:

>
>
> On Mon, Oct 5, 2015 at 3:21 PM, Seth Price  wrote:
>
>> Hi, I've spent the last two or three hours trying to get GRASS' unit
>> tests running. With a fresh source tree, the best I can get is ~9% of the
>> tests passing:
>>
>
> Oh, sorry about that, you need to use basic instead of full NC location.
> The datasets are unfortunately incompatible and the whole thing is
> undocumented because we never made the switch official.
>
> https://grass.osgeo.org/download/sample-data/
>
> But since NC basic will be replaced by standardized sample dataset (which
> is partially reason for the confusing situation), use this new dataset
> instead.
>
> https://trac.osgeo.org/grass/wiki/SampleDataset (goes here:
> http://www4.ncsu.edu/~hmitaso/grasswork/grassbookdat4ed/)
>
> Have you noticed that you can view the errors in an HTML report?
>
> "grass.gunittest.main writes a text summary to standard output and it
> creates an HTML report from all tests in all testsuite directories inside
> the directory tree. The report is placed in testreport by default. Open
> file testreport/index.html in you web browser to inspect it."
>
>
> https://grass.osgeo.org/grass71/manuals/libpython/gunittest_running_tests.html#running-tests-and-creating-report
>
> seths-mbp:grass-7.1.svn_src_snapshot_2015_09_19 sprice$ grass71 --text
>> ../nc_spm_08_grass7/PERMANENT/
>>
>> [...]
>>
>> GRASS 7.1.svn
>> (nc_spm_08_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 >
>> python -m grass.gunittest.main --location
>> /usr/local/grass/nc_spm_08_grass7/ --location-type nc
>>
>> test_g_list from ./general/g.list failed (1 test failed)
>>
>> test_g_remove from ./general/g.remove failed (2 tests failed)
>>
>> test_overwrite from ./general/g.rename failed (3 tests failed)
>> [...]
>>
>> test_vto3d from ./vector/v.to.3d failed (1 test failed)
>>
>> test_vwhat_layers from ./vector/v.what failed (1 test failed)
>>
>> test_vwhat_ncspm from ./vector/v.what failed (4 tests failed)
>>
>>
>> Executed 127 test files in 0:00:55.959398.
>>
>> From them 12 files (9%) were successful and 115 files (91%) failed.
>>
>> GRASS 7.1.svn
>> (nc_spm_08_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 >
>>
>> I'd really like to work on these unit tests. Any ideas as to where I'm
>> going wrong? I feel like I've exhausted the various knowledge bases
>> available online.
>> Thanks,
>> Seth
>>
>&g

Re: [GRASS-dev] I've tripled GRASS's I/O speed

[Seth Price]

Hi, I've spent the last two or three hours trying to get GRASS' unit tests
running. With a fresh source tree, the best I can get is ~9% of the tests
passing:

seths-mbp:grass-7.1.svn_src_snapshot_2015_09_19 sprice$ grass71 --text
../nc_spm_08_grass7/PERMANENT/

[...]

GRASS 7.1.svn
(nc_spm_08_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 >
python -m grass.gunittest.main --location
/usr/local/grass/nc_spm_08_grass7/ --location-type nc

test_g_list from ./general/g.list failed (1 test failed)

test_g_remove from ./general/g.remove failed (2 tests failed)

test_overwrite from ./general/g.rename failed (3 tests failed)
[...]

test_vto3d from ./vector/v.to.3d failed (1 test failed)

test_vwhat_layers from ./vector/v.what failed (1 test failed)

test_vwhat_ncspm from ./vector/v.what failed (4 tests failed)


Executed 127 test files in 0:00:55.959398.

>From them 12 files (9%) were successful and 115 files (91%) failed.

GRASS 7.1.svn
(nc_spm_08_grass7):/usr/local/grass/grass-7.1.svn_src_snapshot_2015_09_19 >

I'd really like to work on these unit tests. Any ideas as to where I'm
going wrong? I feel like I've exhausted the various knowledge bases
available online.
Thanks,
Seth


On Fri, Oct 2, 2015 at 11:25 AM, Vaclav Petras  wrote:

>
>
> On Fri, Oct 2, 2015 at 12:49 PM, Seth Price  wrote:
>
>> ..by adding the option of a few different compression schemes, including
>> LZ4. I've had the ticket open for a week now with no responses. I'd love to
>> get it incorporated into trunk. For more info, see here:
>> https://trac.osgeo.org/grass/ticket/2750
>>
>
> Hi,
>
> thanks for the reminder. This looks really good. Can you provide a test
> which would do a trivial operation (like the benchmark in the ticket)
> ideally using Python and gunittest [1]? Please, let me know if you don't
> know where to start.
>
> Vaclav
>
> [1]
> https://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] I've tripled GRASS's I/O speed

[Seth Price]

I imagine the best test will need pretty low level access to the cellhd
structure to look at the compression flags. Is that what you mean? Or would
a better way include looking at the output of `r.compress`?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] I've tripled GRASS's I/O speed

[Seth Price]

..by adding the option of a few different compression schemes, including
LZ4. I've had the ticket open for a week now with no responses. I'd love to
get it incorporated into trunk. For more info, see here:
https://trac.osgeo.org/grass/ticket/2750
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] 'make' hangs indefinitely on compiling with latest v7 weekly & trunk

[Seth Price]

If I compile the latest GRASS v7, 'make' gets to a point in the compile
and stops indefinitely. Does this happen for anyone else?

(I would report it in trac, but I don't have my password with me and it
sounds difficult to reset.)

Configure:
./configure  --with-freetype
--with-freetype-includes=/usr/local/include/freetype2 --with-opengl=aqua
--without-tcltk --with-libs=/usr/local/lib --enable-64bit --enable-shared
--with-cxx --with-python --with-openmp --with-sqlite

Make:
[...]
VERSION_NUMBER=7.0.svn
/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/tools/g.html2man.py
/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/docs/html/displaydrivers.html
/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/docs/man/man1/displaydrivers.1
make -C d.barscale || echo
/usr/local/grass/grass7_trunk/display/d.barscale >>
/usr/local/grass/grass7_trunk/error.log
test -d OBJ.x86_64-apple-darwin12.3.0 || mkdir -p
OBJ.x86_64-apple-darwin12.3.0
gcc  -g -O2  
-I/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/include
-I/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/include 
-D_FILE_OFFSET_BITS=64  -DPACKAGE=\""grassmods"\"  
-I/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/include
-I/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/include -o
OBJ.x86_64-apple-darwin12.3.0/draw_scale.o -c draw_scale.c
gcc  -g -O2  
-I/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/include
-I/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/include 
-D_FILE_OFFSET_BITS=64  -DPACKAGE=\""grassmods"\"  
-I/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/include
-I/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/include -o
OBJ.x86_64-apple-darwin12.3.0/main.o -c main.c
: && gcc
-L/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/lib
-L/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/lib
-L/usr/local/lib   -o
/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/bin/d.barscale
OBJ.x86_64-apple-darwin12.3.0/draw_scale.o
OBJ.x86_64-apple-darwin12.3.0/main.o-lgrass_display.7.0.svn
-lgrass_gis.7.0.svn
if [
"/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/bin/d.barscale"
!= "" ] ; then
GISRC=/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/demolocation/.grassrc70
GISBASE=/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0
PATH="/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/bin:/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/bin:$PATH"
PYTHONPATH="/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/etc/python:/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/etc/python:$PYTHONPATH"
DYLD_LIBRARY_PATH="/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/bin:/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/lib:/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/lib:"
LC_ALL=C
/usr/local/grass/grass7_trunk/dist.x86_64-apple-darwin12.3.0/bin/d.barscale
--html-description < /dev/null | grep -v '\|' >
d.barscale.tmp.html ; fi
^Cmake[3]: *** Deleting file `d.barscale.tmp.html'
make[3]: *** [d.barscale.tmp.html] Error 130
make[2]: *** [d.barscale] Interrupt: 2
make[1]: *** [subdirs] Interrupt: 2
make: *** [default] Interrupt: 2

grass7_trunk sprice$


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Ignored enhancements

[Seth Price]

It's been a while, but I think one motivating factor is the limiting GPU RAM. 
If we can't fit everything on the GPU, then it needs to be tiled. The only way 
to accurately tile is to make each tile independent of its surroundings. This 
can be done arbitrarily small with pre computed horizons.

I think the other reason is the whole pre computation (but only once) thing you 
mention.

I don't think it bothers me too much at the moment what you decide to do with 
it, but the shadowing & tiling code becomes more complicated to compensate.
~Seth


via iPhone

On Feb 12, 2013, at 2:10 AM, Hamish  wrote:

> Doug wrote:
>> I appreciate the effort.
> 
> (me too :)
> 
>>  Working with  large rasters, this will make a big difference! 
> 
> with respect to r.hozion, I'm still trying to understand where
> the best use case for it is.
> 
> the idea as I understand it (which is not completely) is that
> it precomutes some of what r.sun does, so that the r.sun module
> runs faster. But the r.sun module places the sun exactly where
> it wants it, while r.horizon must make some compromise and
> approximate the position. to get any sort of reasonable placement
> you'd need upwards of 100 seed maps, but since r.sun must open
> them all at once the performance hit you take from the extra
> overhead cancels out the speed gain. And so you have more disk
> I/O with worse positioning -- better not to have used r.horizon
> at all?
> 
> see further discussion and benchmarking in "r.sun2 commissioning
> trials":
>  http://trac.osgeo.org/grass/ticket/498
> 
> and on the r.sun page in the wiki:
>  http://grasswiki.osgeo.org/wiki/R.sun#Seed_maps
> 
> 
> thanks for any light you can shed on this, it has puzzled me
> for a while.
> 
> 
> Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Ignored enhancements

[Seth Price]

They should. I didn't really make any changes to the calculations, I just 
rearranged the code to make it more processor and compiler friendly.

~Seth


via iPhone

On Feb 9, 2013, at 3:27 PM, "Newcomb, Doug"  wrote:

> Seth,
> I finally got a chance to patch your enhancements from the GRASS 70 svn code 
> I pulled last night.
> 
> I compiled with these options:
> ./configure --with-gdal  --with-freetype 
> --with-freetype-includes=/usr/include/freetype2 --with-proj   --with-sqlite 
> --enable-largefile --with-cxx --enable-64bit  --with-python  --with-blas 
> --with-lapack  --with-cairo  --with-wxwidgets --with-spatialite --with-tcltk 
> --with-tcltk-includes=/usr/include/tcl8.4 
> --with-liblas=/usr/local/bin/liblas-config --enable-largefile --with-openmp 
> --with-readline
> 
> The computer uses an AMD Vishera 8 core cpu with 8GB DDR3 1333 RAM  ( freshly 
> updated home machine)
> 
> 
> I used this 23 million cell raster of 20ft bare earth elevation in the 
> mountains of western North Carolina.
> 
> 
>  Layer:nc_1@PERMANENT Date: Thu Jul  5 20:56:51 2012|
>  | Mapset:   PERMANENT  Login of Creator: dnewcomb
> |
>  | Location: ncstpft  
> |
>  | DataBase: /data1/grass7
> |
>  | Title:bilinear interpolation with Tykhonov regularization ( nc_1 ) 
> |
>  | Timestamp: none
> |
>  
> ||
>  |
> |
>  |   Type of Map:  raster   Number of Categories: 7000
> |
>  |   Data Type:DCELL  
> |
>  |   Rows: 5328   
> |
>  |   Columns:  4375   
> |
>  |   Total Cells:  2331   
> |
>  |Projection: Lambert Conformal Conic 
> |
>  |N: 593000S: 486439   Res: 20.00018769   
> |
>  |E: 492500W: 405000   Res:20 
> |
>  |   Range of data:min = -8269.7102472716  max = 6999.76272107517 
> |
>  |
> |
>  |   Data Description:
> |
>  |generated by v.surf.bspline 
> |
>  |
> |
>  |   Comments:
> |
>  |v.surf.bspline -z input="nc_1@PERMANENT" raster="nc_1" sie=40 sin=40\   
> |
>  | method="bilinear" lambda_i=0.01 layer="1" solver="cholesky" maxit=1\   
> |
>  |00 error=0.01 memory=300
> |
>  |
> |
>  
> ++
> 
> 
> First, with the default GRASS 7 svn pull from 2/9
> 
> GRASS 7.0.svn (ncstpft):~ > time r.horizon -d elevin=nc_1 horizonstep=90 
> horizon=test_normal
> Calculating map 1 of 4 (angle 0.00, raster map )
>  100%
> Calculating map 2 of 4 (angle 90.00, raster map )
>  100%
> Calculating map 3 of 4 (angle 180.00, raster map )
>  100%
> Calculating map 4 of 4 (angle 270.00, raster map )
>  100%
> 
> real  16m14.028s
> user  16m11.993s
> sys   0m1.860s
> 
> 
> Second, patching r.horizon main.c with the diff file from your patch.
> 
> GRASS 7.0.svn (ncstpft):~ > time r.horizon -d elevin=nc_1 horizonstep=90 
> horizon=test_price
> Calculating map 1 of 4 (angle 0.00, raster map )
>  100%
> Calculating map 2 of 4 (angle 90.00, raster map )
>  100%
> Calculating map 3 of 4 (angle 180.00, raster map )
>  100%
> Calculating map 4 of 4 (angle 270.00, raster map )
>  100%
> 
> real  14m22.607s
> user  14m20.582s
> sys   0m1.836s
> 
> Using r.mapcal to subtract the normal r.horizon calculation from the modified 
> calculation shows 0 difference between the two results
> 
> I usually run r.horizon on a 755 million cell grid and do 24 horizons, I am 
> assuming the the benefits would scale proportionally?
> 
> 
> Doug
>  
> 
> 

[GRASS-dev] Ignored enhancements

[Seth Price]

A while ago I made some simple, but significant, enhancements and submitted 
them to trac. They haven't been picked up, so I wanted to point them out so 
someone can commit them before they diverge from the trunk.

http://trac.osgeo.org/grass/ticket/1624

This has had some activity recently, but it's status is still "new" and it 
isn't in trunk.

http://trac.osgeo.org/grass/ticket/1575

~Seth


via iPhone___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Parallel computing for r.sun

[Seth Price]

On the Mac, you're compiling with "-framework OpenCL"

~Seth


via iPhone

On Jan 29, 2013, at 9:14 PM, Yann Chemin  wrote:

> Hi Hamish,
> 
> """
> the first step is to get support for OpenCL build into grass7's
> ./configure next to pthreads and OpenMP which are already there.
> I welcome help with that, my copious free time hasn't been
> very good lately.
> """
> 
> I am heading to the code sprint in Genoa on Sunday,
> Could you spend a little time explaining me the directions to do that?
> (URL, PDF, anything welcome)
> 
> 
> Cheers,
> Yann
> 
> 
> On 30 January 2013 08:19, Hamish  wrote:
>> Yann wrote:
>> > anyone has a timeline for merging the OpenCL code into trunk?
>> 
>> Hi,
>> 
>> that's been on my todo list for way too long.
>> 
>> the first step is to get support for OpenCL build into grass7's
>> ./configure next to pthreads and OpenMP which are already there.
>> I welcome help with that, my copious free time hasn't been
>> very good lately.
>> 
>> The removal of tertiary calls from the main r.sun loop has
>> already been done in trunk.
>> 
>> I'll try to write more after work, but a lot is explained
>> on these pages:
>>   http://grasswiki.osgeo.org/wiki/Category:Parallelization
>> 
>> besides the r.sun work already done, AFAIAC the top candidates
>> for parallelization in GRASS are v.surf.rst and v.surf.bspline.
>> Currently there is some support directly in the LU decomposition
>> but that makes 1000s of threads; the cost of creating and
>> destroying those is coming down a lot, but I think it will
>> probably be a lot more efficient to only create dozens of
>> threads in the case of v.surf.bspline (see code comment at
>> the start of the loop where the OpenMP support could go)
>> and for v.surf.rst perhaps multithread the various boxes of
>> the quadtree?  The idea being to more closely match the
>> number of threads/processes with the number of CPUs or GPUs.
>> For CPUs that means dozens, for GPUs that means hundreds.
>> 
>> Each module will be different, so each one requires its own
>> approach. For that reason I'm happy for pthreads, OpenMP,
>> and OpenCL to all be supported.
>> 
>> various python and bourne shell scripts (quite new so not
>> backported to 6.4.svn yet) have been parallelized; the easy
>> win is to run the three R,G,B bands in parallel. It only
>> scales to 3 CPUs, but is nearly perfectly efficient and a 3x
>> speedup is as good as any. See the v.surf.icw script in both
>> g6.sh and g7.py addons for a complete example.
>> 
>> the good news is that slowly the opencl apis are making their
>> way into the mainstream driver releases, even intel is on board.
>> before you pretty much needed to tailor your linux distro to
>> match their SDK release target if you wanted to use it; and
>> then the SDK didn't match with the available driver version,
>> and other such pain..
>> 
>> I'm not sure of what modules in GRASS besides r.sun are well
>> suited to GPU acceleration. r.sun as a ray-tracing exercise
>> was an obvious one as that's what GPUs are generally designed
>> to do these days. Much, if not most, of GRASS's modules are
>> I/O limited, and especially I/O to the video card has
>> traditionally been really slow. (that's getting better to, but
>> still a little on the horizon).
>> 
>> another thing to consider is that GPU math on consumer-grade
>> video cards have been traditionally limited to float()s. you
>> had to buy the expensive "science grade" one if you wanted to
>> calc using double prec. FPs.
>> 
>> great leaps can be made, but there are some caveats to consider.
>> 
>> 
>> best,
>> Hamish
> 
> 
> 
> -- 
> Yann Chemin
> Researcher@IWMI
> Skype/FB: yann.chemin
> 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Parallel computing for r.sun

[Seth Price]

I rewrote r.sun into OpenCL a while ago for a google summer of code project. I 
believe the source is public in github, but never got merged into trunk.
~Seth


via iPhone

On Jan 29, 2013, at 8:01 AM, Yann Chemin  wrote:

> Hi,
> 
> OpenMP first to leverage the actual CPU development routes.
> OpenCL second to leverage the actual GPU routes.
> 
> Cheers,
> Yann
> 
> 
> 
> On 29 January 2013 19:11, Newcomb, Doug  wrote:
>> I would vote for multicore OpenMP/OPENCL.  I just purchased an 8 core AMD 
>> Vishera MB and CPU combo for under $300US to use at home , which is faster 
>> than the 8 core Xeon server system I used to do statewide solar irradiation 
>> modeling at work  for a 755 Million cell grid for 365 days (half hour 
>> increments)  in 2011. With the advances in multicore architecture ( who 
>> knows what core densities ARM will bring?) and utilization of the processing 
>> elements in video cards, I think you will benefit many more users on going 
>> the multicore route.
>> 
>> Doug
>> 
>> 
>> On Tue, Jan 29, 2013 at 8:05 AM, Ruzicka Jan  wrote:
>>> Dear developers,
>>> 
>>> We are planning to rewrite the module r.sun for parallel computation and 
>>> would like to ask you, which platform is more desired by the GRASS 
>>> community. To our understanding there are two main ways of development. 
>>> Either we design it for multi-core desktop systems that use shared memory 
>>> (for example with use of OpenMP) or create module for large clusters with 
>>> use of MPI library.
>>> 
>>> Which way do you think would benefit GRASS more?
>>> 
>>> Best regards
>>> 
>>> Jan Ruzicka
>>> ___
>>> grass-dev mailing list
>>> grass-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>> 
>> 
>> 
>> -- 
>> Doug Newcomb
>> USFWS
>> Raleigh, NC
>> 919-856-4520 ext. 14 doug_newc...@fws.gov
>> -
>> The opinions I express are my own and are not representative of the official 
>> policy of the U.S.Fish and Wildlife Service or Dept. of the Interior.   Life 
>> is too short for undocumented, proprietary data formats.
>> 
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 
> 
> 
> -- 
> Yann Chemin
> Researcher@IWMI
> Skype/FB: yann.chemin
> 
> ___
> 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

Re: [GRASS-dev] Parallel computing for r.sun

[Seth Price]

Also, OpenCL can run as both multicore CPU and GPU. OpenMP can only run on CPU 
but it's much easier to program. I vaguely recall the OpenCL speed up over 
single thread on the order of 20x - 50x. If you're looking for a consultant to 
do additional OpenCL work, I might be able to help.
~Seth

via iPhone

On Jan 29, 2013, at 8:01 AM, Yann Chemin  wrote:

> Hi,
> 
> OpenMP first to leverage the actual CPU development routes.
> OpenCL second to leverage the actual GPU routes.
> 
> Cheers,
> Yann
> 
> 
> 
> On 29 January 2013 19:11, Newcomb, Doug  wrote:
>> I would vote for multicore OpenMP/OPENCL.  I just purchased an 8 core AMD 
>> Vishera MB and CPU combo for under $300US to use at home , which is faster 
>> than the 8 core Xeon server system I used to do statewide solar irradiation 
>> modeling at work  for a 755 Million cell grid for 365 days (half hour 
>> increments)  in 2011. With the advances in multicore architecture ( who 
>> knows what core densities ARM will bring?) and utilization of the processing 
>> elements in video cards, I think you will benefit many more users on going 
>> the multicore route.
>> 
>> Doug
>> 
>> 
>> On Tue, Jan 29, 2013 at 8:05 AM, Ruzicka Jan  wrote:
>>> Dear developers,
>>> 
>>> We are planning to rewrite the module r.sun for parallel computation and 
>>> would like to ask you, which platform is more desired by the GRASS 
>>> community. To our understanding there are two main ways of development. 
>>> Either we design it for multi-core desktop systems that use shared memory 
>>> (for example with use of OpenMP) or create module for large clusters with 
>>> use of MPI library.
>>> 
>>> Which way do you think would benefit GRASS more?
>>> 
>>> Best regards
>>> 
>>> Jan Ruzicka
>>> ___
>>> grass-dev mailing list
>>> grass-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>> 
>> 
>> 
>> -- 
>> Doug Newcomb
>> USFWS
>> Raleigh, NC
>> 919-856-4520 ext. 14 doug_newc...@fws.gov
>> -
>> The opinions I express are my own and are not representative of the official 
>> policy of the U.S.Fish and Wildlife Service or Dept. of the Interior.   Life 
>> is too short for undocumented, proprietary data formats.
>> 
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
> 
> 
> 
> -- 
> Yann Chemin
> Researcher@IWMI
> Skype/FB: yann.chemin
> 
> ___
> 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

[GRASS-dev] Building a vector topology (and failing)

[Seth Price]

Hey all, I've been trying to get my topology to build for a while now in my 
module, and I'm not getting anywhere. I currently have it to the point where 
I'm simply trying to draw a triangle with corners (0,0), (0,100), & (100,0). It 
calls Vect_append_point() three times, then Vect_write_line(,GV_BOUNDARY,,) to 
create the polygon. When building the topology, it fails to create an area with 
"WARNING: Number of incorrect boundaries: 1".

I'm used to raster programming, but I would think that this would work. You can 
see in the debug that the error shouldn't happen. There aren't duplicate 
angles. I'm using a recent SVN of GRASS 7.0. Anyone have any idea what I'm 
doing wrong? Below is the relevant debug output.
Thanks,
Seth

[...]
Registering primitives...
D3/3: Vect_read_next_line()
D3/3: V1_read_next_line_nat()
D3/3: Vect__Read_line_nat: offset = 18
D3/3: type = 4, do_cats = 1 dead = 0
D3/3: n_cats = 1
D3/3: n_points = 3
D3/3: off = 107
D3/3: Register line: offset = 18
D3/3: dig_spidx_add_line(): line = 1
D3/3: Register node: type = 4,  589971.509972,5300028.490028
D3/3: dig_find_node()
D3/3: node = 0
D3/3: dig_add_node(): n_nodes = 0, alloc_nodes = 0
D3/3: dig_spidx_add_node(): node = 1, x,y,z = 589971.509972, 5300028.490028, 
0.00
D3/3: new node = 1, n_nodes = 1, alloc_nodes = 1000
D3/3: Add new node: 1
D3/3: dig_node_add_line(): node = 1 line = 1
D3/3: dig_node_alloc_line(): add = 1
D3/3: angle = -1.570796
D3/3: dig_node_add_line(): line 1 added position 0 n_lines: 1 angle -1.570796
D3/3: Register node 591396.011396,5300028.490028
D3/3: dig_find_node()
D3/3: node = 0
D3/3: dig_add_node(): n_nodes = 1, alloc_nodes = 1000
D3/3: dig_spidx_add_node(): node = 2, x,y,z = 591396.011396, 5300028.490028, 
0.00
D3/3: new node = 2, n_nodes = 2, alloc_nodes = 1000
D3/3: Add new node: 2
D3/3: dig_node_add_line(): node = 2 line = -1
D3/3: dig_node_alloc_line(): add = 1
D3/3: angle = -2.356194
D3/3: dig_node_add_line(): line -1 added position 0 n_lines: 1 angle -2.356194
D3/3: dig_cidx_add_cat(): field = 4 cat = 1 line = 1 type = 4
D3/3: Vect_read_next_line()
D3/3: V1_read_next_line_nat()
D3/3: Vect__Read_line_nat: offset = 107
1 primitives registered
3 vertices registered
Building areas...
 100%
D3/3: Build area for line = 1, side = 1
D3/3: Vect_build_line_area() line = 1, side = 1
D3/3: dig_line_get_area(): line = 1, side = 1 (left), area = 0
D3/3: dig_build_area_with_line(): first_line = 1, side = 1
D3/3: dig_node_line_angle: node = 1 line = 1
D3/3: dig__angle_next_line: line = 1, side = 2, type = 4
D3/3:  node = 1
D3/3:   n_lines = 1
D3/3:   i = 0 line = 1 angle = -1.570796
D3/3:   current position = 0
D3/3:   next = 0 line = 1 angle = -1.570796
D3/3:   this one
D3/3: next_line = 1
D3/3: dig_node_angle_check: line = 1, type = 4
D3/3: dig_node_line_angle: node = 1 line = 1
D3/3: dig__angle_next_line: line = 1, side = 2, type = 4
D3/3:  node = 1
D3/3:   n_lines = 1
D3/3:   i = 0 line = 1 angle = -1.570796
D3/3:   current position = 0
D3/3:   next = 0 line = 1 angle = -1.570796
D3/3:   this one
D3/3: dig_node_line_angle: node = 1 line = 1
D3/3:   The line to the right has the same angle: node = 1, line = 1
D3/3: Cannot build area, a neighbour of the line 1 has the same angle at the 
node
D3/3:   n_lines = 0
D3/3: Build area for line = 1, side = 2
D3/3: Vect_build_line_area() line = 1, side = 2
D3/3: dig_line_get_area(): line = 1, side = 2 (right), area = 0
D3/3: dig_build_area_with_line(): first_line = 1, side = 2
D3/3: dig_node_line_angle: node = 1 line = 1
D3/3: dig__angle_next_line: line = -1, side = 2, type = 4
D3/3:  node = 2
D3/3:   n_lines = 1
D3/3:   i = 0 line = -1 angle = -2.356194
D3/3:   current position = 0
D3/3:   next = 0 line = -1 angle = -2.356194
D3/3:   this one
D3/3: next_line = -1
D3/3: dig_node_angle_check: line = -1, type = 4
D3/3: dig_node_line_angle: node = 2 line = -1
D3/3: dig__angle_next_line: line = -1, side = 2, type = 4
D3/3:  node = 2
D3/3:   n_lines = 1
D3/3:   i = 0 line = -1 angle = -2.356194
D3/3:   current position = 0
D3/3:   next = 0 line = -1 angle = -2.356194
D3/3:   this one
D3/3: dig_node_line_angle: node = 2 line = -1
D3/3:   The line to the right has the same angle: node = 2, line = -1
D3/3: Cannot build area, a neighbour of the line -1 has the same angle at the 
node
D3/3:   n_lines = 0
0 areas built
0 isles built
[...]___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] r.horizion bugfix and speedup

[Seth Price]

I made some tweaks to r.horizon/main.c to almost half its runtime and
remove a bug. By my tests, it's output is identical to before, but a 219
minute run has been reduced to 110 minutes. Mostly due to removal of
unneeded floor() calls. I could use some people to test and make sure I'm
not introducing any bugs, though.
Thanks,
Seth

--- main.orig   2011-08-14 06:32:49.0 -0600
+++ main.c  2012-02-12 19:20:15.0 -0700
@@ -144,12 +144,15 @@
 /* use G_distance() instead ??!?! */
 double distance(double x1, double x2, double y1, double y2)
 {
+   double diffX = x1 - x2;
+   double diffY = y1 - y2;
+
 if (ll_correction) {
-   return DEGREEINMETERS * sqrt(coslatsq * (x1 - x2) * (x1 - x2)
-+ (y1 - y2) * (y1 - y2));
+   return DEGREEINMETERS * sqrt(coslatsq * diffX * diffX
++ diffY * diffY);
 }
 else {
-   return sqrt((x1 - x2) * (x1 - x2) + (y1 - y2) * (y1 - y2));
+   return sqrt(diffX * diffX + diffY * diffY);
 }
 }

@@ -841,36 +844,28 @@

 int new_point()
 {
-int iold, jold;
-int succes = 1, succes2 = 1;
-double sx, sy;
-double dx, dy;
-
-iold = ip;
-jold = jp;
+int iold = ip;
+int jold = jp;

-while (succes) {
+while (1) {
yy0 += stepsinangle;
xx0 += stepcosangle;


/* offset 0.5 cell size to get the right cell i, j */
-   sx = xx0 * invstepx + offsetx;
-   sy = yy0 * invstepy + offsety;
-   ip = (int)sx;
-   jp = (int)sy;
+   ip = (int) (xx0 * invstepx + offsetx);
+   jp = (int) (yy0 * invstepy + offsety);

/* test outside of raster */
if ((ip < 0) || (ip >= n) || (jp < 0) || (jp >= m))
return (3);

if ((ip != iold) || (jp != jold)) {
-   dx = (double)ip *stepx;
-   dy = (double)jp *stepy;
+   double dx = (double)ip *stepx;
+   double dy = (double)jp *stepy;

length = distance(xg0, dx, yg0, dy);  /* dist from orig. grid point
to the current grid point */
-   succes2 = test_low_res();
-   if (succes2 == 1) {
+   if (test_low_res() == 1) {
zp = z[jp][ip];
return (1);
}
@@ -882,54 +877,44 @@

 int test_low_res()
 {
-int iold100, jold100;
-double sx, sy;
-int delx, dely, mindel;
-double zp100, z2, curvature_diff;
-
-iold100 = ip100;
-jold100 = jp100;
-ip100 = floor(ip / 100.);
-jp100 = floor(jp / 100.);
+int iold100 = ip100;
+int jold100 = jp100;
+ip100 = ip * .01;
+jp100 = jp * .01;
 /*test the new position with low resolution */
 if ((ip100 != iold100) || (jp100 != jold100)) {
/* G_debug(3,"%d %d %d %d\n",ip,jp, iold100,jold100); */
/*  replace with approximate version
   curvature_diff = EARTHRADIUS*(1.-cos(length/EARTHRADIUS));
-*/
+
+   Code folded into the 'if' statement:
curvature_diff = 0.5 * length * length * invEarth;
z2 = z_orig + curvature_diff + length * tanh0;
zp100 = z100[jp100][ip100];
+   if (zp100 <= z2) {...
+*/
/*G_debug(3,"%d %d %lf %lf \n",ip,jp,z2,zp100); */

-   if (zp100 <= z2)
+   if (z100[jp100][ip100] <= z_orig + 0.5 * length * length * invEarth +
length * tanh0)
/*skip to the next lowres cell */
{
-   delx = 32000;
-   dely = 32000;
+   int mindel;
+   int delx = 32000;
+   int dely = 32000;
+   double sx = (xx0 * invstepx + offsetx) * .01;
+   double sy = (yy0 * invstepy + offsety) * .01;
+
if (cosangle > 0.) {
-   sx = xx0 * invstepx + offsetx;
-   delx =
-   floor(fabs
- ((ceil(sx / 100.) - (sx / 100.)) * distcosangle));
+   delx = fabs((ceil(sx) - sx) * distcosangle);
}
-   if (cosangle < 0.) {
-   sx = xx0 * invstepx + offsetx;
-   delx =
-   floor(fabs
- ((floor(sx / 100.) - (sx / 100.)) * distcosangle));
+   else if (cosangle < 0.) {
+   delx = fabs((floor(sx) - sx) * distcosangle);
}
if (sinangle > 0.) {
-   sy = yy0 * invstepy + offsety;
-   dely =
-   floor(fabs
- ((ceil(sy / 100.) - (sy / 100.)) * distsinangle));
+   dely = fabs((ceil(sy) - sy) * distsinangle);
}
else if (sinangle < 0.) {
-   sy = yy0 * invstepy + offsety;
-   dely =
-   floor(fabs
- ((floor(jp / 100.) - (sy / 100.)) * distsinangle));
+   dely = fabs((floor(sy) - sy) * distsinangle);
}

mindel = min(delx, dely);
@@ -953,17 +938,14 @@

 double searching()
 {
-double z2;
-double curvature_diff;
-int succes =

Re: [GRASS-dev] parallelizing GRASS modules

[Seth Price]

If you decide to use opencl, keep in contact and I might be able to help. I'm 
traveling for at least the next few days, though.

~Seth


via iPhone

On Dec 3, 2011, at 3:07 PM, Barton Michael  wrote:

> I lost the previous thread but wanted to respond to your question about which 
> modules might benefit from speedup.
> 
> In our recursive landscape evolution module (r.landscape.evol.py), the two 
> GRASS modules that take the most time are r.watershed, r.stats, and r.walk, 
> especially r.watershed and r.stats since we need to run these every model 
> cycle. 
> 
> The speedup of r.watershed of a few years back made an enormous difference in 
> our model run times. But it is still time consuming on landscapes with large 
> numbers of cells. If parallelization could speed this up, it would be great. 
> I'm not sure that r.stats can be parallelized or not, but speedup would be 
> helpful.
> 
> 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

[GRASS-dev] r.sun: Now Available in OpenCL!

[Seth Price]

Hey all, good news! I now have r.sun written to run in OpenCL in GRASS  
7. My test shows a 20x speedup over the original code. ("r.sun  
numpartitions=3 elevin=gauss glob_rad=glob_rad_ocl day=180")


Feel free to download the code from here:
http://github.com/mailseth/OpenCL-integration-for-GRASS---GDAL

It's currently setup for compiling on my machine, a Mac. You'll need  
to play with the makefile to get it to work otherwise.


I've only done limited testing, so if you find something that makes it  
error, please send a helpful bug report my direction. You could also  
send me a data file and the exact commands needed to replicate the  
problem.

~Seth
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Rast_set_window() changes in 7.0

[Seth Price]

I'm getting an error whenever I run r.sun under the latest weekly:
ERROR: Output window changed while maps are open for write

Here's the command I'm using:
r.sun numpartitions=2 elevin=gauss glob_rad=glob_rad_out day=180

Is this related to your work? Should I make a bug report?
~Seth


On Jul 22, 2010, at 12:57 AM, Glynn Clements wrote:



r42876 implements a fairly invasive change to the raster window
handling in 7.0. Specifically:

1. Modules which read and write maps at different resolutions now make
use of the ability to set separate input and output windows
(Rast_set_input_window() and Rast_set_output_window()).

2. Changing the input/output window while maps are open for read/write
(respectively) now generates a fatal error. There should be no need to
do so, and I want to get bug reports for any cases I've overlooked.
Rast_set_window() changes both the input and output windows.

I would appreciate it if people can test any affected modules.
Specifically, the following are the modules and libraries which called
Rast_set_window:

display/d.rast.arrow
display/d.rast.num
general/g.region
imagery/i.atcorr
imagery/i.ifft
imagery/i.rectify
lib/display
lib/gpde
lib/lidar
lib/rst/interp_float
ps/ps.map
raster/r.basins.fill
raster/r.category
raster/r.coin
raster/r.compress
raster/r.describe
raster/r.external
raster/r.flow
raster/r.horizon
raster/r.in.arc
raster/r.in.ascii
raster/r.in.bin
raster/r.in.gdal
raster/r.in.gridatb
raster/r.in.mat
raster/r.in.png
raster/r.in.poly
raster/r.neighbors
raster/r.null
raster/r.proj
raster/r.recode
raster/r.resamp.bspline
raster/r.resamp.filter
raster/r.resamp.interp
raster/r.resamp.rst
raster/r.resamp.stats
raster/r.rescale
raster/r.slope.aspect
raster/r.sun
raster/r.support.stats
raster/r.support
raster/r.surf.idw2
raster/r.to.rast3
raster/r.to.rast3elev
raster/simwe/simlib
raster3d/r3.cross.rast
raster3d/r3.out.vtk
raster3d/r3.to.rast

In particular, anything using the gpde, lidar or rst libraries should
be a priority.

FWIW, the rationale behind the "split window" functionality is to
avoid having r.resamp.* continually changing the window between the
input and output resolutions, as this causes the column mapping to be
regenerated for the input map each time.

--
Glynn Clements 
___
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

Re: [GRASS-dev] r.sun and pj_do_proj() calls

[Seth Price]

Should I go with Hamish's patch in the previous email, or is there  
some ongoing work here? I think I'm getting ready to push to finish  
OpenCL r.sun.

~Seth


On Aug 1, 2010, at 12:07 AM, Jaro Hofierka wrote:


Hi Hamish,

Many thanks for your great work!
I expected some kind of skewness in the svn version, because it  
always seeks a point in one direction:


   delt_lat = -0.0001 * cos(inputAngle);  /* Arbitrary small  
distance in latitude */

   delt_lon = 0.0001 * sin(inputAngle) / cos(latitude);


My idea is that perhaps the easiest way to deal with the meridian  
convergence would be to do all calculations in lat-lon, even for  
cartesian systems.
Even now we call pj_do_proj() to get lat-lon for every grid point in  
main.c, so it might be more convenient to get the lat-lon values in  
the beginning and then do everything in lat-lon.


Kind regards,

Jaro


Hamish wrote:

Hi,

As suggested by Jaro, by
- commenting out all the pj_do_proj() stuff, and
- re-enabling sin(sunVarGeom->sunAzimuthAngle), and
- using the -s shading flag, and
- not using horizon maps,

I get the same exact output values as with my patch (attached), which
replaces the proper pj_do_proj() reprojection with a simple cosine
pseudo-projection.

Both Jaro's and my patches give slightly different results than the
current SVN version based on pj_do_proj(). Looking at the test  
results
from using a Gaussian mound the pj_() version seems to be rotated  
counter-
clockwise by a little bit compared to the others. My best guess is  
that

this is due to the 0.9 degree difference between grid-north and
true-north at this site (`g.region -n`), as it is the pj_do_proj()
version which seems to be slightly askew, the others seem to be
symmetric. But perhaps that rotation is more than 1 deg?


# spearfish dataset
g.region -dp
r.surf.volcano out=gauss method=gaussian kurtosis=1


# current r.sun in grass 6.5svn ( using pj_do_proj() )
time r.sun -s elevin="gauss" glob_rad="rad.global.30minT.65svn"  
day=180

step=0.5 real3m19.480s
  user3m6.108s
  sys 0m2.500s


# Jaro's patch ( revert back to setting from sunAzimuthAngle )
time r.sun -s elevin="gauss" glob_rad="rad.global. 
30minT.sunAzimuthAngle"

day=180 step=0.5 real2m58.834s
  user2m50.555s
  sys 0m1.188s


# My patch ( attached; replace pj_do_proj() with lon*cos(lat)  
scaling )
time r.sun -s elevin="gauss" glob_rad="rad.global.30minT.coslat"  
day=180

step=0.5 real3m12.652s
  user2m52.727s
  sys 0m1.424s



# compare results
for map in 65svn sunAzimuthAngle coslat ; do
  echo "[$map]"
  r.univar rad.global.30minT.$map -g | grep 'mean=\|stddev=\|sum='
  echo
done

[65svn]
mean=8788.2168789737
stddev=40.3700050839272
sum=2657714972.10546875

[sunAzimuthAngle]
mean=8788.04781049377
stddev=40.3848632592666
sum=2657663842.75390625

[coslat]
mean=8788.04781049377
stddev=40.3848632592666
sum=2657663842.75390625


# view
d.erase
for map in 65svn sunAzimuthAngle coslat ; do
   echo "[$map]"; d.rast rad.global.30minT.$map
   d.title -s rad.global.30minT.$map | d.text
   read
done


(the Gaussian mound also shows why a small step size like 0.05 is so
important, which may finally be made practical by GPU acceleration.  
see

  http://grass.osgeo.org/wiki/r.sun#Time_step )


regards,
Hamish


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.sun and pj_do_proj() calls

[Seth Price]

I'm looking for when that pj_do_proj() call was added (and by whom and  
why). I'm looking for the full history of this file:

http://newtrac.osgeo.org/grass/browser/grass/trunk/raster/r.sun/rsunlib.c

I can't seem to go back far enough, though. This is the furthest I can  
get:

http://newtrac.osgeo.org/grass/browser/grass/trunk/raster/r.sun2/rsunlib.c?rev=34556

Which came from here:
http://newtrac.osgeo.org/grass/log/grass-addons/r.sun_horizon/r.sun2/rsunlib.c?rev=25783

The comments say it came from JRC, but what is that?


I do see that the original function didn't use pj_do_proj(), but I'm  
not sure why it was added:

http://newtrac.osgeo.org/grass/browser/grass/trunk/raster/r.sun/main.c?rev=38127


Does anyone know what revision pj_do_proj() was added in?
~Seth



On Jun 9, 2010, at 10:16 PM, Yann Chemin wrote:


to make things faster (and maybe more consistent), it may just be
better to have lat and long rasters as input to r.sun, instead of
repeatingly calling for a function to convert them.


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.sun and pj_do_proj() calls

[Seth Price]

For reference, this page seems to make a reasonable attempt at  
explaining the calculations:

http://re.jrc.ec.europa.eu/pvgis/solres/solmod3.htm

~Seth


On Jun 9, 2010, at 9:45 PM, Jaro Hofierka wrote:




Seth Price wrote:
Does latin/longin work for both locations that pj_do_proj() is  
called,
or just the one in main.c? It looked like some additional  
calculations

were done in the rsunlib.c call.


In my opinion pj_do_proj() should be called only once, in main.c. I  
don't see a real reason why it is also in rsunlib.c, so I believe it  
should be commented out here. If I recall correctly rsunlib.c was  
created by Thomas so I hope he can confirm this.


Jaro




Would you be able to write some additional code that uses latin/ 
longin
for the rsunlib.c call? I fear screwing it up because I'm not sure  
what

it's doing there.

Thanks,
Seth


On Jun 9, 2010, at 9:19 PM, Jaro Hofierka wrote:




Markus Neteler wrote:

On Wed, Jun 9, 2010 at 6:00 PM, Glynn
Clements wrote:


Seth Price wrote:

I'm working on translating r.sun to OpenCL to run on the GPU,  
but I've
hit a bit of a snag. I'm hoping y'all can help or at least tell  
me

what I'm looking at.

The root of it is that I can't call pj_do_proj() from within the
OpenCL kernel, so I need to pass that in from the outside. For
example, on line 1824 of main.c in the current SVN has us  
calculating
the lat/long if we aren't passed in files latin and longin. So  
for the
OpenCL version I'll need to make latin and longin arrays ahead  
of time

instead of calculating it in the loop.

The problem is in rsunlib.c at line 250. How can I avoid this
pj_do_proj() call? I was thinking that because I have the lat/ 
long

coordinates for all points, I can use that on lines 255& 256,
effectively changing G_projection() to return PROJECTION_LL and
avoiding going into the 'if' statement. I don't know if that will
work, though. I really don't know what's going on here enough  
to feel

comfortable changing the calculation.

Suggestions? Code?



Hi Seth,

Maybe Thomas Huld can answer this better than me, but just a small
explanation how it should work.

r.sun effectivelly needs latitude,longitude for every cell. So
intention with latin/longin rasters was to get these values in case
you don't have a projection defined in grass. If you have a  
cartesian

projection defined in grass, you can get lat/lon on the fly (e.g.
using pj_do_proj() or any other method). So if you are able to read
the lat/lon values for every cell by other method then you can  
disable

this call.

Jaro



I don't know the answer to this. But if no-one else does either,  
r.sun
should be disabled. An error is preferable to silently producing  
wrong

answers.


For sure. I have added the authors in bcc who may have suggestions.

Using different mechanisms for projection in different places  
looks
really suspicious. If there's a good reason for doing so, it  
should be
clearly documented. If there isn't a good reason, it should be  
fixed.

If no-one knows whether it's right or wrong, the module should be
disabled until we do know.


The first thing to do may be contacting the authors... done with  
this

email.

Markus






___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.sun and pj_do_proj() calls

[Seth Price]

I think that's the best solution for the OpenCL code I'm working on.  
However, with the normal code, computing the lat/long as needed may  
take less time, RAM, and hard drive space then pre-computing it. So  
either situation may be better, depending on how the code is run.

~Seth


On Jun 9, 2010, at 10:16 PM, Yann Chemin wrote:


to make things faster (and maybe more consistent), it may just be
better to have lat and long rasters as input to r.sun, instead of
repeatingly calling for a function to convert them.


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.sun and pj_do_proj() calls

[Seth Price]

Does latin/longin work for both locations that pj_do_proj() is called,  
or just the one in main.c? It looked like some additional calculations  
were done in the rsunlib.c call.


Would you be able to write some additional code that uses latin/longin  
for the rsunlib.c call? I fear screwing it up because I'm not sure  
what it's doing there.


Thanks,
Seth


On Jun 9, 2010, at 9:19 PM, Jaro Hofierka wrote:




Markus Neteler wrote:
On Wed, Jun 9, 2010 at 6:00 PM, Glynn Clements>  wrote:


Seth Price wrote:

I'm working on translating r.sun to OpenCL to run on the GPU, but  
I've

hit a bit of a snag. I'm hoping y'all can help or at least tell me
what I'm looking at.

The root of it is that I can't call pj_do_proj() from within the
OpenCL kernel, so I need to pass that in from the outside. For
example, on line 1824 of main.c in the current SVN has us  
calculating
the lat/long if we aren't passed in files latin and longin. So  
for the
OpenCL version I'll need to make latin and longin arrays ahead of  
time

instead of calculating it in the loop.

The problem is in rsunlib.c at line 250. How can I avoid this
pj_do_proj() call? I was thinking that because I have the lat/long
coordinates for all points, I can use that on lines 255&  256,
effectively changing G_projection() to return PROJECTION_LL and
avoiding going into the 'if' statement. I don't know if that will
work, though. I really don't know what's going on here enough to  
feel

comfortable changing the calculation.

Suggestions? Code?



Hi Seth,

Maybe Thomas Huld can answer this better than me, but just a small  
explanation how it should work.


r.sun effectivelly needs latitude,longitude for every cell. So  
intention with latin/longin rasters was to get these values in case  
you don't have a projection defined in grass. If you have a  
cartesian projection defined in grass, you can get lat/lon on the  
fly (e.g. using pj_do_proj() or any other method). So if you are  
able to read the lat/lon values for every cell by other method then  
you can disable this call.


Jaro



I don't know the answer to this. But if no-one else does either,  
r.sun
should be disabled. An error is preferable to silently producing  
wrong

answers.


For sure. I have added the authors in bcc who may have suggestions.


Using different mechanisms for projection in different places looks
really suspicious. If there's a good reason for doing so, it  
should be
clearly documented. If there isn't a good reason, it should be  
fixed.

If no-one knows whether it's right or wrong, the module should be
disabled until we do know.


The first thing to do may be contacting the authors... done with  
this email.


Markus



___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] r.sun and pj_do_proj() calls

[Seth Price]

I'm working on translating r.sun to OpenCL to run on the GPU, but I've  
hit a bit of a snag. I'm hoping y'all can help or at least tell me  
what I'm looking at.


The root of it is that I can't call pj_do_proj() from within the  
OpenCL kernel, so I need to pass that in from the outside. For  
example, on line 1824 of main.c in the current SVN has us calculating  
the lat/long if we aren't passed in files latin and longin. So for the  
OpenCL version I'll need to make latin and longin arrays ahead of time  
instead of calculating it in the loop.


The problem is in rsunlib.c at line 250. How can I avoid this  
pj_do_proj() call? I was thinking that because I have the lat/long  
coordinates for all points, I can use that on lines 255 & 256,  
effectively changing G_projection() to return PROJECTION_LL and  
avoiding going into the 'if' statement. I don't know if that will  
work, though. I really don't know what's going on here enough to feel  
comfortable changing the calculation.


Suggestions? Code?
~Seth
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Modules for GPU-based upgrade?

[Seth Price]

PS: There is a good discussion of double precision in the first few  
minutes of this podcast:

http://www.macresearch.org/opencl_episode3

Which also references this PDF:
http://www.nvidia.com/content/nvision2008/tech_presentations/NVIDIA_Research_Summit/NVISION08-Mixed_Precision_Methods_on_GPUs.pdf

~Seth


On Apr 2, 2010, at 2:03 PM, Dylan Beaudette wrote:


On Friday 02 April 2010, Seth Price wrote:

I'm a student interested in a Summer of Code project to improve some
modules with GPU-based code. In theory, this could result in a 50x
speedup for embarrassingly parallel operations (ie. raster). There is
a list of some possible modules for upgrade here:
http://grass.osgeo.org/wiki/GPU

What would the GRASS community think of also including these modules
as options for improvement? Do they need a speedup? Am I missing
anything?

- r.resamp.interp (spline & Lanczos would be added)
- r.slop.aspect
- r.texture
- i.sunhours
- i.vi

These also work out well for my thesis work (land cover
classification), which gives me extra motivation. ;)
~Seth


Hi,

I think that it sounds like a great idea. Have any ideas on how to  
keep double

precision when working with the GPU?

Cheers,
Dylan


--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Modules for GPU-based upgrade?

[Seth Price]

If it's a slow module already, there's a good chance it won't be I/O  
bound. Things like bilinear resampling are I/O bound, and wouldn't be  
touched. However, cubic and Lanczos  interpolation are not I/O bound  
and will greatly sped up by way of a GPU.


I think that anything that's noticeably slower than other modules  
shouldn't be I/O bound until we have it running on the GPU. (The GPU  
is often such a compute beast that almost everything becomes  
bottlenecked by the PCI bus, but it's hard to say ahead of time.)

~Seth


On Apr 2, 2010, at 5:45 PM, Glynn Clements wrote:



Seth Price wrote:


I'm a student interested in a Summer of Code project to improve some
modules with GPU-based code. In theory, this could result in a 50x
speedup for embarrassingly parallel operations (ie. raster).


Whereas in practice, I/O will be the bottleneck.


There is
a list of some possible modules for upgrade here:
http://grass.osgeo.org/wiki/GPU

What would the GRASS community think of also including these modules
as options for improvement? Do they need a speedup? Am I missing
anything?

- r.resamp.interp (spline & Lanczos would be added)
- r.slop.aspect
- r.texture
- i.sunhours
- i.vi


r.resamp.stats, r.resamp.filter and r.series should also be readily
parallelisable, but again I/O is likely to be the bottleneck. r.series
has the advantage that the I/O is also parallelisable.

--
Glynn Clements 


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Modules for GPU-based upgrade?

[Seth Price]

I know that double precision is supported on newer cards and CUDA, but  
the limitation may be OpenCL. I'm not sure how to best make that work  
besides making GPU acceleration optional and/or using macros to let  
the user more easily choose. In the future there will probably be  
better support in OpenCL, which lends support for macros.


~Seth


via iPhone

On Apr 2, 2010, at 2:03 PM, Dylan Beaudette   
wrote:



On Friday 02 April 2010, Seth Price wrote:

I'm a student interested in a Summer of Code project to improve some
modules with GPU-based code. In theory, this could result in a 50x
speedup for embarrassingly parallel operations (ie. raster). There is
a list of some possible modules for upgrade here:
http://grass.osgeo.org/wiki/GPU

What would the GRASS community think of also including these modules
as options for improvement? Do they need a speedup? Am I missing
anything?

- r.resamp.interp (spline & Lanczos would be added)
- r.slop.aspect
- r.texture
- i.sunhours
- i.vi

These also work out well for my thesis work (land cover
classification), which gives me extra motivation. ;)
~Seth


Hi,

I think that it sounds like a great idea. Have any ideas on how to  
keep double

precision when working with the GPU?

Cheers,
Dylan


--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Modules for GPU-based upgrade?

[Seth Price]

I'm a student interested in a Summer of Code project to improve some  
modules with GPU-based code. In theory, this could result in a 50x  
speedup for embarrassingly parallel operations (ie. raster). There is  
a list of some possible modules for upgrade here:

http://grass.osgeo.org/wiki/GPU

What would the GRASS community think of also including these modules  
as options for improvement? Do they need a speedup? Am I missing  
anything?


- r.resamp.interp (spline & Lanczos would be added)
- r.slop.aspect
- r.texture
- i.sunhours
- i.vi

These also work out well for my thesis work (land cover  
classification), which gives me extra motivation. ;)

~Seth
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev