Modelling tool user interfaces

The tables below compare some main features of the user interfaces of the selected modelling tools that relate to their ease of use. These include approximate comparisons of typical model run times and the computing power needed to run them, as well as how easy it is to export and view various model outputs and test different parameter value options for sensitivity analyses and/or calibration.

The combination of how long it takes to set up a model (including preparing input data in the needed format, setting up the structure, entering the parameter values), how long it takes for the model to run, how long it takes to access model outputs of interest, and how long it takes to test and refine the model influences what can be achieved in the time that is available for a modelling project. Some modelling tools may run very quickly, but take a relatively long time to set up and don't have an efficient way to change and test multiple parameter value options, which makes calibration a time consuming, manual process. Other tools may take long to run, but can be set up to do a number of parameter testing runs and even scenario runs at once, allowing the modeller to attend to other work in the meantime (however they may have to do so on another computer if the model requires a lot of computing power!).

Interface comparison overview

Interface characteristic	WRSM-Pitman	SPATSIM-Pitman	ACRU4	SWAT2012	MIKE-SHE
Graphical user interface (vs code prompt)	yes	yes	yes	yes	yes
Catchment map display (visualise linkages)	no	yes	no	yes	yes
Model run times
Estimated model run time for a 30 year run, ~300km^2 catchment (Note: will depend on model set-up complexity & computing power!)	seconds to minutes	seconds to minutes	seconds to minutes	tens of minutes	hours
Computing resources needed
Comparative rating of computing power needed to achieve workable run times.	light	light	light	medium	intensive (need good GPU)
Model set-up ease & efficiency
Automated creation of model units & connections from map inputs (vs fully manual creation)	no	no	no	yes	yes
Input parameter values and change values for batches of models units (e.g., all HRUs of a cover type)	(limited)	yes	no	yes	yes
In-built database of suggested parameter values (e.g., for common vegetation types, soil types, etc.)	no	no	yes	yes	no
User can build own parameter databases for use across multiple models	no	(limited)	no	yes	yes
Model set-up transparency (i.e., is it very obvious what the model is doing/assuming?)
Interface makes the user interact with every component & parameter entry option during model set-up (vs having default parameter values pre-entered & not forcing user to view them)	yes	yes	yes	no	yes
Tool checks connection errors	(limited)	yes	(limited)	yes	yes
Batch runs & calibration tools
Facility for batch runs, parameter sensitivity analyses, uncertainty analyses & auto-calibration	no	yes	no	yes	yes
Accessing model output
Output viewer tool for streamflow	yes	yes	yes	yes	yes
Output viewer tool for water balance fluxes and stores	(limited)	yes	no	(limited)	yes
All water balance components that are calculated by the model can be exported	no	no	yes	yes	yes
Batch export of water balance fluxes for model's basic spatial units	no	yes	yes	yes	yes
Automated extraction of water balance fluxes for different spatial scales (e.g., by cover class area, by subcatchment, full catchment)	no	no	no	(limited)	yes

Formats of input and output data

The table below gives some basic information about the file formats used for model inputs and outputs across the different modelling tools to give a general impression of what is required to work with them. This is a very rough overview and one has to work with user manuals, tutorials, and/or pre-exist demonstration models and data to understand the various formatting requirements and file types used across the inputs and outputs of a specific software tool.
For large or complex model set-ups that will have many different inputs (e.g., different input rainfall timeseries for several different points across the modelled area), it is highly recommended to use coding tools like R or Python to prepare the input files as it will be time-consuming to get many files into the same specific formatting required by the modelling software and most do not have in-built conversion tools.

