<div dir="ltr">Thanks, <div>I implemented accordingly and seams to work fine. </div><div>Thank you. </div><div>Best </div><div>Giuseppe</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 28 May 2017 at 17:18, Markus Metz <span dir="ltr"><<a href="mailto:markus.metz.giswork@gmail.com" target="_blank">markus.metz.giswork@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span class=""><div><br><br>On Thu, May 25, 2017 at 5:24 PM, Giuseppe Amatulli <<a href="mailto:giuseppe.amatulli@gmail.com" target="_blank">giuseppe.amatulli@gmail.com</a>> wrote:<br>><br>> Hi Markus, <br>> in reality the computation beyond the mask problem is very complex, I will try to summarize. <br>> I have the UNIT3753 mask sit on the PERMANENT and I create 1000 location in a multicore environment (HPC). <br>> Each location use the UNIT3753-mask from the PERMANENT. This action produce that the  cell_misc/UNIT3753/reclassed_<wbr>to is written simultaneously from different cores. <br><br></div></span>This is the problem. If several processes try to edit the same file at once, this can cause data corruption. The reclassed_to file holds the names of the reclassed raster maps based on that raster map. Instead of r.mask, you can use r.mapcalc to create specific MASKs for each process on each compute node. This should avoid these problems, as long as each process on each compute node uses its own unique mapset.<br></div><div><br></div>Markus M (running GRASS on an HPC system every day)<div><div><div><div class="h5"><br>> I think that this action creates a  reclassed_to file very large and probably also with different permission which was not be able to be removed. <br>><br>> I solved by manually  remove the reclassed_to file, so now the process is running smoothly. <br>><br>> A potential solution would be:<br>> 1) for each location  g.copy raster=PERMANENT,UNIT3753 , and than apply the r.mask using the UNIT3753 in the location and not in the PERMANENT.<br>> This would work but data duplication will be there.<br>> 2) a second solution would be if  the reclassed_to can have a unique name (e.g. reclassed_to$$) associate to the location. <br>><br>> Any thought? <br>> Thank you<br>> Best Regards<br>> Giuseppe<br>> p.s. in few weeks I will be in Berlin so we may chat in person. <br>>  <br>>  <br>><br>><br>><br>><br>> On 24 May 2017 at 18:29, Markus Neteler <<a href="mailto:neteler@osgeo.org" target="_blank">neteler@osgeo.org</a>> wrote:<br>>><br>>> On Wed, May 24, 2017 at 11:40 PM, Giuseppe Amatulli<br>>> <<a href="mailto:giuseppe.amatulli@gmail.com" target="_blank">giuseppe.amatulli@gmail.com</a>> wrote:<br>>> > Hi Nikos<br>>> > I just sort out.<br>>> > the file /PERMANENT/cell_misc/UNIT3753/<wbr>reclassed_to was very big (2.5g) and<br>>> > it  was not be able to be removed with the r.remove.<br>>><br>>> That size is not an issue at all (the EU DEM is 25GB or more for<br>>> example)... the problem must be elsewhere. Happy to help if possible.<br>>> BTW: I have compiled GRASS 7.2 also for RHEL via EPEL, see the download page.<br>>><br>>> Markus<br>>><br>>><br>>> --<br>>> Markus Neteler, PhD<br>>> <a href="http://www.mundialis.de" target="_blank">http://www.mundialis.de</a> - free data with free software<br>>> <a href="http://grass.osgeo.org" target="_blank">http://grass.osgeo.org</a><br>>> <a href="http://courses.neteler.org/blog" target="_blank">http://courses.neteler.org/<wbr>blog</a><br>><br>><br>><br>><br>> --<br>> Giuseppe Amatulli, Ph.D.<br>><br>> Research scientist at<br>> Yale School of Forestry & Environmental Studies<br>> Yale Center for Research Computing<br>> Center for Science and Social Science Information<br>> New Haven, 06511<br>> Teaching: <a href="http://spatial-ecology.org" target="_blank">http://spatial-ecology.org</a><br>> Work:  <a href="https://environment.yale.edu/profile/giuseppe-amatulli/" target="_blank">https://environment.yale.edu/<wbr>profile/giuseppe-amatulli/</a><br>><br></div></div>> ______________________________<wbr>_________________<br>> grass-user mailing list<br>> <a href="mailto:grass-user@lists.osgeo.org" target="_blank">grass-user@lists.osgeo.org</a><br>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-user" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/grass-user</a><br><br></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Giuseppe Amatulli, Ph.D.<br><br>Research scientist at<br><span>Yale School of Forestry & Environmental Studies<br></span><span>Yale Center for Research Computing<br></span>Center for Science and Social Science Information<br>New Haven, 06511<br><div>
   Teaching: <a href="http://spatial-ecology.org" target="_blank">http://spatial-ecology.org</a>
  </div> 
  
   Work:  <a href="https://environment.yale.edu/profile/giuseppe-amatulli/" target="_blank">https://environment.yale.edu/profile/giuseppe-amatulli/</a> <br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>