Revision as of 13:46, 22 October 2012

The tutorial is prepared to use the J2000 hydrological model for hydrological system analysis of a river catchment. A test catchment and dataset of the Dudh Kosi river basin has been provided along with the tutorial. The Dudh Kosi river basin was used for the hydrological system analysis by using the J2000 hydrological model as a part of the PhD research (Nepal, 2012). The information provided here is largely based on this study. PhD Thesis. The motivation, objectives and methodological approach and the rational of using the J2000 model in the Dudh Kosi river basin are also presented. The users can use the test data to get familiar with the model application. At the same time, users can prepare their own dataset to understand the hydrological system dynamics of any river basin by following this tutorial.

Who can use the tutorial

The tutorial is prepared in such a way that the J2000 hydrological model can be used independently without any techtical support from model developers. Therefore, it can be used by students, model developers and researchers for the hydrological system analysis of a catchment. The tutorial should be read in conjunction with other sub-tutorials which has been mentioned in different part of this tutorial. Additionally, the tutorial is supplied with test dataset of the Dudh Kosi river basin (Nepal, 2012) which users can use to get familiar with the different aspects of the J2000 model. Similarly, users can also create their own dataset of the catchment of interest to run the model.

Description of the test dataset

The tutorial is accompanied by the test dataset of the Dudh Kosi river basin. This hydro-meteorological data were provided by the Department of Hydrology and Meteorology (DHM), Government of Nepal. The DHM has provided permission to use the data along with the tutorial. The users are expected to use the tutorial along with the test data to understand different aspects of the J2000 modelling system and also aim to prepare their own dataset to run the model.

Motivation

This is the motivation of the study.

Study area

This is the Study area, Dudh Kosi river basin.

Objectives and methods

Objectives and methods

The J2000 model

The J2000 model is a distributed and process oriented distributed hydrological model for hydrological simulations of meso-and macro-scale catchment. It is implemented in the Jena Adaptable Modelling system (JAMS) which is a software framework for component based development and application of environmental models (Kralisch and Krause 2006, Kralisch et.al. 2007). The simulation of different hydrological processes is carried out in encapsulated process modules which are to a great extend independent of each other. This allows changing, substituting or adding single modules or processes without having restructuring the model once again from the start. With this flexibility, a glacier module is integrated as a part of the study carried out by Nepal (2012) in the Himalayan region.

The modelling application represents the important hydrological processes of a river catchment. The principal layout of the J2000 hydrological model is provided in the figure below. The layout also includes the glacier module which has been applied in the Himalayan region. The modelling system differentiates among four different runoff components according to their specific origin. The component with the highest temporal dynamics is the fast direct runoff (RD1) (overland flow). It consists of the runoff of sealed areas and surface runoff originating due to saturated access and infiltration access processes. The slow direct runoff component (RD2) (also known as Interflow 1), which corresponds to the lateral hypodermic runoff within soil zone, reacts slightly more slowly. This process reacts slightly more slowly than RD1. Two further base flow runoff components can be distinguished. The relatively 'fast baseflow runoff (RG1) (also known as Interflow 2) simulates the runoff from the upper part of an aquifer, which is more permeable due to weathering, compared to the lower zone of the aquifer. The slow baseflow runoff component (RG2), which can be seen as flow within fractures of solid rocks or matrix in homogeneous unconsolidated aquifers.

The detailed description of the modelling systems is provided in many publications. Some of the important publications are: (Krause, 2001,; Krause 2002,; Krause, 2010,; Nepal, 2012; Kralisch and Krause 2006,; Kralisch et.al. 2007). Some of the publications can be accessed from this link also: http://jams.uni-jena.de/index.php?id=5582&L=2

Preparation of dataset

Model parameter files

The requirement of the data to run the J2000 hydrological model is discussed in detail which is a pre-requisite to run the model. Two types of data are required i) model parameter files and ii) meteorological input data. The first one is prepared and quantified inside the GIS environment and known as model parameter files. The parameter files and their values are static in the modelling application.

