Frequently asked questions

No. Nays2DFlood has no dedicated structure model for dams, reservoirs or bridges, so their detailed operation (gates, storage routing, pier effects) cannot be represented directly. What the solver does offer is rainfall input and box culverts, which are described in the Nays2DFlood solver manual (culvert settings around p.10 and p.37, rainfall around p.26 of the English manual). If an embankment-like structure must be represented, the practical approach is to raise the ground elevation with a polygon or place obstacle cells rather than trying to define the structure itself.

The N2F.tpo topography file is not bundled with the iRIC installer's example folders. It is provided as part of the "sample data" package on the Nays2DFlood solver page of the iRIC website (https://i-ric.org/en/solvers/nays2dflood/). Download that package and import the .tpo file through Import > Geographic Data > Elevation to follow the tutorial.

A failure at the very first step almost always points to a problem in the input data rather than the solver settings, so re-check the elevation data, grid and calculation conditions carefully. One workaround that has been reported to fix this: after importing the geographic data and creating the grid, save the project and close iRIC, then reopen it and perform the attribute mapping (elevation to grid) before running the solver. In that case the mapping was processed correctly and the calculation started normally. This is a reported workaround rather than a documented fix, so if it does not help, verify that the elevation values and coordinate system of the imported data are valid.

Raising the elevation with a polygon does not act exactly like an obstacle cell. Elevation is smoothed between grid points when it is mapped, so a narrow raised strip may be flattened; make the raised area at least 4 grid cells wide so it reliably blocks the flow. A true obstacle cell blocks flow without this smoothing. To pass water through the raised section, set up box culverts as described in the Nays2DFlood solver manual (see around p.10 and p.37), where the invert level and dimensions are specified. Note that dams and bridges themselves cannot be modelled in Nays2DFlood.

Overlapping cells usually occur where the centre line bends sharply relative to the grid width. Edit the grid-creating condition rather than the finished grid: in the Object Browser, select Grid Creating Condition, then drag the black control points of the centre line (and adjust the width) so the transverse lines no longer cross. Re-create the grid afterwards and check the affected sections again before running the solver.

There is no fixed recommended value; they have to be tuned by trial and error for each grid. The time step is limited by the CFL condition: the distance travelled in one step (velocity x time step) must stay below the grid size, otherwise the calculation stops. So a larger time step is only possible with coarser cells or slower flow; if you do not know the velocity beforehand, start small and increase gradually. For the water-surface relaxation coefficient, increasing it speeds up convergence but makes the iteration less stable. If the calculation does not converge, decrease the relaxation coefficient and increase the maximum number of iterations.

Use the graph window: click Open New Graph Window on the main toolbar, choose I as the X-axis coordinate, and add Water surface elevation ("WaterSurf") as the plotted value. This gives a longitudinal profile of water level along the grid; by fixing J you can read the level at each I position. There is no built-in cross-section table listing water level per section; if the grid has no cells in the transverse direction, a cross-directional water-level display is not possible. As an alternative, export the results as CSV and extract the water surface at the grid points of interest.

Convert the raster to a plain XYZ text file with a GIS program first, then rename it. In QGIS: load the DEM, open Raster > Conversion > Translate (Convert Format), choose the XYZ output format and run the conversion. ArcGIS (Raster to Point, then export the table) works as well. Open the exported .xyz file in a text editor, use Save As and change the extension to .tpo. The file is then ready to import in iRIC via Import > Geographic Data > Elevation. If the resulting file is very large (tens of MB), importing may be slow or appear to hang, so consider clipping the DEM to the study area or resampling it before conversion.

Two settings are involved. First, obtain an API key from Google Maps and register it in iRIC under Option > Preferences > Background Images (Internet) tab (see the iRIC GUI user manual, Preferences section). Second, if your organisation uses a proxy, set it under Option > Preferences > Network Proxy; without the correct proxy the tiles cannot be downloaded. Some users reported that images still did not load after these steps, so also confirm that the project has a valid coordinate system set and that the API key is enabled for the map tile service.

