<div dir="ltr"><div>Hi Markus, </div><div>in reality the computation beyond the mask problem is very complex, I will try to summarize. </div><div>I have the UNIT3753 mask sit on the PERMANENT and I create 1000 location in a multicore environment (HPC). </div><div>Each location use the UNIT3753-mask from the PERMANENT. This action produce that the  cell_misc/UNIT3753/reclassed_to is written simultaneously from different cores. </div><div>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. </div><div><br></div><div>I solved by manually  remove the reclassed_to file, so now the process is running smoothly. </div><div><br></div><div>A potential solution would be:</div><div>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.</div><div>This would work but data duplication will be there.</div><div>2) a second solution would be if  the reclassed_to can have a unique name (e.g. <font color="#000000"><span style="font-size:12.8px">r</span></font>eclassed_to$$) associate to the location. </div><div><br></div><div>Any thought? </div><div>Thank you</div><div>Best Regards</div><div>Giuseppe</div><div>p.s. in few weeks I will be in Berlin so we may chat in person. </div><div> </div><div> </div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 May 2017 at 18:29, Markus Neteler <span dir="ltr"><<a href="mailto:neteler@osgeo.org" target="_blank">neteler@osgeo.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, May 24, 2017 at 11:40 PM, Giuseppe Amatulli<br>
<<a href="mailto:giuseppe.amatulli@gmail.com">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>
</span>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>
<span class="HOEnZb"><font color="#888888"><br>
Markus<br>
<br>
<br>
--<br>
Markus Neteler, PhD<br>
<a href="http://www.mundialis.de" rel="noreferrer" target="_blank">http://www.mundialis.de</a> - free data with free software<br>
<a href="http://grass.osgeo.org" rel="noreferrer" target="_blank">http://grass.osgeo.org</a><br>
<a href="http://courses.neteler.org/blog" rel="noreferrer" target="_blank">http://courses.neteler.org/<wbr>blog</a><br>
</font></span></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>