Users have to prepare all the input data (i.e. soil, land cover, geology, DEM) in raster format with certain resolution. While delineating HRUs, all the input data has to be provided in a same resolution. The resolution of the dataset mainly controls the number of HRUs to be formed without losing the heterogeneity of a catchment. Therefore, the resolution of input data depends upon a catchment to be modelled. If the catchment is small (e.g. 600 km²), the resolution between 30-90 is suitable depending upon the resolution of the available dataset. Similarly, for meso-scale catchment (e.g. 4000 km²), resolution between 250-500 m is suitable.

The detailed descriptions to derive the parameter files are provided below:

Soil parameter file

The detailed information required for the soil parameter file is provided in Table below.

The soil parameter file is one of the important parameter files which needs a range of information as shown in Table above to produce a comprehensive characterization regarding water holding capacity of different soil types. For this, the texture information of soil types of different soil horizons are required. A detailed description of how to produce soil parameter file is provided here:

How to prepare soil parameter file

Land cover parameter file

The land-use parameter file requires information about the land-use and land-cover of a catchment which controls the different aspects of hydrology. Such information can be derived from literature where the spatial information about the land-use and land-cover is provided. Alternatively, such information can be estimated by using remote sensing images and subsequent classification. The J2000 hydrological model requires major classification of land-use and land-cover which affects the hydrological dynamics.

How to prepare land cover parameter file

Hydro-geological parameter file

The information required for the Hydro-geological parameter file are provided below:

• hgeo.par

The storage capacity of upper (RG1) and lower (RG2) groundwater storage can be estimated by analyzing geological information of the area. The storage capacity is normally controlled by the geological formation, rock types, origin and nature of rocks and permeability. These values are expressed as maximum storage volume in mm/day of each storage type. The storage coefficient values (RG1_k and RG2_k) are used as a general recession co-efficient of two storage. These are expressed as retention time in days in the particular storage. The recession is further controlled by a flexible calibration parameter within the model.

The detailed description of the hydro-geological parameter are provided here: How to derive hydro-geological parameter file

HRUs and Reach parameter files

Hydrological Response Units (HRUs) are the modelling entities for the J2000 hydrological model. HRUs are 'spatial model entities which are distributed, heterogeneous structured entities having a common climate, land-use, soil, and geology controlling their hydrological dynamics' (Flügel 1995). The areas which comprise similar properties such as topography (slope, aspects), land-use, soil and geology, and behaves similarly in their hydrological response, are merged together to develop a HRU. The variation of the hydrological process dynamics within the HRU should be relatively small compared with the dynamics in a different HRU (Flügel 1995).

The process of delineating HRUs is described in the following tutorial. GRASS-HRU tutorial. Users need to prepare the following file for HRU delineation.

• Digital Elevation Model (DEM)
• Soil
• Land-use
• Hydro-geology

All these data must be supplied in a *.tiff data format with a same resolution. The delineation of HRUs process provide HRU and Reach parameter files at the end.

• HRU parameter file (*hru.par)

HRU schematic diagram

A sample HRU parameter file is provided below.

The HRU parameter file stores the spatial attributes of the catchment area where information about elevation, area, aspect, coordinates (x,y), land-use type (landuseID), hydrogeology(hgeoID) and soil(soilID) is stored for each HRU. The HRUs are topologically connected for lateral routing to simulate lateral water transport processes between an HRU to an HRU and was further connected to a nearby reach for reach routing. The column (to_poly) defines the HRU which passes water to next HRU.

The connection between the HRU parameter file and other parameter files is solved inside the HRU parameter file. For example, in the HRU parameter file, the HRU id 1 has all the necessary information as required in above table, including the land-use, soil and geology type which the HRU1 belongs to:

• Reach parameter file (*reach.par)

The reach parameter file stores the information about stream characteristics as well as the relationship between stream networks to accomplish reach routing. The reach parameter file contains information on the structure of the flow topology by noting the ID for every reach into which it transfers. The reach parameter is produced along with the HRU delineation process and also comprises the information as required in above table.

With respect to the figure of the HRU parameter file above, the HRU ID 1 contributes water directly to REACH ID 1 whereas HRU ID 16 contributes water to HRU ID 5 which then contributes to REACH ID 2. The interactions between the parameter files were solved by a relation between the soil, land use and hydrogeological descriptors in the HRU parameter file and respective descriptors in the other parameter files.

