Your remarks Māris are very interesting. I am actually having trouble
with my CPU (AMD Ryzen 7 3800X) and debian stable: I should try to test
several debian backports to have the full temperature sensors support
(not yet supported with 4.19) but am not especially at ease with these
quite dodgy
Vincent,
On Thu, Oct 15, 2020 at 6:39 PM Vincent Bain wrote:
>
> Markus, Māris, and others who feel concerned,
>
> following on with this post, I am wondering if either something is
> wrong with my openMP install (then it's not the place to bother anyone
> with it) or if there may be something
Valgrind leak check is needed only for developers as it tracks memory
consumption not its errors (although in this case it allowed to notice
OpenMP presence by shear luck). As your valgrind run is clean, this is
a dead end.
On my system I also have a OpenMP and pthreads configuration.
Markus, Māris, and others who feel concerned,
following on with this post, I am wondering if either something is
wrong with my openMP install (then it's not the place to bother anyone
with it) or if there may be something wrong with r.param.scale, and
possibly more generally with the way GRASS
Recompiled without openmp:
md5sum Bureau/slope_test.*
1231556eb6c1307834d3eb0c41108982 Bureau/slope_test.1
1231556eb6c1307834d3eb0c41108982 Bureau/slope_test.10
1231556eb6c1307834d3eb0c41108982 Bureau/slope_test.11
1231556eb6c1307834d3eb0c41108982 Bureau/slope_test.12
On Thu, Oct 15, 2020 at 10:58 AM Vincent Bain wrote:
>
> Markus,
> my configuration cmd :
>
> ./configure
...
> --with-openmp=yes
...
> --with-openmp
You may drop "openmp" and recompile (after "make distclean"). Just to
exclude that openMP causes the trouble.
Markus
Markus,
my configuration cmd :
./configure
--with-freetype
--with-freetype-includes=/usr/include/freetype2
--with-postgres
--with-postgres-includes=/usr/include/postgresql/
--with-postgres-libs=/usr/lib/postgresql
--with-readline
--with-geos
--with-liblas=yes
--with-cairo
Markus,
my configuration cmd :
./configure
--with-freetype
--with-freetype-includes=/usr/include/freetype2
--with-postgres
--with-postgres-includes=/usr/include/postgresql/
--with-postgres-libs=/usr/lib/postgresql
--with-readline
--with-geos
--with-liblas=yes
--with-cairo
Hi Vincent,
On Thu, Oct 15, 2020 at 10:13 AM Vincent Bain wrote:
>
> Thanks Māris for your advice,
>
> it sounds dreadful to me to have to deal with these hardware issues...
> I installed valgrind and ran r.param.scale.
>
> Attached are the outputs of the command, first run without any
>
Thanks Māris for your advice,
it sounds dreadful to me to have to deal with these hardware issues...
I installed valgrind and ran r.param.scale.
Attached are the outputs of the command, first run without any
argument, then with --leak-check=full option. Of course it's nearly
"doubledutch" to me!
Hello Vincent,
start with running stress tests on your hardware. I always run at
least 24h memtest followed by several rounds of compiling kernel on
any new hardware. Allowed to catch a misbehaving motherboard of laptop
before I started to use it for my daily needs.
You could try to run process
Hi Markus,
thank you for your reply and investigation!
just in case, if I follow your first method, here's what it gives me on
a 12 steps loop, i.e. 40% success :
md5sum Bureau/slope_test.*
0bfb867317c149e9eb0b232ed6859294 Bureau/slope_test.1
872be645bdcc826442010e0f7cdcf8b3
Hi Vincent
On Sun, Oct 11, 2020 at 8:08 PM Vincent Bain wrote:
>
> Dear Grass users,
> has anyone ever experienced such issue with r.param.scale?
>
> Here's the point:
> I use to invoke r.param.scale instead of r.slope.aspect to calculate
> topographical slopes in various situations. I
Dear Grass users,
has anyone ever experienced such issue with r.param.scale?
Here's the point:
I use to invoke r.param.scale instead of r.slope.aspect to calculate
topographical slopes in various situations. I especially appreciate to
have a hand on the size of processing window. I rencently had
14 matches
Mail list logo
