Response to George Foster's email to MOSES management subgroup on Tue. Aug. 12.
I am not yet convinced that all the "primary" process classes have been defined to handle all the situations that I think will be needed in our models. Hopefully, as we discuss and address each of the process classes we have currently defined with respect to their parameters, my questions and concerns will be resolved.
A couple of possible solutions are mentioned frequently below about how to handle some scenarios I have used as examples during discussions on individual physical processes to illustrate specific problems. Basically, they deal with situations where a single process definition with a fixed set of parameters can't address. I think the discussion I present for some of the individual process classes will provide plenty of real world examples of why I see this as being an issue we need to address in this group. However, to introduce the topic briefly here, assume that:
Process_A = f (parm1, parm2)
where parm1 and parm2 are fixed absolute values.
Now there may be some situations where Process_A needs to be defined as follows to best simulate the actual situation:
Process_A = f (parm3, parm4)
where parm3 and parm4 need to be fractional (%) or relative values.
Obviously, there are several approaches to handling this problem, some are: 1) have more than one distinct "instance" of a physical process, in essence then, more than one "definition" and thus implementation of the actual physical process.
Process_A(1) = f (parm1, parm2)
and
Process_A(2) = f (parm3, parm4)
2) have a physical process defined such that it handles all the cases that need to be addressed.
Process_A = f (parmA, parmB, flag)
if flag == 0 then parmA = parm1 & parmB = parm2
if flag == 1 then parmA = parm1 & parmB = parm4
else parmA = parm3 & parmB = parm4
3) some combination of 1) and 2) above that could possibly address other, more complex situations, because it provides even more flexibility.Currently, WEPS has implemented all three methods above to handle a variety of situations. Typically, we took the approach that it was better to define multiple "instances" of a specific physical process that handled specific situations in a simple manner than it was to implement one complex "instance" which carried along a lot of seldom used parameters or employed special flags that were likely to be confusing to the user. The drawback was that in some cases more than one "instance" of a process could actually be employed to define the exact same situation. I hope the introduction to these ideas help provide an understanding to why I raised and addressed issues regarding individual processes in the manner that I have.
I think the approach that George has suggested will work in many cases (shared parameters such as speed and depth be assigned at the operation level, but be passed in some manner to the individual operation's processes that require them as parameters).
In George's scenario, he has implied that speed is an operation level parameter and thus all processes representing that operation have to "occur at the same travel speed". I can't envision a problem with the variable, "speed", being treated in this fashion.
George goes on to say that the variable depth can be assigned at an "operation level" as well. However, each individual process (or group of processes) representing an operation component are then assigned a depth value that could be changed relative to the "operation level" depth parameter. From his discussion, I understand that he expects the interface to maintain a link between the "operation level" depth parameter value and the process depth values such that a change in the "operation level" depth parameter causes a relative shift in the individual process parameters (but not the other way around, i.e., a change in a process depth value only changes the relative difference to the "operation level" depth in the link and doesn't change the "operation level" depth value).
I agree in principle with this approach as it allows a user to quickly change the "depth" of an operation at the "operation level" and it correctly propagate down to the individual process depth parameter values correctly. However, there are a couple of issues that need to be addressed.
If a user is allowed to specify such a sequence as a single "operation", then he should probably have the ability to "set the depths" of each independently of the other. The other option is to require the user to specify such combinations as distinct operations performed sequentially on the same day. Regardless, we must define how we will handle this situation.
Say a multi-tool implement is defined such that it has two major components, a disk gang and a chisel rank. The "operation level" depth can be specified and the relative depths for the tow components, disk and chisel, can be set. However, if there are several processes that require the depth variable for each component, how will the user quickly and conveniently be able to adjust the "relative" depth of a single component, disk or chisel, to the "operation level" depth value? We surely don't want him to manually adjust the depth value for each individual process that makes up one of the components.
It appears that we might want to have another potential "component level" depth value that is analogous to the "operation level" depth value. This approach could resolve the similar situation presented regarding multi-implement operations where the individual implements would be a "component" of the operation. The disadvantage of this approach is the potential complexity in implementing it in the interface (with respect to what we gain in functionality) and possible confusion by the user.
Currently I see two soil processes that are either missing or will need to be handled via the currently specified processes in a manner I don't see at this time:
ASD is a physical soil parameter that is maintained within WEPS. Typically, tillage operations will affect ASD within the tillage zone by "breaking" aggregates of one size into more aggregates of a smaller size. WEPS incorporates a 2-parameter "crushing" model to reflect this effect on ASD. The WEPS Soil Submodel deals with simulating the re-aggregating/consolidating process on ASD due to climatic effects.
I don't think this is being addressed by any of the currently specified soil processes. My understanding is that the "compact soil" process is to deal with changes in soil bulk density due to an operation (tillage implement) below the tillage zone or an operation that does no "tilling" such as a surface roller packer.
As I understand it, this process will then contain four parameters:
WEPS currently only recognizes the first three. A fixed 1:4 ridge slope is assumed in the model. I don't see the ridge side slope parameter being a problem for WEPS to deal with.
I do have some questions regarding this process though. Obviously, one method (or instance) of this process is for the user to define the resultant final ridged condition regardless of the pre-operation ridged condition. This is an obvious and valid approach for many types of operations, but there are situations that this approach isn't adequate. I believe that this is an example of where there may be a need for more than one method (or instance) of describing the create/modify ridges process. In fact, this is the approach (multiple versions of a process that accept different numbers and types of parameters) that WEPS has attempted to take to handle some of the issues (example scenarios) I raise here.
In WEPS, one of the "instances" of this process is implemented such that we automatically reset the tillage depth to a value sufficient to create the desired ridges. Thus, all the other soil processes such an operation performs are correctly applied to the correct soil layers down to the depth required to create the specified ridges. This is probably the best approach to handling operations that are used primarily for the purpose of creating ridges as a farmer will "set" the tillage depth of these implements to create the ridges he wants. Thus, one "instance" of the create/modify ridges in WEPS is designed to handle the goal of creating specific ridges, not to determine some of the ridge characteristics based upon tillage depth/implement type.
We certainly don't need to have multiple instances of that implement in the database with different ridge widths specified. We probably want a way to have one instance of the implement listed in the database that does this function that will work correctly regardless of the current ridge width (these types of implements usually can be adjusted to work with different ridge spacings anyway). As I see it, we can handle this in at least one of two ways: 1) have additional parameter flag(s) for a single create/modify ridges process that indicates this variant effect, or 2) have a second instance of the create/modify ridges process that doesn't include a ridge spacing parameter.
If we want to simulate these situations, which I think we want the ability to do, then we have to either have another "instance" of the create/modify ridges process or have an additional parameter flag to handle this situation.
George comments on the need for an operation that needs to create a dike height relative to the current ridge height. I again see this being handled best in one of two ways: 1) have another "instance" of the create/modify furrow dikes process that takes a relative parameter value for dike height with respect to the current ridge height, or 2) have a parameter flag that signals the dike height parameter is a relative rather than an absolute value.
Another question arises here as to whether there would be a need for a relative dike height to be specified as a fraction of the current ridge height rather than a displacement offset from the current ridge height. I don't have enough experience with dikers and ridger/dikers to answer this question.
Also, the destruction of dikes are inter-related with ridges. Some operations may destroy only the dikes but not affect ridges, others may treat ridges and dikes equally. We will need to be sure that we can handle both situations. A combined create/modify ridge and dike process "instance" might be a possible solution.
WEPS currently implements random roughness effects caused by an operation as being a function of the initial roughness and the type of operation. Thus, it handles situations where an implement like a harrow which is typically is used in conditions where it will leave a relatively smooth surface but since it isn't an "aggressive" tool, can't create that smooth surface if the pre-tilled surface is extremely rough. A roto-tiller for example would create very similar surface conditions, regardless of the initial soil roughness.
WEPS does not deal with changes in after tillage surface roughness at the "management" level. The WEPS Soil Submodel deals with degrading a random rough surface down to some "long-term" roughness level. The "long-term" roughness level and decay rate are determined ultimately by soil type.
Currently specifying distribution of incorporated material isn't controlled by the user except for a "mixing" coefficient that distributes the amount of material being incorporated among the soil layers within WEPS. I think a distribution curve, or parameters for such a curve, could be implemented easily within WEPS.
I like the idea of providing a distribution curve based upon the implement type. Currently WEPS uses a "mixing" coefficient with a value assigned to an implement that affects the "completeness" of mixing within soil layers.
Currently WEPS assumes a common soil/management subregion as being uniformly homogeneous. When processes are applied to only a portion of the area, the effect of each process is determined and the results weighted averaged back with the original values.
If others can suggest good ways to handle such things within WEPS without dramatically altering it's current underlying structure, I would appreciate it. One of the problems I foresee is that if there are two residue burial coefficients (one for rill and one for interrill regions) which should WEPS apply? If we decide to have a single coefficient and two additional ones for rill/interrill use, will that confuse the user? Would he be required to provide all three when constructing an operation?
I envision this process as increasing the bulk density below the tillage zone for tillage implements and also representing surface "packer" implements. We have not yet implemented it within WEPS, but see it being important for predicting the development of "claypans", etc. Some wind erosion susceptible regions rely on this subsurface compaction zone for them to "create" large surface aggregates with chisels when emergency tillage is required to control wind erosion.
I would assume a mass per unit area parameter would be required with a compaction model then using that value along with knowledge of specific soil parameters to propagate the effects of the weight below the tillage depth (or surface).
I have lots of comments/questions regarding these. I've thought about this some as I believe each model treats biomass differently in terms of pools (live, dead), component types maintained (leaves, stems, roots, etc.). What we need to do is develop a structure in MOSES management that can encompass all the current systems in a coherent, comprehensive manner.
For informational purposes, WEPS currently has 4 biomass pools (current crop, residue of previous crop, residue of 2nd previous crop, and all older residue). Each of these pools obviously are identified by a vegetation type to associate specific vegetative/residue growth and decomposition information with them (the third residue pool uses a "generic" crop designation for decomposition purposes). The crop pool is partitioned up into 4 parts by mass (stems, leaves, roots, and reproductive components. Stem and leaves are further partitioned into 5 components by height with root mass partitioned among the soil layers. Residue pools are partitioned into 3 parts (standing stems, flat material, and below ground material). No distinctions are made relative to residue types (leaves, stems, etc.) in the residue pools. Transfer of material from the crop pool to a residue pool and subsequent shifting of material from one residue pool down to another is triggered explicitly within WEPS as a physical process. So, for example, the "kill" process will initiate a transfer of biomass from one biomass pool to another. Cutting will move both live and dead standing material to the appropriate biomass pool components (flat).
Due to several issues that I don't think we have adequately addressed in WEPS, I have been considering an alternate approach for the future that might have some ideas useful for MOSES Management. Assume the following:
This would address some weaknesses I see in WEPS: 1) how to conveniently deal with intercropping when WEPS incorporates a crop growth model capable of handling more than one crop growing at the same time, 2) eliminate the problem of having to "transfer" material from a "crop" pool to a "residue" pool so that a dead crop can decompose, and 3) address the problem that could occur in WEPS where a crop may have completely matured due to climatic conditions, yet not be harvested until sometime later (early freeze). If WEPS moves the crop to a residue pool so that decomposition begins, the crop is no longer available to be "harvested" because it isn't in the "crop" pool.
These are ideas I have in how to make changes within WEPS to handle intercropping whenever that becomes a priority in the future. I realize that it is a little off the current subject, but if any of you have suggestions/comments related to this outside of MOSES management, let me know.
Oh, one question, what is the definition of "pods", the reproductive components of a crop, or what?
No problem here that I see, except that we can't handle intercropping at this time.
I expect that we will need a parameter that specifies what fraction of the crop is killed. I also see it being required that the actual crop(s) being killed must be specified as well. For intercropping situations, does the operation affect the last planted (selective herbicide to kill a cover crop), first planted (harvest operation), or both growing crops (non-selective herbicide)?
WEPS changes canopy information based on the change in crop height and above ground mass internally in the crop growth model.
I believe that we are going to have to have some way of specifying if the cutting process is selective, i.e., affects only the crop, only the residue, or both.
There may be a need for a "fraction of material cut" to represent a "cut efficiency" for the operation. I don't know.
Again, there may be a need to provide an option as to whether the flattening process is selective to only the crop pool, residue pools, or both.
Bill Elliot communicated with me about the deficiency within WEPP regarding removal/burial of residue on a cover basis when there are large mass quantities of biomass on the surface. Without getting into the details of the problem, he feels that it is necessary for operations to be able to be constructed that can bury/remove biomass on a mass basis in MOSES. WEPS currently can handle both situations.
Again, I see a need to distinguish what is being removed, crop, residue, or both. Also, possibly by component (leaves, stems, pods).
My initial thoughts here is for shredding to change a residue from "non-fragile" to "fragile", thus changing the decomposition rate of the material. Another way may be to move shredded stems to the "leaf" pool and shredded leaves to the "pods" pool for those models that handle them.