[GRASS-dev] creating new modules

Kirk R. Wythers kwythers at umn.edu
Thu Aug 24 11:17:47 EDT 2006


On Aug 24, 2006, at 3:57 AM, Hamish wrote:

> On Sun, 6 Aug 2006 16:46:12 -0500
> "Kirk R. Wythers" <kwythers at umn.edu> wrote:
>
>> However, the README file for it says that it was written for grass
>> 5.4. Does anyone know  if there are particular coding issue when
>> writing a module for 6.1 relative to 5.4?
>
> the raster format is unchanged, so not (m)any issues to worry about.
>

Thanks very much Hamish,

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?

Thanks again,

Kirk




More information about the grass-dev mailing list