Setup procedure

created in each time step, dependent on the logistic growth model and the number of agents that were deleted due to the ageing process incorporated in the model.

Finally, scenarios of future annual rainfall can be selected, based on local climate data as simulated by the IPCC (International Panel on Climate Change), which is the leading research group with respect to global climate assessment. The annual data of the rainfall scenario selected by the model user are fed into the productivity functions for rainy-season land-use types. Furthermore, a model is developed (see Chapter 5) to calculate the forage availability for local livestock based on rainfall data in order to determine the annual carrying capacity for local livestock. This way, in GH-LUDAS, a decrease or increase in crop and forage productivity due to changing rainfall patterns indirectly influence land-use choice and livestock dynamics and thus livelihood strategies (Figure 3.9). The details of the integration of rainfall data into crop and forage productivity are given in Chapter 5.

Global-policy Module Carrying Capacity C

Growth Rate r

Calculate Population Size P_tat Time Step t

Create (P_t- P_t-1+ D_t) Agents

Calculate Number of Deleted Agents D_t Calculation of Age

? ?

? ?

Figure 3.8: Regulation of agent population in GH-LUDAS Landscape setup

The setup procedure for the landscape can be structurally described by the following succes-sive steps:

1. The implementation and visualization of current land-cover patterns in the study area, based on the analysis of satellite images

2. The assignment of patch-specific variables to all patches located in the study area 3. The allocation of dams to this landscape via mouse click, if the examination of this

policy is desired by the model user.

As this section mainly deals with the implementation of the model, we will only give a short explanation of how these patch-specific attributes have been derived, and focus on the way of implementation. The sources and derivation of these attributes will be described in detail later in Chapter 5.

The land-cover pattern of the year 2006 was derived from two satellite images using the ERDAS package. The first image with a higher resolution, served as the basis for the digitization of the main river and its tributaries, while the second provided the basis for the

Global-policy Module Choice of Rainfall Scenario

Global-policy Module

BEHAVIOR STATE

Decision Module H_group Hgross income

Landscape Module

STATE BEHAVIOR Yield Dynamics Livestock Dynamics

Pland use dry

Pland use rainy

-Generating income

Land-use actions

Figure 3.9: Integration of rainfall change in GH-LUDAS

classification of all remaining land-cover types. These two images were then converted to ascii files, which store a single value per pixel, representing one patch of the landscape of 30 m x 30 m. These ascii files can then be easily read by NetLogo, whereas each patch of the view is assigned its specific value of land-cover. Within the view, these different land-cover types were then visualized by different colors.

While the land-cover patterns are visible within the view, the other patch attributes are only stored but not visualized. These variables include institutional attributes (P_village, P_compound), distances (P_{dist river}, P_{dist dams}, Pdist water sources), and all biophysical variabes (P_wetness, P_upslope, P_elevation, Psoil fertility, Psoil texture, P_gwl, P_gwr). The irrigation coefficient P_{irr oeff}and the dummy variable P_irrigableare then calculated from this data set (see Chapter 5). All other variables were derived from different sources such as maps, GIS layers created by previous studies of the study area, and satellite images. In the same manner as the land-cover data, the data were also converted to ascii files to be read by NetLogo.

The last procedure is only called if the user wishes to implement dams within the model. Within the view, the dam can be inserted by the user via mouse click, and its

irriga-tion capacity can be set specifically for each dam. This way, each dam has its own specific irrigation capacity. Each inserted dam consists of the dam itself and its respective irrigable area. First, the procedure creates a dam as a circle around the selected patch, while the size of the circle is defined by the irrigation capacity, and converts the land cover of these patches to ’water’. Second, the irrigable area is created along the direction of minimal elevation (P_elevation), with the number of patches pre-defined by the value of irrigation capacity. Fi-nally, the dummy variable (P_irrigable) is set to 1 for all patches within this irrigable area.

Household agents setup

The setup procedure for household agents can be structurally described by the following suc-cessive steps:

1. The import of the set of 200 interviewed farmers, together with their specific household variables

2. The multiplication of these 200 households to populate the landscape to its actual pop-ulation size

3. The calculation of distance variables for all household and landscape agents 4. The allocation of land holdings for each household agent

In the first step, to ensure a reliable reproduction of the real population, copies of those households that had been interviewed during the field surveys will be created. These household agents are endowed with the same set of variables as the interviewed farmers, and are located within the respective village of the catchment. Within each village, they are distributed on the compounds as digitized by a high-resolution satellite image, i.e. on patches with the dummy variable being P_compound=1. The range of imported variables comprises all attributes that are of relevance for the next time step of simulation, including institutional and social attributes (e.g. H_village, H_age, etc.), labor resources (e.g. H_labor), financial resources (e.g. Hgross rainy, H_{gross dry}, etc.), and land resources (e.g. H_holdings).

These variables are imported as text files into NetLogo, each storing 200 values, one for each household. Just like the ascii files, these files can be easily called by NetLogo,

assigning each value to its respective household agent. After the creation of the set of these 200 agents, the population will be augmented by creating copies of these basic agents until the actual population size is reached. These new agents are allocated to the same village as their original, and distributed within the different compounds in the respective village. The actual population sizes for each of the villages were calculated from statistical data sets provided by the Ghanaian Survey Department.

In the third step, when all agents have been created, the distances of these agents to landscape features such as main river and dams are calculated. Furthermore, if dams have been inserted into the landscape, the distance to dams are updated for all landscape agents.

Finally, since virtual household agents should also own patches as in reality, this procedure allocates land holdings to each of the agents. The sizes of these land holdings are given by the holding variables of the agents, as called by the first procedure. The location of these patches is given by the land-allocation procedure, which works as a loop. In each loop, each agent is allowed to select one single patch, and the procedure will be run until all agents are assigned their specific amount of land.

The loop itself runs as follows: As long as patches within the Landscape Vision are still available (i.e. P_owner=’nobody’), the called agent will mark a random patch within this vision as his. If no patch within the Landscape Vision is available, the agent will select a random patch within the same village, and if none of these are available, the agent will select a random patch from the whole catchment. The design of this procedure avoids a biased pat-tern of distances of owned patches to their respective owners.