Data type	WRSM-Pitman	SPATSIM-Pitman	ACRU4	SWAT2012	MIKE-SHE
Timeseries data	Specially formatted text files (special file extensions) Monthly data with years as rows and a column for each month in a water year starting in Oct, and for some types an annual sum in an additional column. Files can be read and generated by text editors (like Notepad) outside of WRSM, even though the files do not have typical text file extensions (e.g. ".txt"). WRSM input and output file extensions show the type of data (e.g., .RAN file is a rainfall timeseries file). Data can be brought into Excel for analyses, but it is difficult to create the input file formatting within Excel. A text editor or a general coding interface like an R or Python editor can be used to achieve the needed input data timeseries.	Specially formatted text files (.txt) Some flexibility on the formatting for inputs as one can specify the row/column format and date formatting in the files in the tools' input interface. Inputs can be prepared in Excel and outputs easily opened there as well.	Specially formatted ASCII text files (.txt) & .DBF files Input is daily data in long-format (one date per row) in a composite file containing climate variable and observed flow inputs in specified column orders and number formats. Difficult to prepare simply in Excel, and labour intensive to prepare in a text editor (e.g, Notepad), but reasonable to prepare in a general coding programme like R or Python. Outputs are .dbf format text files which open easily in Excel.	Specially formatted text files (.txt) & Access database files Daily data in long-format (one date per row) text files. Reasonable to prepare and easy to open in Excel. Outputs can also be produced in an Access database.	Software-specific .dfs0 file format Dfs0 files for input must be generated within MIKE software. Data in long-format (each row is a timestep) prepared in Excel can be copy-pasted into a blank dfs0 file with the correct number of rows and data from dfs0 files can be copy-pasted into Excel. There are also batch conversion tools in MIKE that can be used to convert specifically formatted text files into dfs0 files and to convert dfs0 files into text files.
Spatial data	N/A (Spatial data is not directly input into the software) Spatial data must be interpreted outside of the tool to decide on how to set-up the network of modules: what areas will have their own modules (e.g. subcatchment delineation; special cover types to represent separately, like plantations, irrigated areas, wetlands; river reaches and dams), determine sizes and other characteristics of the modules, and how they are linked to one another.	N/A (Spatial data is not directly input into the software) Spatial data must be interpreted outside of the tool to decide on how to set-up the network of subcatchments: subcatchment delineation plus special features to represent specifically like dams, plantations, irrigated areas, wetlands), determine the sizes and other characteristics of subcatchments and special areas, and how subcatchments are linked to one another.	N/A (Spatial data is not directly input into the software) Spatial data must be interpreted outside of the tool to decide on how to set-up the network of subcatchments composed of HRUs, river reaches, & dams: subcatchment delineation, what areas will have their own HRUs (land cover types to represent individually), determine the sizes and other characteristics of the HRUs, and how units linked to one another.	Standard GIS shapefile and grid/raster files (geotif, grid) used. DEM input must be a raster. Land cover and soil type data can be input as shapefiles or rasters (see user manuals for formatting/attribute requirements). Tool-delineated subcatchments, river lines, HRUs are output as shapefiles. Hydrological predictions are not output in a spatial format. The data can be linked back to spatial units based on ID numbers manually by the user for spatial displays. (SWAT+ has developed tools for this internally...)	Software-specific .dfs2 and .dfs3 file formats used in general. A few inputs allow standard shapefiles. dfs2 files are 2D gridded data. Standard GIS grids can be saved in an ASCI format in GIS software and then a MIKE tool applied to convert to dfs2. Subcatchments and landcover can be input as shapefiles. Many hydrological predictions can be output as spatial data as .dfs3 files, 3 dimensional data "cubes": a 2D grid of values (e.g. transpiration, surface water depth, soil moisture, groundwater depth) for each timestep, all in one file. These can be stepped-through or played as video in the interface. Timeseries for point locations or specified areas can be extracted. .dfs2 files can be converted to ASCI files to open in GIS software using an in-built tool.

User impressions of 'ease-of-use' (modeller survey)

A brief survey for hydrological modellers was distributed via the South African Hydrology Society (SAHS) as part of the model intercomparison project (2019-2021). Participants were asked to rank the ease-of-use of the software interface for any modelling tools they were familiar with on a scale of 1-5 in which: 1=poor, 3=satisfactory, 5= excellent
There was a very wide range of scores assigned for each tool across the respondents, showing that different people experience the tools differently!
Both the average and the range of scores assigned are presented below

Survey data	WRSM-Pitman	SPATSIM-Pitman	ACRU4	SWAT2012	MIKE-SHE
Number of users answering survey	13	14	19	9	8
Average ease-of-use score 1-poor to 5-excellent	3.8	3.4	3.4	3.9	3.0
Range of scores assigned 1-poor to 5-excellent	2 - 5	2 - 5	1 - 5	3 - 5	1 - 5