Comments on scripts, modeling and Grass

[Conn Copas]

Agustin Lobo <alobo at ija.csic.es> writes:

> It is clear that almost ANY scripting language (even the c-shell) 
> can be used for a simple flow of grass commands: most of us use this method
> every day. The problem is when, within the model, you must
> ANALYSE the result of a grass command and the subsequent
> actions depend upon the result of this analysis.

Agreed. The question that needs to be asked is whether modelling has some 
features which differentiate it from programming in general. If so, a reasonable
strategy is to attempt to identify those features and then make available some 
higher-level abstractions in a specialised language. The only example I can 
think of off the top of my head is discrete event simulation languages. However, 
not all modelling involves simulation.

> >Alternatively, R has a batch mode that can be called from the shell. You
> >could actually build an R script programmatically from another app once
> >the data files have been created, then launch R to do batch processing 
> by running the script.
> 
> Yes, as with Splus and, probably, Matlab. The problem, as I said, is
> that the communication between R and Grass would be through writing
> and reading files: this is slow (remember a model can have thousands
> of iterations) and uses more disk space (which is becoming a minor
> problem, though).

Although not familiar with R, the question has to be asked whether it is capable 
of reading from and writing to the terminal (which, as far as Unix is concerned, 
is just a set of files). If so, then it is possible in principle to redirect I/O 
to other processes, including Grass commands. Maybe even set up a socket (which, 
physically, is just another file).

Roy Sanderson <R.A.Sanderson at newcastle.ac.uk> writes:

> I don't know whether this is relevant to this disucssion, but as I recall,
> when the first PC version of Grass was launched by LAS about 5 years ago,
> it contained some sort of Grass 'Visual Toolbox', allowing you to link
> various Grass routines together directly through the GUI.  The publicity
> gave the impression that this would be similar to linking modelling
> components together in a program such as ModelMaker.  I've not tried
> Grassland, so I can't say how good this approach is, but has anyone tried
> to use this feature regularly, and would an extension of that approach
> provide both power and simplicity for the non-programmer that many comments
> suggest?

As I recall, Khoros was one of the first systems to provide that graphical 
piping notion. My experience is that most of these systems provide a fairly 
limited graphical programming capability because of the difficulty of doing 
things like looping and conditionals in graphics. The simplicity for the 
non-programmer is still an attractive feature, however.

--
Conn V Copas
Information Technology Division
Defence Science and Technology Organisation
PO Box 1500
Salisbury            tel: +61 (0)8 825 95349
SA  5108             fax: +61 (0)8 825 95589
Australia       e-mail: Conn.Copas at dsto.defence.gov.au
------------------------------------------------------