The option is under Calculation Condition > Others > Finite differential method for advection terms. CIP is a higher-order scheme that interpolates with a cubic polynomial, which reduces numerical diffusion and gives higher accuracy; the upwind scheme is simpler and more diffusive. For inundation analysis both are considered accurate enough, and in practice the difference in results is small, so a reasonable approach is to run both and compare. The theoretical background of these schemes is covered in iRIC Academy.

iRIC does not compute the inundated area directly. A workable method is to export the calculation result as CSV (File > Export > Calculation result), which gives the coordinates and water depth of every grid point. Then, in a spreadsheet or GIS, compute the area of each cell and sum the areas of the cells whose depth exceeds a chosen threshold (for example 0.01 m). Alternatively, export the depth contour as ESRI Shape files and measure the polygon area in GIS.

A mid-run failure usually means the flow became too fast somewhere for the current time step and grid. Try the following in order: 1) reduce the calculation time step; 2) make the grid spacing coarser; 3) look at the result just before the failure, find where the velocity spikes, and correct the elevation there (spurious pits or steep steps in the DEM are a common cause). Re-run after each change to see which one resolves it.

This is a sign that the project is working in latitude/longitude degrees instead of metres. Nays2DFlood calculates only in metre units, so set the project coordinate system to a projected system in metres (for example a WGS 84 / UTM zone) via the project property dialog, as described in the iRIC GUI manual. The elevation data must also be in that metre-based system; if the imported points were in degrees, re-export them from GIS in the projected coordinate system before importing. If the imported data appears blank after changing the system, the data and the project system do not match, so check the export projection again.

Use File > Export > Contour Figure as ESRI Shape files to export the depth (or other) contour of a chosen time step as a shapefile. There is no built-in maximum-inundation export, so export the relevant time steps and overlay them in ArcGIS to derive the maximum extent. Another approach is to export results as text/CSV points, build a point layer in QGIS or ArcGIS, and interpolate a raster from the depth values for further GIS analysis.

No. Nays2DFlood and Nays2DH are purely 2D solvers, and the current iRIC does not support coupling a 1D channel model with a 2D floodplain model. Model coupling (1D to 2D, 2D to 3D) has been mentioned as a future direction for iRIC, but it is not available in the released version. Note also that a 1D channel plus 2D floodplain approach is generally considered a poor choice for flood simulation, because the details of flow inside the channel strongly control where and how much water overflows and returns; running the whole domain in 2D is the recommended approach.

When two separate point-set (.tpo) files are imported into iRIC, only one of them is used when mapping elevation to the grid. The workaround is to merge the two data sets outside iRIC into a single .tpo file that contains both the DEM points and the surveyed cross-section points, then import that combined file. After mapping, check the resulting riverbed elevation in the pre-processing window to confirm that the surveyed cross-section values now appear in the grid.

In the graph window, the type of plot is controlled by the X-Axis selector at the top-left of the window. Choose I or J (grid index direction) instead of Time to get a longitudinal or transverse profile of water depth or water surface elevation along the grid. With Time selected you only get a time series at one point, which is why the profile does not appear.

No. Neither Nays2DH nor Nays2DFlood supports nested grids. Each calculation uses a single structured grid. If you need higher resolution in part of the domain, the available options are to refine the whole grid, to vary the cell size along the grid, or to run a separate calculation for the area of interest.

Each arrow shows the flow velocity at a grid point: the direction of the arrow is the flow direction, and its length is proportional to the velocity magnitude (longer arrow = faster flow). The arrow scale and display settings can be adjusted in the Arrow item of the 2D post-processing object browser, which is described in the iRIC GUI user manual under visualization.

iRIC does not compute travel time directly. A practical way is to use the Particles function in the 2D post-processing window: release particles at the upstream end and watch how many output steps they take to reach the downstream end. Because the particle tracking is based on the stored output, it is better to set a small output time interval in the calculation conditions before running, so that the particle movement is resolved well enough to read the travel time.

When the grid size is changed, the calculation time step (dt) must be changed too. Most calculation failures in Nays2DFlood are related to the time step. dt should satisfy the CFL condition:

• dt < dx / (|u| + sqrt(g*h)) and dt < dy / (|v| + sqrt(g*h))

