<div dir="ltr"><div>Hi,</div>Here an example of hidden region settings for modules utilized in the temporal framework:<div><br></div><div>Imagine you have a Landsat location that contains many thousand scenes (time series) from all over the world including all bands. Each band of the time series is managed in a specific space-time dataset. You may want to use the temporal raster algebra to compute the NDVI in parallel on all scenes at once. This is not possible at the moment, because of the current region settings. Except you can set the current region to cover the whole world, which is not preferable.</div><div><br></div><div>So the idea is to have options that will set the computational region for each process independently, when the process is invoked. Hence the raster computational window is set in the parser, so that the usual region get methods in the modules will work untouched. This avoids the current approach that is covering a single module call (like r.mapclalc, r.series, r.neighbors, ... ) in several g.region and g.remove calls in a dedicated subprocess.</div><div><br></div><div>This option is only useful for parallel processing of raster layers with different spatial extents. A special feature for the temporal framework, that should not be exposed to all the users, only to those who implement massive parallel working temporal modules. Hence using the same approach as for WPS, GUI and HTML output:</div><div><br></div><div>r.mapclac --raster-region= --north= --south= --west= --east= --res= --ewres= --nsres= --vect-region --raster-align= ...</div><div><br></div><div>Just my 2 cent</div><div>Sören</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-09-25 20:49 GMT+01:00 Markus Neteler <span dir="ltr"><<a href="mailto:neteler@osgeo.org" target="_blank">neteler@osgeo.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Sep 23, 2016 at 11:30 PM, Markus Metz<br>
<span class=""><<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a><wbr>> wrote:<br>
> On Fri, Sep 23, 2016 at 11:22 PM, Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>> wrote:<br>
>> On Fri, Sep 23, 2016 at 11:05 PM, Markus Metz<br>
>> <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a><wbr>> wrote:<br>
>>> On Fri, Sep 23, 2016 at 1:11 PM, Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>> wrote:<br>
>> ...<br>
>>> Your motivation is to provide a specialized CLI interface for HPC<br>
>>> processing?<br>
>><br>
>> No, not the case.<br>
>><br>
>>> We used GRASS with HPC processing for years and the<br>
>>> problems we faced were causes by the HPC hardware and software<br>
>>> infrastructure, not by GRASS. What exactly is the problem with using<br>
>>> GRASS and HPC processing?<br>
>><br>
>> There is no problem. There is just the issue that with an increasing<br>
>> amount of additions (e.g. maybe the need to provide region/resolution<br>
>> to individual modules for independent parallel processing without the<br>
>> overhead of always opening a new mapset)<br>
><br>
> Getting closer it seems. Can you quantify "the overhead of always<br>
> opening a new mapset"?<br>
<br>
</span>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>
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>
<div class="HOEnZb"><div class="h5">______________________________<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>