[GRASS-dev] creating new modules

[Glynn Clements]

Kirk R. Wythers wrote:

> I think my approach is going to have to be "baby steps". I did look  
> at r.example (recommended by Markus), which seems to read in a  
> raster, does nothing to it, then writes a new raster. If I want to  
> write a ecosystem model module for GRASS, then my goal is to figure  
> out how to organize my model's code into the "does nothing" portion  
> of r.example.
> 
> If you don't mind, like to describe my models data requirements, and  
> then hear your thoughts as module design.
> 
> The goal here is to write a module r.pnet. PnET is a general  
> ecosystem model that does carbon, water and nitrogen balance. It can  
> output things like gross and net primary production, net ecosystem  
> production, plant and ecosystem respiration, etc.
> 
> In it's present form PnET requires a file of vegetation parameters,  
> and a file of climate parameters (climate inputs are temporal, i.e.  
> daily time step would have one day of temps, precipitation, and solar  
> radiation per line). However, on a spatial application such as this,  
> climate will vary both temporally and spatially, therefore I will  
> need a multidimensional data holder for climate inputs.
> 
> Presently the vegetation parameters are in individual files based on  
> cover type (for example, one file for oak, one file for maple, one  
> file for pine, one file for corn, etc...
> 
> I am envisioning a GRASS module that takes a input raster of land  
> cover, and for each pixel, gets the vegetation parameters associated  
> with the land cover type, gets climate data for the current time step  
> (that day for example), then runs the PnET model for that pixel, then  
> writes it's output, before moving on to the next pixel.
> 
> Perhaps a good start would be to write some over simplified PnET code  
> into the "does nothing" portion of r.example and see if I can get  
> anything working?

Anything which can be done by filling in the do-nothing portion of
r.example can be done with r.mapcalc.

More generally, anything with a fixed number of inputs and outputs
where the value of each output cell only depends upon the
corresponding input cell and its immediate neighbours is probably best
done with r.mapcalc.

OTOH, if the outputs depend upon larger areas of the map, then it's
better to start with a module which has a similar structure. E.g. 
r.grow, r.neighbors and r.mfilter all compute cell values based upon a
finite neigbourhood surrounding each cell (but only for one input map;
extending the concept to several maps wouldn't be difficult).

-- 
Glynn Clements <glynn at gclements.plus.com>