Comments on scripts, modeling and Grass

Agustin Lobo alobo at ija.csic.es
Wed Oct 27 06:55:26 EDT 1999



I comment here on the several reactions to my message 
"Re: Forestry and Grass + scripts for models"

Issue 1: Are "classic" programming languages (i.e., FORTRAN, c, c++...)
adequate for GIS modeling?

 Rich Shepard <rshepard at appl-ecosys.com>

>"  It was only when I moved to microcomputers and C (in the mid-1980's) that
>I learned the value of commenting code. Scientists aren't taught this;
>programmers are.

>  My code now is at least 50% comments; often much more. I explain why I did
>something a certain way or what I was trying to accomplish. The effort is
>repaid manyfold when I look at old code years later. :-)"

Well, this demonstrates that C is not a good language for modeling, as 
you have
to repeat each line in a different language. Would English be an adequate 
language for this
message if I had to repeat every paragraph in a different language because
virtually nobody (even not myself!) could understand what I'm saying? 
(OK, 
sometimes my English can be so obscure that this problem could actually 
be real!).

Note that I'm talking about modeling. I understand that, in other 
applications,
FORTRAN, C, C++,..., can be the best alternative. But, in modeling, often you
cannot evaluate the program just by the result. If you write a program to
display an image, you can easily detect an error in the code because
the display would be wrong. Or if you write a program to calculate
an FFT you can use a simple input and compare the result to your own 
computation
or to the result produced by another FFT program: the result is predictable.
Instead, in modeling, the result is not predictable (yet): that's why
you make the model. Also, you can have a CORRECT result out of a WRONG model:
the result must be produced by processes that are physically, biologically,
ecologically... consistent, and this should be assessed by other scientists
being able to read the code. Which implies a simple syntax with, ideally,
one action per line.



 Bernhard Reiter <bernhard at uwm.edu> has a different opinion:

>This is pretty much a question of style. Good C programs a very readable.
>(C++ is more difficult.) 

I think that this could be true for very skilled C "writers" and "readers"
conforming to the same style (and not only to the same language!). I would
argue that the time devoted to the programming itself would be of the same
order of magnitude that the time devoted to think on the processes to be
modeled. Take the example of writing this message: I can concentrate
on the idea that I want to communicate and spend a minimum time on the
language itself (I know, most of you would prefer that I spend more
time on improving my language..., but you get the idea)


Issue 2: Are the scripting languages around convenient alternatives?

 Bernhard Reiter <bernhard at uwm.edu>:

>Any scripting language will do that. The shell does it.
>I would recommend python. (www.python.org)
>But you also mean GRASS functions.


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.


Leonard Coop <coopl at ava.bcc.orst.edu>:

>Here is a snippet from a perl script (I didn't write it but I use it)
>running GRASS showing how you can use perl files as standard i/o to
>write to GRASS functions, in this case r.mapcalc:

>    open RMAPCALC, "|r.mapcalc" or die "Can't launch r.mapcalc";
>    # STEP 5: ADD CORRECTIONS
>    print RMAPCALC "$corrname = ($basename * $rationame)/1000\n";
>    # STEPS 6: FORCE NEGATIVES TO ZERO
>    print RMAPCALC "$outname = max($corrname,0)\n";
>    close RMAPCALC;


Well, here we have 5 lines for what should be just one, 
r.mapcalc "out = max( ($basename * $rationame)/1000, 0)"

...and not to tell about the annoying and redundant "$": if we write
a program, the default should be that the names of the variables represent
the variables, or should I sign this message as $AgustinLobo ? If I sign
as Agustin Lobo, would anybody understand that my name has written the 
message?


 Bernhard Reiter <bernhard at uwm.edu>:
>Perl generally is a greater mess than "C". It is much harder to write
>good structured programs in perl.

But,

"Roderick A. Anderson" <raanders at altoplanos.net>:

>Despite what others may think or say perl is an excellent language for
>simple to very complex projects.  It is only as obscure as you want it to
>be. 


May be we could do the following: use a short model as an example and code
it in different scripting languages.



ISSUE 3. Are "high level" languages (i.e., Splus (R as free alternative),
Matlab (Octave as free alternative), IDL ...) adequate for GIS modeling?


Rich Shepard <rshepard at appl-ecosys.com>:
> I've know of S-Plus and I just discovered R. I think that it
> would be ideal to link GRASS and R for analytical purposes.


"Pete St. Onge" <pete at seul.org>


>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).

Another problem with Splus (I think that R is better but don't know
how much better) is that it is very inefficient with FOR loops, as it
allocates all the memory at once. This is a big problem for simulations,
that typically have long loops.

ISSUE 4. The use of Grass in modeling

Bruce Byars <Bruce_Byars at baylor.edu>

>What we have been very successful in is using grass
>as a kind of "front-end" processor to develop/analyze/display data
>for use in complex stand-alone models.  In our experience this is
>the best of both worlds.  It is not really time-consuming to write
>either scripts or C programs for this type of data development.
>In this way, a user can use whatever model they are comfortable
>with, using grass for data development and display.

>For example, we use grass to develop input data into the SWAT
>watershed hydrology model.  SWAT is a very large and complex
>model, but using grass we significantly cut down the time to develop
>inputs and analyze results spatially.


Yes, this is an obvious application. But I think that Grass could 
(should) be
used for the actual modeling as well.

Final comment: using C for writing is like making a toy out of raw 
plastic material:
you can do whatever you want but it is difficult and, probably, the parts 
will not
be used by others. Using grass commands within a script (either a shell 
script
or Splus, Matlab etc) is more like using a LEGO: you have more constraints,
but the parts are standard, which implies that many others use them and can
detect errors.










Agus

Dr. Agustin Lobo
Instituto de Ciencias de la Tierra (CSIC)
Lluis Sole Sabaris s/n
08028 Barcelona SPAIN
tel 34 93409 5410
fax 34 93411 0012
alobo at ija.csic.es
http://pangea.ija.csic.es/alobo




More information about the grass-user mailing list