where dx, dy are the grid spacing in each direction, |u|, |v| are the absolute velocities, g is gravity and h is water depth. A smaller grid therefore needs a smaller dt; for example, try reducing 0.2 s to 0.1 s or 0.05 s and check whether the run completes. The output time interval (for example 600 s) is independent of dt and does not affect stability. If the run still fails at the very first step, also check the inflow settings and initial water depth, since a very high velocity at the inflow cell can violate the condition even with a small dt.

Nays2DFlood can be used for low-flow conditions, and it is sometimes chosen instead of Nays2DH when tributary inflows need to be added. If the results for low flow are not satisfactory, the suggested step is to reduce the calculation grid size so that the low-water channel is resolved. Remember to reduce the calculation time step at the same time so that the CFL condition is still satisfied.

Nays2DH and Nays2DFlood handle elevation in three stages, which is why the value at the same node changes:

1. During attribute mapping, the elevation is assigned to the grid points (nodes).
2. During the calculation, the solver works with cell-centre values, i.e. the average of the four surrounding grid points.
3. When results are output, the value at each grid point is the average of the four surrounding cell-centre values.

So the output Elevation is a smoothed version of the input, and the difference is larger where the terrain is steep or the grid is coarse. For calibration against an observed gauge, compare the observed level with the output WaterSurfaceElevation, which corresponds to the output Elevation plus Depth at that node, rather than with the pre-processing elevation. Using the original input elevation plus the calculated depth as an estimate of the water surface is something that has been suggested, but it has not been confirmed as an exact relation, so treat it as an approximation.

A common cause is that part of the grid lies outside the area covered by the elevation (DEM) point data. Where the grid has no elevation data, attribute mapping becomes extremely slow. To check, select the point-set data in the object browser and switch Display Setting from Points to Surface; any part of the grid not covered by the surface has no data. To fix it, add a few extra points with a high elevation around the domain so that the whole grid area is covered (Add New Point in the point-set data menu), then run Remesh TINs before generating the grid and mapping again. With full coverage the mapping is much faster.

Very likely. A coarse DEM (for example 12.5 m or 30 m resolution) often does not represent the channel, and a DEM from LiDAR or satellite does not include the riverbed below the water surface at all. As a result the model may see no continuous channel downstream. Suggested steps:

• Combine bathymetry (surveyed cross sections) with the DEM so that the channel below the water surface is represented; without bathymetry an accurate simulation is difficult.
• Use a finer DEM if one is available (5 m or better).
• Reduce the calculation grid size so that the channel is resolved; a grid of a few hundred metres per cell cannot represent a river channel.
• As a test, increase the discharge to see whether the downstream reach is reached at all.

Both are options for the advection term. The CIP (Constrained Interpolation Profile) method calculates advection more accurately, while the upwind scheme is more robust and less likely to cause a calculation failure. If a run with CIP diverges, switching to upwind is a common first trial. The theoretical background of these numerical schemes is covered by iRIC Academy.

Discharge at an arbitrary location cannot be displayed directly in iRIC; the graph window only offers node values such as depth, water surface elevation and velocity, plus the inflow you specified. The workaround is to use File > Export > Calculation result (CSV) to export the results, then compute the discharge yourself in a spreadsheet by summing depth × velocity × cell width across the cells of the cross section you are interested in.

Two settings are the usual suspects:

1. Inflow polygon: the polygon drawn for the inflow boundary condition must cover at least one grid node. If it covers none, no water enters and the run ends immediately.
2. Time units: the time unit of the discharge setting and the time column of the inflow discharge time series must match. If Time unit of discharge is set to second, the inflow time series must also be given in seconds (and likewise for other units).

After correcting these, re-map the boundary conditions and run again.

One likely cause is specifying the inflow on a single grid cell. Concentrating the whole discharge on one cell produces a very large velocity at t = 0 (especially on a dry bed), which violates the CFL condition even with small time steps such as 0.01 s on a 2 m grid. Draw the inflow polygon so that it covers a reasonable number of nodes across the channel (around 10 or more is a common practice). Also check the initial conditions and depth at the inflow. If a project that previously ran now fails without any changes, the CGNS project file may have become corrupted; re-creating the project from the same data is a possible workaround.

