Hamish:
> > I am looking to add OpenMP support to v.surf.bspline
...
Sören wrote:
> Try r49406.
> You need to separate the computation for j == 0 and j > 0.
nice, thanks.
> > b) 3.5x speedup is very nice, but any way to improve
> > on that 40% efficiency loss?
>
> The speedup is better as larg
#1500: g.region returns wrong convergence angle
--+-
Reporter: annakrat | Owner: grass-dev@…
Type: defect| Status: new
Priority: normal
#1499: v.surf.rst in trunk doesn't write the output map
+---
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milest
#1499: v.surf.rst in trunk doesn't create write the output map
+---
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: major |
On Mon, 28 Nov 2011, Martin Landa wrote:
Hi,
2011/11/28 Roger Bivand :
import wxnviz
# disable wxNviz for 6.4.2
# TODO: backport wxNviz from devbr6 *after* releasing 6.4.2
haveNviz = False
hopefully fixed in r49409. Martin
Confirmed, thanks! Roger
PS. I also needed NumPy inst
#1498: patch proposal: new option for v.category to copy category values from
one
layer to another
-+--
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Roger wrote:
> Where should I look to see which files were
> changed by r49360 on the server, so that I can
> compare with the ones I checked out?
the long way:
-
go to https://trac.osgeo.org/grass/browser/
or https://trac.osgeo.org/grass/ and click on the
"browse source" button on
Hi,
2011/11/28 Roger Bivand :
> import wxnviz
> # disable wxNviz for 6.4.2
> # TODO: backport wxNviz from devbr6 *after* releasing 6.4.2
> haveNviz = False
>
hopefully fixed in r49409. Martin
--
Martin Landa * http://geo.fsv.cvut.cz/~landa
__
#1498: patch proposal: new option for v.category to copy category values from
one
layer to another
-+--
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
On Mon, 28 Nov 2011, Roger Bivand wrote:
On Mon, 28 Nov 2011, Markus Metz wrote:
Roger Bivand wrote:
Hi,
I first tried 6.4.2 RC2, now also checked out SVN 49406, with the same
result. With fresh Fedora 16, building from source (with 6.4.1 the proj
arguments were never needed), there is troub
#1498: patch proposal: new option for v.category to copy category values from
one
layer to another
-+--
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
On 28/11/11 11:28, Moritz Lennert wrote:
I agree that it would be helpful to have an opion in v.category to copy
the values from one layer to another (i.e. something like option=copy
layer=2 sourcelayer=1).
I just filed an enhancement request with a proposed patch implementing
this (http://tra
#1498: patch proposal: new option for v.category to copy category values from
one
layer to another
-+--
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
On Mon, 28 Nov 2011, Markus Metz wrote:
Roger Bivand wrote:
Hi,
I first tried 6.4.2 RC2, now also checked out SVN 49406, with the same
result. With fresh Fedora 16, building from source (with 6.4.1 the proj
arguments were never needed), there is trouble loading the GUI:
wxNviz has been disab
Roger Bivand wrote:
> Hi,
>
> I first tried 6.4.2 RC2, now also checked out SVN 49406, with the same
> result. With fresh Fedora 16, building from source (with 6.4.1 the proj
> arguments were never needed), there is trouble loading the GUI:
wxNviz has been disabled only 3 days ago in 6.4, latest s
Hi,
I first tried 6.4.2 RC2, now also checked out SVN 49406, with the same
result. With fresh Fedora 16, building from source (with 6.4.1 the proj
arguments were never needed), there is trouble loading the GUI:
$ ./configure --prefix=/home/rsb/topics/GRASS/G642RC2 --with-wxwidgets
--with-pro
Hi Hamish,
2011/11/28 Hamish :
> Hi,
>
> On June 2, 2011, Soeren wrote:
>> Have a look at:
>> http://grass.osgeo.org/wiki/OpenMP
>>
>> There are only a few modules using OpenMP (r.gwflow, r3.gwflow and
>> r.solute.transport). Parts of the gpde and gmath libraries in grass
>> 6.5 and 7 are parallel
On Sun, Nov 27, 2011 at 4:57 AM, Andy Wickert wrote:
> > There can be a significant performance hit for doing this. Checking
> > whether the result of an addition overflowed is actually more
> > expensive than the addition itself. Checking whether a multiplication
> > overflowed can be even worse
18 matches
Mail list logo
