Frequently asked questions

The numerical scheme is not described in detail in the solver manual. Reference material by the solver developer is available on the iRIC site: the online lecture notes at https://i-ric.org/yasu/master_e/index.htm and the collection of PDF documents at https://i-ric.org/yasu/pdf_files/pdf.htm cover the discretization used in the Nays family of solvers. The theoretical background of the numerical methods is covered in iRIC Academy.

The tmp folder created in the project directory is not filled automatically. To produce the files needed for a hot start, first run a calculation with the option "Output temporary files" set to Yes in the calculation conditions and specify the folder path where the temporary files should be written. After that run finishes, the files will be in the folder you specified, and you can point the hot start setting to that path for a subsequent run.

In a reported case this was not related to the solver or the data but to the display setup. With two monitors (a laptop screen plus an external display), opening the 2D post-processing window while the iRIC main window was on the secondary monitor froze the program, whereas opening it with iRIC on the primary monitor worked normally. A likely underlying cause is that the PC has two graphics adapters (e.g. integrated Intel and a discrete GPU) and Windows assigns different adapters to different screens. You can try moving the iRIC window to the primary monitor before opening the visualization window, or set iRIC to use a specific GPU in Windows Settings > System > Display > Graphics settings.

Importing elevation data is not enough by itself; the values must also be transferred to the grid. After creating the grid, run Grid > Attribute mapping so that the imported elevation is mapped to the grid nodes, and check in the pre-processing window that the grid now has elevation values. Running the solver with unmapped grid attributes typically triggers this kind of warning. The iRIC tutorials contain several examples of the mapping step.

The developer framework in iRIC is for registering your own solver; it does not let you plug new modules into an existing solver from outside. Changing the turbulence closure of Nays2DH requires modifying the solver source code, so the advice is to contact the developer of that solver. Note that several solvers already offer more than one turbulence model in their calculation conditions, which may cover your need. A future iRIC version with coupling capabilities between solvers was mentioned as being under testing at the time, but no release details were given.

Rather than repairing the intersections manually, regenerate the grid with a different algorithm. "Create grid from polygonal line and width" tends to produce cleaner grids when the river centre line from the survey data is irregular, because you draw the grid centre line yourself, independent of the river survey centre line, and specify the width. The procedure is described in the iRIC GUI user manual: https://iric-gui-user-manual.readthedocs.io/en/latest/04/05/01_02_polygonal_line_and_width.html. After creating the grid, map the elevation data to it with Grid > Attribute mapping.

No. Nays2DH has no rainfall input; rainfall (including X-band radar data) is a feature of Nays2DFlood only. If rainfall on the computational domain is important for your case, use Nays2DFlood, or represent the additional water as inflow discharge at the boundaries in Nays2DH.

"Calculation failure" is most often caused by an unsuitable combination of the time step (dt) and the grid cell size. Reduce the time step in Calculation Condition > Time and Iteration, or use a coarser grid with wider cells, so that the flow does not cross more than one cell per time step. Trying a smaller dt first is the simplest fix; if the run still fails, also check the initial discharge and the bed elevation for abrupt jumps.

The importable geographic data formats are listed in the iRIC GUI user manual: https://iric-gui-user-manual.readthedocs.io/en/latest/06_files.html. For bathymetry, the common choices are river survey data (.riv), point elevation data (.tpo, X Y Z text) and CSV point files. Convert your survey output to one of these, import it via Geographic Data > Elevation > Import, and then map it to the grid with Grid > Attribute mapping.

This message means the computation is diverging, so the grid and the calculation conditions need to be reviewed rather than the solver itself. Points to check:

• CFL condition: the product of the time step and the flow velocity must be smaller than the grid cell size. If in doubt, reduce the time step first.
• Grid quality: a large size ratio between neighbouring cells makes the calculation unstable, and flipped (inverted) cells, which typically appear in sharp bends, can stop the run. Enable the checks under Option > Preferences > Grid Checking in iRIC to detect such cells.
• Initial and boundary conditions: make sure the discharge and downstream water-surface settings are consistent with the terrain; a failure in the recession limb of a non-uniform hydrograph is also usually a time-step / CFL problem rather than a hydrograph problem.

The iRIC help FAQ page lists further tips for runs that do not proceed smoothly.

Internet background maps are configured in the iRIC pre-processor, not in the Nays2DH solver settings. In the Object Browser there is a Background Images (Internet) item where you can choose the map source to display behind the grid. The available services and how to switch between them are described in the iRIC GUI user manual, section "Object Browser > Background images (Internet)" (iric-gui-user-manual.readthedocs.io). If the Google tiles show a "For development purposes only" watermark, try one of the other map sources offered there.

• Obstacle blocks both the flow and the sediment transport completely in that cell. It can be placed anywhere in the computational domain as a cell attribute, but its size is determined by the grid: an obstacle occupies whole cells, so make the grid fine enough to represent the shape you need.
• Fixed bed (non-erodible bed) represents a surface such as concrete. Sediment can still deposit on top of it, but the cell itself is never eroded.

Both are set as cell conditions on the grid in the pre-processor.

Yes. Nays2DH is a suitable solver for braided-channel development. Unlike the meander examples in the manuals, start from a fairly straight, wide channel with bed deformation enabled and let the bars and multiple channels develop during the run. An example of braided-channel modelling with Nays2DH is available as a video on the iRIC YouTube channel.

An access violation during the run normally means the solver is reading invalid grid information. Review the following settings and correct anything inconsistent:

• the confluence (tributary) settings if the grid includes a confluence (for example a Type A confluence from the left bank);
• the mixed (non-uniform) grain size settings;
• the mapping of geographic data (elevation, roughness, etc.) onto the grid.

