View source for Defining stratum state variables from LAI (lairead)

Instructions for altering stratum (vegetation) state variable values in an existing worldfile using the LAI read program (usually used to initialize stratum state variables based on an LAI image).
(For instructions on making an initial worldfile – refer to module 1 for instructions on creating input maps and module 2 on editing the template and creating the worldfile).

I. Output the following raster maps from the GRASS dataset in ascii format:
        - hill
        - patch
        - zone
        - vegid
        - lai
The hill, patch and zone maps are the same maps that you used to define those associated levels in the existing worldfile.  The vegid map is an ID map of the different vegetation types you are defining in your watershed (the stratum_default_ID found in the vegetation definition file), and the lai map is a map of corresponding LAI values for those vegetation types.

To output the maps, use the r.out.ascii GRASS command, i.e.:

'''G> r.out.ascii input=h.t100 output=ws.hill dp=0 null=0'''

'''G> r.out.ascii input=lai_map output=ws.lai'''

Give each of these maps the same prefix (i.e. ws) and these exact extensions for what map is represented, i.e. ws.hill, ws.patch, ws.zone, ws.vegid, and ws.lai

(Note: you may need to use the GRASS command r.mode to make sure the map vegid is already the mode of the vegetation ID per patch; otherwise the program will just take the last ID it finds when making the patch – this may not be always be necessary)

II. Create an allometric table text file (i.e. allometric.txt)

The first row of the text file is only one column – containing the number of entries, i.e. the number of vegetation types that will be included in the file – therefore, if you only have the two vegetation types Douglas fir and Red alder, then the number would be 2.
The subsequent rows will consist of ten columns for the following items:

1) vegetation id

2) SLA

3) leaf:root 

4) leaf:stem 

5) stem:coarseroot 

6) livestem:deadstem 

7) cn_leaf  

8) cn_froot 

9) cn_livewood 

10) cn_deadwood 


Each of the successive rows in the allometric text file (a row for each vegetation entry) will include 10 values – one value for each of the above entries for each vegetation type.  While you will include a value for each entry, you will not include the headings in the allometric text file. 
Column definitions:

1. vegetation ID – the stratum_default_ID in the vegetation definition file

2. sla – specific leaf area, found in the vegetation definition file

Columns 3-6 are defined by allometric relationships and are DIFFERENT than what is in the vegetation definition file - which specifies NEW carbon allocation, while the lairead program requires values for the existing carbon allocation on a fully formed tree:

3. leaf:root  - allometric relationship found in literature, assume if cannot find another value

4. leaf:stem  - allometric relationship, varies by type, important to get from literature if possible

5. stem:coarseroot – allometric relationship found in literature

6. livestem:deadstem – allometric relationship found in literature

Columns 7-10 reflect C:N ratio values; these you can base on the values in the veg def file:

7. cn_leaf - carbon to nitrogen ratio

8. cn_froot - carbon to nitrogen ratio

9. cn_livewood - carbon to nitrogen ratio

10. cn_deadwood - carbon to nitrogen ratio (same value can be for all veg types (333.333))

The resultant file ‘allometric.txt’ will look something like this: 



          3
          0     0     0        0          0       0          0      0        0      0
          4     1     1.83     0.0141     1.5     0.7071     40     82.4     50     333.3333333
          7     1     1.83     0.0141     1.5     0.7071     40     82.4     50     333.3333333
        


III. You must have an existing worldfile (it can have values for the stratum state variables or they can all be 0, it doesn't matter as these will change after using lairead)
Remember to list all the vegetation types you will be using in the header of the worldfile.
Also, delete any space at the top of the worldfile or it will not read the header correctly.
(When a worldfile is made - one space is included by default at the beginning of the worldfile - just delete this space in a text editor so the first line of the worldfile begins with the first line of text)

IV. Call the lairead program:

(Format)

lairead   -pre (prefix of images)   -old  existing_worldfile -redef  new_redefine_worldfile   -allom  allometric.txt

(command line example)

U> lairead  -pre ws  -old world.example  –redef world.example.Y2000M10D2H1
-allom  allometric.txt

This will give you a new redefine worldfile with the name you specified on the -redef option on the lairead command line.  This is a redefinition worldfile and will not have a header.  If you open it up, you should see the value of -9999 for all state variables except those under stratum.  Under the stratum level should be the new values based on the info you put into the allometric table. (The redefinition worldfile will contain the same name as the existing worldfile being changed, followed by a date extension designating the day the redefine will occur.)

V. Use the redefinition worldfile in a very short simulation in order to incorporate the new redefinition stratum values into the existing worldfile you want to change.

1. Make sure both the worldfile you want to change and the redefinition worldfile have the same name, but the redefinition worldfile will also include a date extension on it, i.e.:

world.example

world.example.Y2000M10D2H1

(format for the date extension is Year, Month, Day, Hour)

2. The tecfile should include a redefine_world event that occurs on the date that matches the date extension on the redefinition worldfile, as well as an output_current_state event that will generate a new worldfile that includes the newly incorporated info.

Example file - tec.redef:

2000 10 2 1 redefine_world

2000 10 3 1 output_current_state

3. Run RHESSys to redefine the ‘world’ using the worldfile you want to change (i.e. world.example) and the tecfile with the redefinition command (tec.redef) in the RHESSys command line.  Regarding the command line start and end dates of the simulation, recommend simply starting/running the simulation for the first day, redefining the world on the second day, then output the new worldfile on the third day, and end the simulation on the fourth day. That way all processes that update only once in a 24-hour period are able to complete, i.e. (on the command line):

-st 2000 10 1 1

-ed 2000 10 4 1

Just make sure the date extension on your redefine worldfile, the redefine_world and output_current_state event dates in the tecfile, and your RHESSys command line start and end dates correspond.  For example, start the RHESSys simulation one day (on the command line), invoke the redefine_world TEC event (in the TEC file) the second day (which will use the same date extension as on the redefine worldfile), invoke the output_current_state TEC event(in the TEC file) on the third day, end the simulation at the fourth day (command line).

As a result, you will get a new worldfile including a date extension that matches the output_current_state event date in the TEC file (the third day of simulation), i.e.:

world.example.Y2000M10D3H1 - this is the worldfile that you use to start subsequent spin up’s or simulations.  Just change the name of this new worldfile so you don't have the cumbersome date extension included in the name (i.e. world.lairead).

(Note: this process will assign the stratum state variable in each patch/stratum across the landscape the same associated value (i.e. cs_leafc, etc… will be assigned the same value for every patch/stratum); therefore, recommend running at least a few years of ‘spin up’ with this new worldfile to allow the vegetation to adjust spatially in response to its’ environment).