Laserfiche WebLink
(1)Have a "baseline" template file for each model that specifies the baseline data for an <br />analysis. This is the default data for the analysis. The form of this file is yet to be <br />determined (MODSIM uses a scenario file and will be studied to determine whether such a <br />file could be applied in CRDSS). It could use some type of macro language so that the <br />language can be applied to different models. For example: <br /># This is the baseline scenario for the Gunnison basin WR <br />model <br />network= gunnison.net <br />output= MODSIM <br />The components of this macro language need to be studied. It could be very simple or very <br />complex and would indicate to the DMI utility how to re-create the data for a scenario. The <br />DMI utility would understand how to translate the specified data, e.g., network, into the <br />proper format for a model. A very good understanding of model input files is necessary. <br />(2)Have a "scenario" file that indicates how the baseline is to be changed to generate the <br />scenario. This file is similar in concept to the "difference" file used by the Gunnison <br />model, but its use will be extended. For scenario data storage requirements, it is proposed <br />that only the baseline data (in the database) and the baseline and scenario macro language <br />files be stored. Consequently, if the data for a scenario have to be regenerated, scenario <br />differences could be applied to the baseline. Additionally, data for scenarios that are <br />themselves modifications to other scenarios could be generated by sequentially applying <br />differences to the previous scenario, starting with the baseline. Similar to the baseline file, <br />the scenario file could employ a macro language: <br /># This is the big flood scenario for the Gunnison basin WR <br />model <br />change station "mystation" flow time series to <br />"mystation.bigflood" <br />Obviously, scenario management could get very complicated, depending on the number of <br />data items that are changed. The scenario file could employ as many useful features as <br />desired, e.g., being able to replace a historical time series with a manufactured one. The <br />scenario file would be generated by the DMI utility after the user edits the data and presses <br />a "Commit Changes" button. Again, this functionality will be reflected in the DMI design, <br />but will not be fully implemented until Year 2. <br />(3)Each DMI utility will have some intelligence related to the model for which it is generating <br />data. This intelligence will be visible in the DMI's GUI in that only applicable choices will <br />be available to the user. The DMI utility will also have enough intelligence to interpret and <br />apply baseline and scenario files. By the end of Year 2, the DMI utility will have options to <br />edit many scenario parameters (to be determined) and save such differences in a scenario <br />file. However, in Year 1, the DMI utility will only understand how to pull the baseline data <br />from the database and format it for the model (no scenarios). After studying the Gunnison <br />model and in talking to Randy Seaholm, it became clear that any scenario editor should <br />display the baseline data and scenario data in parallel displays. For example, if a parameter <br />is to be changed, then the original (baseline) value should be shown as a label next to the <br />editable value. <br />3 <br />A275 05.10.94 1.05-9 Malers <br />