The failure may be related to the minimum water depth used in the calculation. If the first discharge in the time series is 0 m³/s, the initial water depth is very small, which can lead to failure when the discharge later rises sharply. Two approaches are suggested:

• Give a non-zero initial discharge (for example a few hundred m³/s) at the start of the time series so that the channel is wet.
• Before running the full hydrograph, run a constant-discharge case at the peak value and find a calculation time step that is stable; then use that time step for the time series.

There is no single setting for this. Possible factors include riverbed deformation, the roughness coefficient, the downstream water level condition, drainage through small channels not represented in the grid, and seepage. Which one dominates depends on the site, so the recommended approach is to compare the simulation with the actual conditions of the river and test the candidate causes one by one rather than only tuning the floodplain roughness. The background on how these factors affect flood recession is covered by iRIC Academy.

Yes, using two functions:

• In the pre-processing window, use the Create mode of the river survey data to define cross-section lines at the interval you want (see the GUI user manual, river survey data).
• Then use the result-extraction tool for arbitrary cross sections that is published on the iRIC website (software downloads) to extract the calculation result, including maximum depth, along those lines.

The most probable reason is that Depth(max) is being displayed instead of Depth. Depth(max) is the maximum value over the whole run, so it never decreases; switch the scalar to Depth in the 2D post-processing window to see the actual recession. Another possibility is backwater from the downstream boundary: if the downstream water level condition stays high, the flooded area cannot drain. Check the water level at the downstream end over time.

This message appears whenever the selected inflow region includes any cell or node that is not on the grid boundary, even if boundary cells are also included. Zoom in and re-check the inflow polygon: it must cover boundary nodes only. If the region seems correct, redraw it slightly smaller so that it clearly excludes interior cells, and re-map the boundary condition before running. This is the usual cause, but not every case has been confirmed to be resolved by it.

Use Nays2DFlood for the flood analysis. The solver does not output the volume directly, so after the run export the results with File > Export > Calculation result (CSV) and compute the volume in a spreadsheet as the sum of depth × cell area over the cells of the basin (cell area from the grid spacing or the exported coordinates) at the time step of interest.

Nays2DFlood is not downloaded separately; it is distributed as part of iRIC. Download and run the iRIC installer from the official iRIC website, and Nays2DFlood is normally installed together with iRIC (unless you changed the component selection during setup).

If iRIC is already installed but Nays2DFlood does not appear in the solver list, add it with the iRIC maintenance tool (the maintenance/updater program installed with iRIC):

1. Launch the maintenance tool from the iRIC installation folder or the Start menu.
2. Choose the option to add or update components.
3. Tick Nays2DFlood (and any other solvers you need) and proceed.

After the tool finishes, restart iRIC and create a new project; Nays2DFlood should now be selectable as the solver.

Currently this is not possible. In the Edit Simple Operation Results window, the only values that can be referenced in the JavaScript expression are the calculation result values themselves (for example depth, velocity, or elevation). Grid node indices (I, J) and node coordinates (X, Y) are not exposed as variables, so an expression cannot depend on a node's position.

As a workaround, if you need a position-dependent quantity, consider preparing it as a grid attribute or a result value before the calculation, or exporting the results (e.g. to CSV) and post-processing them outside iRIC.

If the run blows up immediately regardless of time step, the problem is usually in the grid rather than the numerical settings. One cause identified on the forum concerns grids built with "Create grid from cross-section data" from a .riv file:

• In that grid generator, the positions of index 2 and index 3 in the .riv file are automatically used as division points.
• If you imported the file with the centerline option "Where the elevation is smallest in low water way" and index 2 happens to be the lowest point, the river centerline and a division point coincide. This produces extremely narrow cells of almost zero width, which makes the calculation diverge.

To fix it, move the river centerline to the correct position in the cross-section data editor (see the user manual section on shifting the centerline of river survey data), then reset the grid creating condition and re-add the division points. The .riv file format is described in the user manual under "Cross-section file (riv)".

As a general rule, if the calculation diverges, enlarging the mesh size or reducing the time step also helps; see the FAQ on the iRIC website.