<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">[snip]<br>
><br>
> As an example, when aiming at processing all Sentinel-2 tiles<br>
> globally, we speak about currently 73000 scenes * up-to-16 tiles along<br>
> with global data, analysis on top of other global data is more complex<br>
> when doing each job in its own mapset and reintegrate it in a single<br>
> target mapset as if able to process then in parallel in one mapset by<br>
> simply specifying the respective region to the command of interest.<br>
> Yes, different from the current paradigm and not for G7.<br>
<br>
</div></div>from our common experience, I would say that creating separate mapsets<br>
is a safety feature. If anything goes wrong with that particular<br>
processing chain, cleaning up is easy, simply delete this particular<br>
mapset and run the job again, if possible on a different host/node<br>
(assuming that failed jobs are logged). Anyway, I would be surprised<br>
if the overhead of opening a separate mapset is measurable when<br>
processing all Sentinel-2 tiles globally. Reintegration into a single<br>
target mapset could cause problems with regard to IO saturation, but<br>
in a HPC environment temporary data always need to be copied to a<br>
final target location at some stage. The HPC system you are using now<br>
is most probably quite different from the one we used previously, so<br>
this is a lot of guessing, particularly about the storage location of<br>
temporary data (no matter if it is the same mapset or a separate<br>
mapset).<br></blockquote><div><br></div><div>Imagine you have a tool that is able to distribute the processing of a large time series of satellite images across a cluster. Each node in the cluster should process a stack of r.mapcalc, r.series or r.neighbors commands in a local temporary mapset, that gets later merged into a single one. A single stack of commands may have hundreds of jobs that will run in a single temporary mapset. In this scenario you need separate region settings for each command in the stack, because of the different spatial extents of the satellite images. The size of the stack depends on the size of the time series (number of maps) and the number of available nodes.</div><div><br></div><div>Having region setting options in the parser will make the implementation of such an approach much easier. Commands like t.rast.algebra and t.rast.neighbors will directly benefit from a region parser option, allowing the parallel processing of satellite image time series on a multi-core machine.</div><div><br></div><div>Best regards</div><div>Soeren</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
To be continued in a GRASS+HPC thread?<br>
<br>
Markus M<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> But my original comment was targeted at the increasing number of<br>
> module parameters and how to handle that (with some new HPC related<br>
> idea as an example).<br>
><br>
> I'm fine to archive this question for now, it will likely come up<br>
> again in the future.<br>
><br>
> markusN<br>
______________________________<wbr>_________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/grass-dev</a></div></div></blockquote></div><br></div></div>