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

[Markus Neteler]

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) to the user interface it
becomes harder to understand for most users.

> You could ask on the GRASS user ML, or a
> GRASS developer who has experience with HPC processing.

I have 10+ years of experience in GRASS HPC :-) So that's fine.

>>>> How do we make sure people understand the options were not
>>>> removed, but are just hidden?
>>
>> For those being on command line, we could either show the advanced options,
>> or, if not show instead a hint that this particular command also offers
>> advanced options.
>
> I assume that most GRASS users regard the command line as advanced
> usage, therefore the CLI should always show all flags and options.

I don't think that all CLI users want to see always 40+ flags and
options per command if it could also be customizable.
Of course there may be different opinions.

...
> You wrote "The flags and parameters for advanced users should be
> hidden by default", and Anna referred to such advanced options.

Simple example, not HPC related:

* r.sun: "npartitions"  - not really relevant for day2day "normal" usage.
* various commands: "Use the low-memory version" - also more advanced
etc.

>> It is not about hiding, as I just tried to explain maybe better now.
>> It is about not adding so many more flags and parameters to the standard
>> interface, or, a way how to address this upcoming problem for the near
>> future.
>
> As you said, your problem is related to HPC processing. Why do you
> think more flags and options are a problem for HPC processing?

No, not a problem for using it.
But maybe not interesting for all users to be always seen when using
GRASS in "shallow mode".

> Particularly for HPC processing, I would assume that the more
> information and the more control you have, the better.

Exactly. Just not all (new) users want to see a huge interface of
which they only use a fraction.
That's why it could be structured better in order to distinguish
between "easy" and "advanced".
Maybe not hide then but at least group the parameters and flags rather
than alpha-order or random mix.

markusN