
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<html><head><meta content="text/html; charset=utf-8" http-equiv="Content-Type"></head><br><br><div style='font-size:10.0pt;font-family:"Tahoma","sans-serif";padding:3.0pt 0in 0in 0in'>

<hr style='border:none;border-top:solid #E1E1E1 1.0pt'>

<b>De :</b> Moritz Lennert <moritzlennert@posteo.net><br>

<b>Envoyé :</b> 25 septembre 2016 23:21:04 GMT+02:00<br>

<b>À :</b> "Sören Gebbert" <soerengebbert@googlemail.com>, Markus Neteler <neteler@osgeo.org><br>

<b>Cc :</b> GRASS developers list <grass-dev@lists.osgeo.org>, Markus Metz <markus.metz.giswork@gmail.com><br>

<b>Objet :</b> Re: [GRASS-dev] Adding an expert mode to the parser<br>

</div>

<br>

<pre class="k9mail"><br /><br />Le 25 septembre 2016 22:29:19 GMT+02:00, "Sören Gebbert" <soerengebbert@googlemail.com> a écrit :<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Hi,<br />Here an example of hidden region settings for modules utilized in the<br />temporal framework:<br /><br />Imagine you have a Landsat location that contains many thousand scenes<br />(time series) from all over the world including all bands. Each band of<br />the<br />time series is managed in a specific space-time dataset. You may want<br />to<br />use the temporal raster algebra to compute the NDVI in parallel on all<br />scenes at once. This is not possible at the moment, because of the<br />current<br />region settings. Except you can set the current region to cover the<br />whole<br />world, which is not preferable.<br /><br />So the idea is to have options that will set the computational region<br />for<br />each

process independently, when the process is invoked. Hence the<br />raster<br />computational window is set in the parser, so that the usual region get<br />methods in the modules will work untouched. This avoids the current<br />approach that is covering a single module call (like r.mapclalc,<br />r.series,<br />r.neighbors, ... ) in several g.region and g.remove calls in a<br />dedicated<br />subprocess.<br /><br />This option is only useful for parallel processing of raster layers<br />with<br />different spatial extents. A special feature for the temporal<br />framework,<br />that should not be exposed to all the users, only to those who<br />implement<br />massive parallel working temporal modules. Hence using the same<br />approach as<br />for WPS, GUI and HTML output:<br /><br />r.mapclac --raster-region= --north= --south= --west= --east= --res=<br />--ewres= --nsres= --vect-region --raster-align= ...<br /></blockquote><br />Can't you do this at a higher level, i.e using the

GRASS Python API's use_temp_region ?<br /><br />Moritz<br /><br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><br />Just my 2 cent<br />Sören<br /><br />2016-09-25 20:49 GMT+01:00 Markus Neteler <neteler@osgeo.org>:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> On Fri, Sep 23, 2016 at 11:30 PM, Markus Metz<br /> <markus.metz.giswork@gmail.com> wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> On Fri, Sep 23, 2016 at 11:22 PM, Markus Neteler<br /></blockquote></blockquote><neteler@osgeo.org><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234;

padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> On Fri, Sep 23, 2016 at 11:05 PM, Markus Metz<br /> <markus.metz.giswork@gmail.com> wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #e9b96e; padding-left: 1ex;"> On Fri, Sep 23, 2016 at 1:11 PM, Markus Neteler<br /></blockquote></blockquote></blockquote></blockquote><neteler@osgeo.org><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> ...<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #e9b96e; padding-left: 1ex;"> Your

motivation is to provide a specialized CLI interface for HPC<br /> processing?<br /></blockquote><br /> No, not the case.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #e9b96e; padding-left: 1ex;"> 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<br /></blockquote></blockquote></blockquote></blockquote>using<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #e9b96e; padding-left: 1ex;"> GRASS and HPC

processing?<br /></blockquote><br /> There is no problem. There is just the issue that with an<br /></blockquote></blockquote></blockquote>increasing<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> amount of additions (e.g. maybe the need to provide<br /></blockquote></blockquote></blockquote>region/resolution<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> to individual

modules for independent parallel processing without<br /></blockquote></blockquote></blockquote>the<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> overhead of always opening a new mapset)<br /></blockquote><br /> Getting closer it seems. Can you quantify "the overhead of always<br /> opening a new mapset"?<br /></blockquote><br /> As an example, when aiming at processing all Sentinel-2 tiles<br /> globally, we speak about currently 73000 scenes * up-to-16 tiles<br /></blockquote>along<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> with global data, analysis on top of other global data is more<br

/></blockquote>complex<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> 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 /><hr /><br /> grass-dev mailing list<br /> grass-dev@lists.osgeo.org<br /> <a href="http://lists.osgeo.org/mailman/listinfo/grass-dev">http://lists.osgeo.org/mailman/listinfo/grass-dev</a></blockquote><br /><br /><br /><hr /><br /><br /><hr /><br />grass-dev

mailing list<br />grass-dev@lists.osgeo.org<br /><a href="http://lists.osgeo.org/mailman/listinfo/grass-dev">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br /></blockquote><br /></pre></html>