[GRASS-dev] Adding an expert mode to the parser

[Sören Gebbert]

[snip]

> >r.mapclac --raster-region= --north= --south= --west= --east= --res=
> >--ewres= --nsres= --vect-region --raster-align= ...
>
> Can't you do this at a higher level, i.e using the GRASS Python API's
> use_temp_region ?
>

This is exactly what i'm doing right now[1,2], covering a single module
call in several g.region and g.remove calls in a dedicated subprocess.
Huge, massive unnecessary overhead.

[1]
https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/modules/interface/module.py#L791
[2]
https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/modules/interface/module.py#L951


> Moritz
>
>
> >
> >Just my 2 cent
> >Sören
> >
> >2016-09-25 20:49 GMT+01:00 Markus Neteler <neteler at osgeo.org>:
> >
> >> On Fri, Sep 23, 2016 at 11:30 PM, Markus Metz
> >> <markus.metz.giswork at gmail.com> wrote:
> >> > On Fri, Sep 23, 2016 at 11:22 PM, Markus Neteler
> ><neteler at osgeo.org>
> >> wrote:
> >> >> On Fri, Sep 23, 2016 at 11:05 PM, Markus Metz
> >> >> <markus.metz.giswork at gmail.com> wrote:
> >> >>> On Fri, Sep 23, 2016 at 1:11 PM, Markus Neteler
> ><neteler at osgeo.org>
> >> wrote:
> >> >> ...
> >> >>> Your motivation is to provide a specialized CLI interface for HPC
> >> >>> processing?
> >> >>
> >> >> No, not the case.
> >> >>
> >> >>> We used GRASS with HPC processing for years and the
> >> >>> problems we faced were causes by the HPC hardware and software
> >> >>> infrastructure, not by GRASS. What exactly is the problem with
> >using
> >> >>> GRASS and HPC processing?
> >> >>
> >> >> There is no problem. There is just the issue that with an
> >increasing
> >> >> amount of additions (e.g. maybe the need to provide
> >region/resolution
> >> >> to individual modules for independent parallel processing without
> >the
> >> >> overhead of always opening a new mapset)
> >> >
> >> > Getting closer it seems. Can you quantify "the overhead of always
> >> > opening a new mapset"?
> >>
> >> As an example, when aiming at processing all Sentinel-2 tiles
> >> globally, we speak about currently 73000 scenes * up-to-16 tiles
> >along
> >> with global data, analysis on top of other global data is more
> >complex
> >> when doing each job in its own mapset and reintegrate it in a single
> >> target mapset as if able to process then in parallel in one mapset by
> >> simply specifying the respective region to the command of interest.
> >> Yes, different from the current paradigm and not for G7.
> >>
> >> But my original comment was targeted at the increasing number of
> >> module parameters and how to handle that (with some new HPC related
> >> idea as an example).
> >>
> >> I'm fine to archive this question for now, it will likely come up
> >> again in the future.
> >>
> >> markusN
> >> _______________________________________________
> >> grass-dev mailing list
> >> grass-dev at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/grass-dev
> >>
> >
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >grass-dev mailing list
> >grass-dev at lists.osgeo.org
> >http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20160925/ddadfcdc/attachment.html>