Meteorological input data

The J2000 hydrological model requires the following input data for the model initialization:

The J2000 modelling system uses Inverse Distance Weightings (IDW) with elevation correction method for the regionalization of the input climate data. The detailed description of regionalization approach is provided in:

[Regionalization approach of the J2000]

All the data as shown in above figure might not be available in some catchments. Normally, temperature and precipitation data are commonly available. In case, there are only few stations (less than 3) for some parameters, the IDW does not work properly. In that case, the same input value is applied for the entire catchment. For some particular variables, for example, temperature, this approach would bring large amount of errors/uncertainties. In such cases, the regionalization approach based on a lapse rate is suggested for temperature. The details of this approach is provided in Nepal, 2012.

The relative humidity, wind and sunshine hours are also not frequently available in some catchments. These values are used for the estimation of evapotranspiration while using Penman-Monteith approach. The sunshine hours and wind speed can be assumed to be enough from one station, in case no other station data is available. In such cases, the same station value is applied for a whole catchment. The one station value for relative humidity also brings certain errors while calculating relative humidity using absolute humidity and temperature. In the J2000 modelling system, a direct regionalization of the relative humidity values is not recommended. The details are provided in 'calculation of evapotranspiration' sub-tutorial.

In case these data (rhum, sunh, wind) are not available the Pennmann-Monteith approach cannot be used. Rather a more empirical approach based on temperature such as Hargreaves, can be used.

A sample of the Input data of rainfall (rain.dat) file is provided below:

The input data must be saved with extension .dat (example: rain.dat). The data in excel format can be saved as 'Text (tab delineated)(*.txt)' and changing the extension from *.txt to *.dat*. At the end of the each dataset, the data column must be ended by #end of data.dat. For more details, download the sample data file:

Each data file has the following structure (demonstrated here for the example of rainfall):

The input data of Dudh Kosi river basin can be downloaded from here.

Workspace for input data

The input data of the J2000 hydrological model has to be provided in a specific folder considered as a 'workspace directory'. This workspace directory contains all the input data required to run the model and as well as the model output files.

Folders and files

The workspace directory has three main folders: input, output and parameters. The input folder has all the required input data to run the model. The parameter folder has parameter files (hru.par, hgeo.par, landuse.par, soil.par and reach.par). The output folder contains output files of different variables after the model is successfully run. A sample workspace of test dataset is provided herewith which provides an idea of how to organize the workspace directory for the J2000 hydrological model.

Folder: input

The input folder has one 12 xml file of each input data. Please copy and paste these files as they are the connector for the real input data which are located inside the folder 'local'.

subfolder: local

The folder inside input folder contains the input data for eight variables (rain.dat, rhum.dat, sunh.dat, tmax.dat, tmean.dat, tmin.dat, wind.dat). The ahum.dat is created when the model is run first time by using the existing data.

subfolder: gis