The same item is listed in the iRIC help FAQ ("When the calculation stops during the calculation (access violation is displayed)").

No. The layer parameters are read when the run starts, so they cannot be changed while the solver is paused; you have to stop the run, change the settings, and start again.

Before rerunning, revise the bed-material layer settings under the calculation conditions:

• Thickness of bedload layer (exchange layer): a value around the maximum grain size dmax or d90 is a common choice.
• Thickness of deposited layer: about 2 dmax, for example.
• Maximum number of deposited layers: increase it if thick deposition is expected.

Thicker layers or a larger maximum number of layers prevent the limit from being reached. The same guidance is given in the iRIC help FAQ on setting the grain size distribution of the exchange and deposited layers.

In current iRIC (4.x) the riv file creator macro is no longer needed and can be skipped. Cross-section survey data can be imported directly: prepare a list of the XY coordinates of the left-bank and right-bank ends of each survey station together with the cross-section data, and iRIC will read each section from it. The file format and procedure are described in the iRIC User's Manual under "Related files > River survey data > MLIT longitudinal/cross-section survey data" (iric-gui-user-manual.readthedocs.io, section 06/01_riversurvey).

It has not been removed; the menu label is different from the manual wording. Right-click on the pre-processor screen with the river survey data selected and choose Generate Cross-Section Data. This is the command the manual calls "Create River Survey Data" — "cross-section data" and "river survey data" refer to the same thing, and the English manual simply uses a different translation.

iRIC itself does not export calculation results as a raster. The recommended route is:

1. Export the results from the post-processor as ESRI shapefiles (the same export used for transects / point data).
2. Convert the shapefile to a raster in a GIS application such as QGIS or ArcGIS (e.g. rasterize the point or polygon attributes onto a grid of the desired resolution).

Alternatively, export the results as topography files (.tpo), CSV or VTK, which are point-data formats that can also be gridded in GIS or other analysis tools.

The standard Nays2DH distributed with iRIC does not provide a feature for specifying inflow discharges in arbitrary cells along the bank lines. A tributary can be represented by including a confluence channel in the computational grid (the Nays2DH manual and a tutorial video cover this), but that does not give multiple point inflows as lateral boundary conditions. According to a forum reply, this kind of lateral inflow is planned for the successor solver that is under development, so waiting for that solver or modifying the open-source Nays2DH code are the current options.

For a flat or nearly flat bed this result is physically correct, not an error. The water surface super-elevates on the outer bank to drive the flow around the bend; through the hydrostatic coupling, this produces a steeper streamwise water-surface slope near the inner bank and a flatter one near the outer bank, so the flow accelerates along the inner bank at the bend apex. Higher outer-bank velocities in real rivers arise from the point bar / pool topography and from secondary flow, which a 2D depth-averaged model like Nays2DH cannot reproduce fully; enabling bed deformation or using a 3D solver brings the result closer to observations. The theoretical background is covered in iRIC Academy.

Enable the bank erosion model in the Nays2DH calculation conditions; the grid then moves with the eroding banks. The settings are described on page 26 of the Nays2DH solver manual. Note that the grid "reconnection" (neck cut-off shortcut) seen in some demonstration videos is not available in the released Nays2DH or other solvers, so simulations run until a cut-off would occur, not beyond.

Yes. Use the CSV export of calculation results in the post-processor (see the iRIC 4 GUI manual, "Calculation result > Export"). CSV export writes one file per time step; each file lists the values for all grid nodes and cells, arranged by index (i, j), so the files can be opened directly in Excel. A short tutorial video on exporting results is linked from the iRIC forum.

Not with the standard Nays2DH included in iRIC: water levels can only be prescribed at the upstream and downstream boundaries, not at an arbitrary interior point. If this is essential, Nays2DH is open source and can be modified; the source code is available in the iRICsolvers GitHub repository (v4_Nays2DH). Otherwise, adjust the downstream water-surface boundary condition and roughness so that the simulated depth at the point of interest matches the measured value.

One known cause is the grain size distribution itself: the size classes must not start with a 0 mm class. A zero-diameter class produces numerical instabilities when bed deformation begins. Remove the 0 mm entry so that every class has a positive diameter and check that the cumulative distribution is monotonic. If the run still fails, review the bedload-layer and deposited-layer thicknesses and the time step, but the zero class is the first thing to check.

These columns appear in the grid file exported from a Nays2DH project and mean the following:

• Z: not used by the solver; it can be ignored.
• N_Elevation: the bed elevation defined at each grid node (the movable bed used for the calculation).
• N_Elevation_zb: the fixed-bed elevation defined at each grid node (the level below which the bed cannot erode).

At the time of the thread these meanings were not documented in the manual, which is why they are listed here.

iRIC can display a longitudinal profile at a chosen time step using the 1D graph (chart) feature in the post-processing window. Select the time step of interest, then create a 1D graph along the desired grid line to see the water surface profile; the graph data can also be exported for use in a spreadsheet. The procedure is described in the iRIC GUI user manual under the chart section: https://iric-gui-user-manual.readthedocs.io/en/latest/05/02_chart.html

This happens with the "Create grid from cross-section data" algorithm when no transverse division points have been defined, so each cross-section line is treated as a single cell width. You can add them in the Grid Creating Condition view:

1. Click the cross-section line you want to subdivide to select it.
2. Choose "Add Division Points" from the right-click menu.
3. Enter the number of divisions and click OK.
4. Regenerate the grid.

The iRIC GUI user manual describes this grid creating algorithm in detail (section on creating a 2D grid from river survey data).