[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 <nete...@osgeo.org>: > > > >> On Fri, Sep 23, 2016 at 11:30 PM, Markus Metz > >> <markus.metz.gisw...@gmail.com> wrote: > >> > On Fri, Sep 23, 2016 at 11:22 PM, Markus Neteler > ><nete...@osgeo.org> > >> wrote: > >> >> On Fri, Sep 23, 2016 at 11:05 PM, Markus Metz > >> >> <markus.metz.gisw...@gmail.com> wrote: > >> >>> On Fri, Sep 23, 2016 at 1:11 PM, Markus Neteler > ><nete...@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@lists.osgeo.org > >> http://lists.osgeo.org/mailman/listinfo/grass-dev > >> > > > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >grass-dev mailing list > >grass-dev@lists.osgeo.org > >http://lists.osgeo.org/mailman/listinfo/grass-dev > >
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev