Note: I've taken a peek at the RUSLE2 response to George's request. They have focused on addressing how a user can build or modify an operation's description based upon the selection of processes and their parameter values. Because we have considered it a more important issue for the user to select operations and build management/crop rotation sequences, we have not addressed the needs of the user's who must build and/or modify operations at the "process" level. Therefore, I have addressed a slightly different issue, of how to represent the operations as a list of processes from a modeler's viewpoint, than how to "create/modify" operations themselves.
Note #2: I have added a link at the end of this page to my additional email discussion comments regarding this topic.
WEPS views operations as an ordered collection of processes. This approach was taken to allow maximum flexibility in describing both existing and future operations that a land manager might employ on wind erosion prone sites. This concept has generally been agreed upon by the MOSES subgroup. Discussion has been centered around developing a common list of processes which will be used by all erosion models to describe operations.
How processes are assembled to represent an operation is the theme of the current discussion and the topic of this proposal. Enclosed are proposed methods of combining processes to define operations, including what the WEPS group sees as desirable features and necessary capabilities of such methods.
WEPS has implemented a method of combining processes together to describe an operation. What is proposed here is not precisely what is currently implemented (hopefully, it addresses some deficiencies of our current implementation). There were a couple of rules or guidelines we followed in developing this method that we felt were very important:
Flexibility - must be able to represent any new or current operation that could be described within the bounds of the defined processes.
This requirement means that the order of processes would probably be important and that an individual process could possibly be used more than once (likely with different parameter values) in describing an operation.
Do not include "shared" parameter values more than once in the operation description.
For example, if two or more processes were a function of tillage depth, then tillage depth would be present only once in the operation description, not in each process parameter list needing tillage depth. This would require "shared" parameter values to be separated in some fashion from the processes that required them.
Make easily available to the user the process parameter values they are most likely to modify among all those used to describe an operation.
This is more of a user-interface issue, but it could impact how operations are defined by an assemblage of processes. A typical operation may be defined with several processes, each having their own parameter values. Some parameter values, such as a residue burial coefficient, may often be adjusted from the default value. The user should be able to access that parameter quickly through the interface, regardless of whether the bury_res process is the first, last, or ith process in the list describing the operation.
Based upon rule #1 above, the following could be done to represent any operation:
Operation
Proc1 (parm1, parm2, ...)
Proc2 (parm1, parm2, ...)
Proc3 (parm1, parm2, ...)
.
.
.
Some examples:
One-way disk harrow (single gang of concave disks)
Processes
1 flatten_residue (parm1)
2 bury_residue (parm1)
3 mix_soil (parm1, parm2, parm3, ...)
4 random_rough (parm1, parm2, ...)
Here the effects of the disk gang which makes up the one-way disk harrow are described as four processes with the appropriate parameter values for each process.
Offset disk harrow (two opposed angle gangs of concave disks)
Processes
1 flatten_residue (parm1)
2 bury_residue (parm1)
3 mix_soil (parm1, parm2, parm3, ...)
4 random_rough (parm1, parm2, ...)
Here the effects of the offset disk harrow gangs are represented by the same four processes with the appropriate parameter values to describe the net effect of the two gangs.
Offset disk harrow (two opposed angle gangs of concave disks)
Processes
1 flatten_residue (parm1)
2 bury_residue (parm1)
3 mix_soil (parm1, parm2, parm3, ...)
4 random_rough (parm1, parm2, ...)
5 flatten_residue (parm1)
6 bury_residue (parm1)
7 mix_soil (parm1, parm2, parm3, ...)
8 random_rough (parm1, parm2, ...)
Here the effects of the offset disk harrow are represented as two independent gangs (front and back) with four processes describing the effects of each gang. This alternate method of describing the offset disk harrow allows a more precise representation of the operation (whether it is more accurate than the previous one is another question).
However, this demonstrates the flexibility of being able to describe an operation with an arbitrary number of processes in a prescribed order. In this example, the back gang of disks could be of a larger diameter and set to a different angle than the front gangs (not unusual), so there could be a sound argument for describing the operation in this fashion. Of course, the benefit of being able to do this is most important for implements with drag attachments, multi-tool implements and operations that have combined several implements together.
To comply with rule #2 above, the description of many operations becomes more complex. The following is an incomplete list of shared parameters:
Operation (tillage) speed - fixed value for operation
Operation/tool (tillage) depth - can change within operation
Operation/tool fraction of surface disturbed
Operation/tool ridge flag - WEPS uses this to describe how an operation is affected when ridges are present.
If we look at the offset disk operation using the second description, it could be represented as follows with shared parameters considered:
Offset disk harrow (two opposed angle gangs of concave disks)
Processes and Shared Parameters
A Shared parm - tillage speed
B Shared parm - tillage depth (front gang)
1 flatten_residue (parm1)
2 bury_residue (parm1)
3 mix_soil (parm1, parm2, parm3, ...)
4 random_rough (parm1, parm2, ...)
C Shared parm - tillage depth (rear gang)
5 flatten_residue (parm1)
6 bury_residue (parm1)
7 mix_soil (parm1, parm2, parm3, ...)
8 random_rough (parm1, parm2, ...)
In this scenario, the processes that required a shared parameter value would have it available to them without explicitly specifying it as a process parameter. The advantage of this approach in the example is that processes 2 & 3 would be using the same tillage depth value (shared parameter B) and processes 6 & 7 would be using the tillage depth specified for shared parameter C. This way, if the default tillage depth was changed, only the shared parameter values would have to be modified. If each process that required tillage depth had it as a local parameter, then multiple instances of the same variable would need to be updated.
Of course, many operations would only need one tillage depth and not two as represented in this example. However, there are many multi-tool tillage operations that have different depths, so it is not an unrealistic as an example of an operation possibly having more than one tillage depth. In the case of multi-tool operations, it might be desirable to have a shared tillage depth parameter that is a function of a prior shared tillage depth value. This could allow adjustment of the first shared tillage depth value only and subsequent tillage depth values adjust accordingly. For example, a multi-tool implement may have a disk gang followed by a rank of chisels. The chisels may be set to a depth of 5cm greater than the disks. Changing the depth the disks operate could then automatically adjust the depth the chisels run at.
There are some details that must be handled when using shared parameters. First, they must be read in or otherwise made available prior to the process using it being applied. This can most appropriately be addressed via the interface used to develop and/or modify operation descriptions. However, it makes the interface and associated code more complex to insure the integrity of the description of an operation. Second, with the shared parameters separated from the processes that use them, means a user may not realize a process uses a shared parameter. This too, can be addressed in the user interface.
To achieve rule#3, "provide the user easy access to selected common parameters", refers to when a user is building a management/crop rotation list of operations using pre-defined operations, not the building or creation of operations from a list of processes. This concept of providing a "short cut" to selected parameters does not mean that all parameters for an operation are not going to be available to the user. All operation process's parameters will be available to the user, they may not be quite as accessible as the "commonly modified" ones.
Examples of such commonly changed parameters may be:
tillage speed
tillage depth
residue burial coefficients
residue flattening coefficients
amount of residue added to field
The proposed new MCREW screen (see: New MCREW Interface at http://www.weru.ksu.edu:/moses/sdcs/mcrew/mcrew.html), which is a synthesis of the ideas suggested from earlier MOSES discussions, includes a tabular (spreadsheet) view with the following column headings:
Date Operation Vegetation User-defined#1 User-defined#2
One method to provide the user with easy access to some of these commonly modified parameters is to allocate user-defined columns
to some of these variables.
The reason to bring some parameters out to be viewed and accessed at this "upper" level is to remind the user that these values need to be adjusted for "local" conditions and that they are very important to obtaining the correct answers from the model. An example of this can be provided. Assume for the sake of argument, that a default tillage direction is to be stored with an operation (I know that others don't believe the default value should exist with the operation, but that is another topic). The default direction is likely to be changed for each situation it is used in. For wind erosion, tillage direction can have a significant impact on the results, therefore, having tillage direction at the top-level management/crop rotation screen reminds the user of it's importance and that the values are easily accessible for modification.
Follow this link to see email comments I made regarding Joel's and my proposals: Wagner's proposal comments at http://www.weru.ksu.edu:/moses/operations/comments.html)