Laserfiche WebLink
<br />Hll2l101 <br /> <br />f'i"^ <br /> <br />variables data base automatically by MMS when the variable is modified in the module where it <br />was declared. To modify a variable from a module where the vanable was not declared, a "putvar" <br />system function is used. <br /> <br />Arguments in the declparam and declvar function statements include a definition of the <br />parameter or variable and the units in which it is expressed. The definition is made available to the <br />model user through a help feature during MMS execution. The definition describes the parameter <br />or variable, provides guidance on the estimation of its initial value, and lists any other pertinent <br />information. This feature provides a mechanism for module developers to imbed their knowledge <br />and expertise within the module and have this information available to all users. The units <br />argument is used in the MBUILD process to ensure the compatible linkage of module parameters <br />and variables. <br /> <br />In the MBUILD procedure, a comparison is made among selected modules to ensure that <br />all getparam and getvar statement functions are satisfied by a declparam or declvar statement for <br />the specified parameter or variable. The declparam or declvar statement may be in the same <br />. module or another module. <br /> <br />The ability to compare parameter and variable names among modules requires that a <br />consistent terminology be used in their naming. A dictionary of currently used terms and their <br />definition is included in MMS to provide information to system users as well as to maintain <br />consistency among module developers. This is one of the more difficult system concepts to <br />develop. However, the value in improved communication within the modeling community and the <br />establishment of some consistency in process parameter and vanable definition are seen as major <br />needs in being able to compare modeling approaches. <br /> <br />While there is a requirement for consistency in the external naming convention used for'" <br />module linkage, there is no immediate need to change the terminology in the already existing <br />code that is convened to a module. Two arguments included in the declparam and declvar <br />function statements are an external system name and an internal module name. These are made <br />equivalent when incorporated into MMS. <br /> <br />Models <br /> <br />Modules are linked using MBUILD in a user-defined sequence to create a model. The mOdules <br />are executed sequentially in a time-based loop whose time step may be variable and is defined by <br />the input data stream. When a model is executed within MMS, one pass is made through the <br />initialize functions of all the modules to initialize all parameters and user-specified variables. <br />Each subsequent pass through the modules is directed to the run function to execute the process <br />algorithms. Groups of processes that have feedback must currently be included in the same <br />module in order to accommodate these mechanisms. However, the ability to group a set of <br />modules into a feedback unit is currently being developed to provide more system flexibility. <br /> <br />'. During module compilation, the MMS X-windows graphical user interface (OUI) is <br />combined'with the modules to provide the links between the selected model and the MMS suppon <br />functions~ A series of pull-down menus in. the QUI pro"ides tlie links to a vaiiety of system <br />features. These include the ability to (1) seleci and epit paramefe~ files and data .files, (2) select a <br /> <br />5 <br />