Some GIS layers can be put here to display the spatial distribution of some output variables (for example, the spatial distribution of precipitation in a catchment (2D and 3D). For this, users need to put the DEM file of a catchment (data format: *.asc). The resolution of the DEM should be similar to the input DEM for HRU delineation process. Users need to copy the styles.sld file which is required to display a map. Additionally, HRUs, streams and station data files (*.shp) can be put in a separate folder to display the variables in a map component. The names of these files and folders have to be defined in a model xml file [model xml file].

'subfolder: dump'

Create a folder with a name 'dump' which is used to dump temporary files.

Folder: output

The folder output has two xml files (HRULoop.xml and TimeLoop.xml) and a folder current. These *.xml file defines the variables for which the output is created. Similarly, the output data is put inside the current folder (file names: TimeLoop.dat and HRULoop.dat). The relevancy of these output data are discussed in sub-tutorial 'Model output' below. [Subsection: Numerical display]

Folder: parameter

The folder contains parameter files (hgeo.par, hru.par, landuse.par, reach.par, soils.par). Please remember that these names should be same in the model xml file.

Folders: explorer and tmp

The other folder inside the workspace is explorer and tmp which is used to dump some temporary files generated while running the model.

Model xml file

The workspace directory also contains a model xml file. The model files can be read as *.xml or *.jams. These model files are provided in example test dataset.

Definition of Model xml file:

The model xml file contains the logical structure of model framework and modules used in the model. It is organized in a systematic way that output from one module is supplied as input to the next module (example: snowmelt (output from snow module is an input for soil module). The model file also contains information about the display of different variables and outputs in the JAMS framework. The model xml can be viewed using the JAMS builder to understand the different component of a specific model.

Users can follow the following tutorial to get familiar with the JAMS Builder.

An example of the Dudh Kosi model is provided in the JAMS builder.

The left window shows the location of model source code files which are required to run a model. All the model source codes are inside the *.jar file. For the J2000 model, J2000.jar file is used. The middle window provides information about the modules used in the model xml file of the Dudh Kosi model. These modules are provided in logical structure where the output of one module is provided as input to next module. A detailed description of these different modules will be provided in later section. An example of Maximum temperature regionalisation module (TmaxLapseRate) is shown in the JAMS builder below. The module uses a single station temperature data to regionalize the maximum temperature in a catchment. By clicking the TmaxLapseRate in the middle column under Regionalization, the detailed information of the module is displayed in the right windows as shown in the figure below.

All the variables used in the modules are provided under the column 'Name'. The column 'Type' describes the characteristics of variables in terms of information (data, quality) they store in the variables. The column 'R/W' determines the input and output nature of the variables. Such as 'statElev' is a elevation of a temperature station which is denoted by R. This means the information is input to the module from previous module and denoted by 'Read'. The 'W' denotes Write which is the new output value from this module. The calibration parameters, if any, are provided in the column 'Value'. This information can be changed from JAMS builder instantly. Upon clicking the variable, the information on 'attribute configuration' will be filled. This information can be changed. Please click on 'set' to save the information.

The model can be run from JAMS builder by clicking the button 'Run Model [1]' or 'Run Model from JAMS launcher[2]' as denoted by red box in the figure below. By clicking the box 1 will directly launch the model, whereas the box 2 will launch JAMS launcher. The latter will provide options to change the model parameters (such as parameter values, time period)etc.

A more detailed description of model xml file in relation to different modules and variables used in model source codes are described in (Krause, 2011). This document can be generated from the JAMS builder instantly. Click on the 'Model' from top banner and 'Generate Model Documentation'. The model documentation will be available in pdf format for download.

The model xml can be viewed and edited using text editor software also (such as PSPad) as shown below for the 'Maximum Temperature Regionalization module'.

<component class="org.unijena.j2k.regionalisation.TemperatureLapseRate1" name="TmaxLapseRate">

• This line defines the location of the module TemperatureLapseRate1 in the model library file *J2000.jar.

<var name="lapseRateWinter" value="0.6"/>
<var name="lapseRateSummer" value="0.55"/>

• The value of lapseRateWinter and and lapserateSummer is the calibration parameter which is a lapse rate of chagnge in temperature per 100 meter.

<var attribute="elevation" context="HRULoop" name="entityElev"/>

• The attribute elevation defines the elevation of an HRU which is input variable to the TemperatureLapseRate1 module. The model reads the elevation of each HRU from the HRU parameter file as explained earlier.

<var attribute="time" context="J2K" name="time"/>

• The time defines the temporal resolution of the model (eg. daily)

<var attribute="tmax" context="HRULoop" name="outputValue"/>

• tmax is the maximum temperature as output value from the module. It calculates a maximum temperature for each HRU using the input variables inside the module.

<var attribute="elevationTmax" context="J2K" name="statElev"/>

• elevationTmax is the input variable of elevation of maximum temperature station. The model read the elevation from the temperature station in input file (e.g. tmax.dat).

<var attribute="dataArrayTmax" context="J2K" name="inputValue"/>

• dataArrayTmax is the input variable of maximum temperature on a particular date.

<var attribute="tmaxOrder" context="HRULoop" name="statOrder"/>

• tmaxOrder defines the order of the station in case more than 1 temperature station is available based on the distance of an HRU with the temperature station. In that case, the model recognizes the nearby station from the particular HRU.

The logical order of each variables used in the module is very important in the model xml file. For example, each input variables must be defined earlier before it is being used. For example, the input variable 'dataArrayTmax' is defined earlier in a module called 'TmaxDataReader' module. The module reads all the maximum temperature daily data in a format which the model can recognize. Similarly, the output variable 'tmax'(maximum temperature) is then used in a later section. For example: tmax (maximum temperature) value of each HRU is used to calculate snowmelt of that HRU.

The calibration parameters can be displayed in the JAMS framework before running the model. For this, the GUI builder of the JAMS launcher can be used (Figure below). Here the example for the Temperature lapse rate has been shown. The temperature lapse rate can be kept under the group regionalization.

1. First click on the GUI builder and choose the group 'regionalization' and then click on the 'add properties'. A new window 'Model parameter editor' will appear where the information of the model component can be changed.

2. For example, in 'Component' class, choose TmaxLapseRate. Similarly, in Variable/attribute, choose lapseRateSummer. Similarly, the name and description of the parameter also have to be filled, along with the lower and upper boundary of the parameter. The users can choose the calibration parameter in between the boundary range. Users can also put extra information under Help Text to provide more detailed information about the parameter. When all the information is filled, by clicking the OK bottom, will bring the parameter in the modelling framework. Similarly, in the next step, users can choose the 'lapseRateWinter' for TmaxLapseRate. It is because the maximum temperature is regionalized with two different lapse rates for summer and winter. and also fill the other information as required as shown in the figure below:

Similarly, the same process can be repeated to TmeanLapseRate and TminLapseRate for summer and winter periods.

The figure below shows the calibration parameters for the lapse rate which is displayed in the JAMS framework. Users can change the value from the JAMS launcher before running the model.

Display model results and output

The xml file comprises components to display model results of certain variables. The model output results can be viewed in the JAMS window after running the model. The spatial distribution of certain output variables (such as precipitation, evapotranspiration) can be displayed at the end of the model run, including the 3D map. In addition, the model also provides the different efficiency results of statistical evaluation at the end of the model run.

The description of the output of model results are provided in the following sub-tutorial: [Output of model results]

Modules within the J2000 hydrological Model

This section describes the different modules within the J2000 hydrological model. The calibration parameters applicable to each module are also described with focus on their influence on streamflow. Following are the important modules in the J2000 hydrological model.

• Precipitation distribution module
• Interception module
• Snow module
• Glacier module
• Interception module
• Soil module
• Groundwater module
• Lateral routing
• Reach routing

Calculation of Evapotranspiration

The detailed description of calculation of evapotranspiration using the Pennmann-Monteith approach (Allen, 1998) is provided in this sub-tutorial.

[Calculation of evapotranspiration]

Precipitation distribution module

Calibration parameters

These parameters are considered as non-flexible parameters and not necessarily placed in the JAMS framework as tunable parameters.

In the J2000 modelling system, the precipitation is first distributed between rain and snow depending upon the air temperature. Two calibration parameters (Trans, and Trs) are used where Trs is base temperature and Trans is a temperature range (upper and lower boundary) above and below the base temperature. In order to determine the amount snow and rain, it is assumed that precipitation below a certain threshold temperatures results in total snow precipitation and exceeding a second threshold results in total rainfall as precipitation. In the range (Trans) between those threshold temperatures, mixed precipitation occurs.

Relevancy in modelling

Putting the Trs values below zero (e.g. -2) will bring more precipitation in the form of 'rain' than 'snow'.

The detailed description of this module along with the algorithm as defined in the model source code is provided in: [Precipitation distribution module]

Interception module

Calibration parameters

The calibration parameters of the interception module in the JAMS builder is provided in the figure below:

Interception is a process during which the precipitation is stored in leaves, and other open surfaces of vegetation. This process is identified as important components of a hydrological cycle that can affect the water balance components. Canopy and residue interception are considered losses to the system, as any rainfall intercepted by either of these components will subsequently be reduced by the evapotranspiration process. The interception module uses a simple storage approach according to Dickinson (1984), which calculates a maximum interception storage capacity based on the Leaf Area Index (LAI) of the particular type of land cover. The model gets the LAI information of different seasons from the land-cover parameter file. When the maximum storage is reached, the surplus is passed as throughfall to the soil module.

The parameters as shown in the figure above have a different value, depending on the type of the intercepted precipitation (rain or snow). It is because the maximum interception capacity of snow is noticeably higher than of liquid precipitation.

Relevancy in modelling

Keeping the high value of parameters (a_snow and a_rain) will store more water on leave surfaces which leads to higher evapotranspiration and less water available for next module (i.e. soil module) runoff and vice versa.

The detailed description of this module along with the algorithm as defined in the model source code is provided in: [Interception module]

Snow module

Calibration parameters

The calibration parameters of the snow module in the JAMS builder is provided in the figure below:

The J2000 snow module is carried out according to the method described in Knauf (1976) including some changes and extensions. The module estimates different state variables of the snow pack such as snow depth, snow density and snow water equivalent, which can be used for the process oriented multi-response validation. The module mainly describes the accumulation, melting and subsidence phases of a snow pack.

If the melt temperature exceeds the temperature limit value ( baseTemp), the snowmelt process begins. The snowColdContent parameter takes into account the cold content of the snow pack. The temperature of the snow pack has to be close to 0 to start the snowmelt process. Negative air temperatures are accumulated and decreased only by positive temperatures and to realize the snowmelt process.

The melt energy required for the calculation of potential snow melt is supplied in the form of sensible heat by air temperature (t_factor), energy input from precipitation as rain (r_factor) and input due to soil heat flow (g_factor). This potential melt rate is further modified according to slope and aspect of the HRU. The snow pack is able to store is liquid water (as supplied in the form of potential snow melt) in its pores up to a certain density limit (CritDens). This storage capacity is lost almost completely and irreversibly when reaching a certain critical density of the snowpack (i.e. amount of free water in relation to the total snow-water equivalent between 40% and 45%) according to (Bertle 1966; Herrmann 1976). The resulting snow snowmelt is supplied to the soil module.

Relevancy in modelling

baseTemp is a threshold temperature for snow melt. The melting only occurs if the air temperature is higher than baseTemp. Keeping the value high will make more snow to store and less snowmelt occurs and vice versa. This parameter is very important in case the basin has seasonal snow storage and melt. The best value can be found around the value 0.

snowCritDens is an important calibration parameter as this allows liquid water from snowpack to be melt when the critical density is higher than this value. This storage capability is lost nearly completely and irreversibly when a certain amount of liquid water proportionally to the total snow water equivalent (around 40%) is reached. Keeping this parameter value low will release the liquid water from snowpack quickly (as the critical density of snow is reached faster ) with less amount of snow and related depth. The high value of this parameter results more time to reach the critical density which will require more fresh snow to occur.

snowColdContent helps to reach the cold content of a snowpack close to zero so that the melting process start. Higher value will help to reach the cold content of a snowpack to zero faster than low value.

t_factor is one of the most important and sensitive parameters to produce melt runoff from a snowpack. The higher value will produce higher snowmelt and vice versa for low value. The higher t_factor value along with r_factor and g_factor will provide heat energy to melt the snowpack and produce runoff.

The detailed description of this module along with the algorithm as defined in the model source code is provided in: [Snow module]

Glacier module

Calibration parameters

The calibration parameters of the glacier module in the JAMS builder is provided in the figure below. Users can choose the method to calculate the glacier icemelt between simple degree-day [1] factor and enhanced degree-day factor [2] in the 'melt formula'. The calibration parameter at the bottom 'ddfIce' is applicable for the simple degree day factor [1].

The seasonal or fresh snow in glacier areas are processed using the J2KProcessSnow as described in the Snow Module in the previous section. When snow storage is zero in the glacier HRU, the glacier ice melt process begins using the enhanced degree day factor. The energy for glacier ice melt is represented by the degree-day factor which is the general function of temperature and radiation (meltFactorIce and alphaIce). The melt rate is further adapted to slope and aspect of the specific HRU. The model also segregates the debris covered and non-debris covered glacier HRU by using the slope of HRUs. If the slope is higher than 30 degree, the glacier HRU is considered as non-debris covered glaciers. In the debris covered glacier HRU, the ice melt is further controlled by the calibration parameter debrisFactor. The outcome from the glacier area is snowmelt (from fresh snow), glacier ice melt and rain runoff (rain-on-glaciers). All these three melt runoff are routed through the glacier areas using three different routing for snow, ice and rain (kSnow, KIce and kRain). At the end, the glacier melt, which is the product of three different runoff (snowmelt, icemelt and rain runoff), are supplied to nearby reach as overland flow (RD1).

Relevancy in modelling:

meltFactorIce is one of the sensitive parameters of the glacier module. The higher value causes higher glacier ice melt and vice versa.

tbase is a threshold temperature for snow melt. The melting only occurs if the air temperature is higher than tbase. Keeping the value high will make more snow to store and less snowmelt occurs and vice versa. The best value can be found around the value 0.

debrisFactor controls the ice melt. The higher value (e.g. 4) means the icemelt is reduced by 40% in the debris covered glacier.

alphaIce bring the radiation factor for snowmelt. The higher value will cause higher glacier ice melt.

kIce, kSnow and kRain are routing coefficient. The lower values represents the short residential time of the potential melt runoff. It is assumed that the rain on glacier surface drains faster than snowmelt and icemelt.

The detailed description of the glacier module along with the algorithm as defined in the model source code is provided in Glacier Module

Soil module

Calibration parameters

The soil module is the most complex part of the J2000 hydrological model which reflects the central role of the soil zone as a regulation and distribution system. The input for the soil module is snowmelt and precipitation in the form of rain. The middle pore storage (MPS) and large pore storage (LPS) represents the water holding capacity of the soil. The water in the MPS represents the field capacity in which water is held against gravity but can be subtracted by an active tension eg. plant transpiration. The input to the soil module is first used to fill the MPS and LPS, which determines the current soil moisture. The soil moisture conditions influence the infiltration process. The infiltration capacity of the particular soil is calculated based the actual soil moisture. Besides this, there are three different infiltration parameters (soilMaxInfSummer, soilMaxInfWinter and soilMaxInfsnow) which controls the infiltration during summer, winter and snow cover. In case of the sealed areas, only certain amount of water on the surface is able to infiltrate which is controlled by two parameters (soilImpGT80 and soilImpLT80). The water which is not able to infiltrate is stored at the land surface, as depression storage, up to a certain amount as defined in calibration parameter (soilMaxDPS) and any surplus is treated as overland flow (RD1). The infiltrated water is then distributed between the MPS and LPS which is controlled by two calibration parameters (soilDistMPSLPS and soilDiffMPSLPS). The water available in MPS can be reduced by evapotranspiration for which the root depth of the respective land cover in the soil is important. The water is the LPS is distributed between the lateral and vertical components (soilLatVertLPS). The lateral flow is responsible for producing interflow from the unsaturated zone (RD2) which can be controlled by soilOutLPS. The vertical flow (percolation) is supplied to groundwater zone (saturated zone) for which the rate of percolation is controlled by soilMaxPerc. The surplus is supplied to the LPS to release as overland flow (RD2). The overland flow and Interflow 2 are controlled by retention coefficient (soilConcRD1 and soilConcRD2).

In the case of overland flow, the retention time period may be different during high flow periods due to non-linear behavior of a catchment. For this, new parameters are introduced to represent the non-linear behavior during the monsoon season of the Himalayan region. Therefore, a new parameter (soilConcRD1Flood), as a recession co-efficient for overland flow during high flood peak period, when the volume of overland flow crosses the threshold soilConcRD1Floodthreshold defined as a calibration parameter.

Relevancy in modelling

soilMaxDPS influences the water stored in depression areas. The higher value of this parameter causes higher amount of water to be stored as depression storage and less water to be available for overland flow.

soilLinRed reduces the amount of evapotranspiration rate. The lower value will reduce the rate at a lower rate.

The detailed description of the soil water module along with the algorithm as defined in the model source code is provided in Soil Water Module.

Routing module