A developmental version of ResSim 3.5 is included with CWMS 3.2.3.

As described in Variants v3.5 ResSim stores its input data time series for its alternatives in a .fits file type. In CWMS, CAVI is not allowed to edit the model linking information in the base model alternative .fits files created by a standalone model. Instead, the file that stores the CAVI model linking information originates as a copy of the standalone model alternative's linking and gets updated every time the user edits the linking in MLE for that alternative in any forecast run.

When a ResSim Alternative is selected in the Model Linking Editor, The MLE asks the ResSim plugin for its input Data Locations (boundary conditions, where it needs data) and displays those in the table. So, the first time a forecast run is opened in MLE once ResSim alternative is selected a specific .fits file is created as a copy of standalone ResSim alternative's linking in the native model and all the locations in the table fills up with the same data used by the ResSim standalone alternative. This file holds pathnames for each required input time series record in CAVI.

If the linking is changed the paths are overwritten in this file (CAVI version of the input data files) not the standalone version of that. Therefore, the alternatives still work properly in standalone. 

When the user selects a model alternative to link to prior models on a row in the table, the MLE asks the prior model plugin for its output DataLocations (where it produces output).  It then filters those output DataLocations by parameter, so a Flow record is linked to a Flow Record and then tries to match the input DataLocation to one in the list of output DataLocations and selects the closest match.  The automatic selection can be almost 100% right or almost all wrong depending on how well the modeler's named things consistently.

When the user is finished matching all the input DataLocations, their selections get saved back to the CAVI version of the files in the native model.  The CAVI does not store any of the model linking. These selections are shown up with the proper alternative keys as the DSS F-part in the pathnames (if they link to prior models).

To help users not have to link every model alternative in every new ForecastRun, the DSS F-Part can be swapped out at compute time by the plugin/native model.  So if a DataLocation was linked to A0B0 (A ResSim data location is linked to HMS(B0) and HMS is linked to MFP(A0)) in one forecast run, and user creates another forecast run with DataLocations linked to X0Z0 (The same ResSim data location is linked to HMS(Z0) and HMS is linked to MFP(X0)), then the DSS F-part will get changed from A0B0 to X0Z0 at compute time. This is called “Dynamic Linking”. But this swapping capability only helps when the alternative is linked to prior models (not extracted data) and there is no change in PO (not adding or removing a program above model alternative). If an alternative is linked to prior model in one forecast run and to extracted data in a new forecast run users have to edit the linking in the new forecast run first to update the files storing the linking information. Also, changing the PO causes issue. If the PO is changed and as an example a program is added to existing PO, what was A0B0 now is A0M0B0. Because the alternative is still effectively linked to A0B0 and the file holds the CAVI linking data includes the pathnames with A0B0 in their F part the alternative needs to be selected in the MLE to update F parts to A0M0B0 in the file.


New features in ResSim 3.5 are listed here ResSim 3.5 Release Notes