[GRASS-dev] [GRASS GIS] #2764: corrupt data written to FCELL and DCELL rasters, hard to re-produce

[GRASS GIS]

#2764: corrupt data written to FCELL and DCELL rasters, hard to re-produce
---------------------+-------------------------
  Reporter:  dylan   |      Owner:  grass-dev@…
      Type:  defect  |     Status:  new
  Priority:  normal  |  Milestone:  7.2.3
 Component:  Raster  |    Version:  unspecified
Resolution:          |   Keywords:
       CPU:  x86-64  |   Platform:  Linux
---------------------+-------------------------

Comment (by mmetz):

 Replying to [comment:27 dylan]:
 > Replying to [comment:26 mmetz]:
 > >[...]
 > > That means r.sun has created corrupt output. BTW, considering that you
 are running several instances of r.sun in parallel, I wonder if you
 compiled GRASS with openmp and use the nprocs option of r.sun. In this
 case you would have several instances of r.sun and each instance of r.sun
 would be multi-threaded: no speed gain, more sources of potential errors.
 >
 > Note that this sometimes happens in the follow-up step where there
 output from `r.sun` is converted to MJ/sq.m by `r.mapcalc`: "beam.106"
 (`r.mapcalc`) vs. "temp_beam_106" (`r.sun`).

 This is a very simple r.mapcalc expression. You should be able to trigger
 the error by simply creating a number of maps in parallel with r.mapcalc,
 after that (serially) testing the outputs with r.univar. With r.mapcalc in
 daily-rad.sh, you are running several independent instances of r.mapcalc
 in parallel. With daily-rad.sh called by beam-rad-at-tile.sh you are not
 testing if GRASS is thread-safe, instead you are testing if your OS,
 filesystem and hard drive can handle multiple simultaneous IO requests.
 Please check your system messages and the health of your hard drives (e.g.
 with smartctl) first, before you proceed.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2764#comment:28>
GRASS GIS <https://grass.osgeo.org>