Frequently asked questions

iRIC is distributed for Windows only. Windows 10 has been confirmed to work well, and the project has stated that a Linux build is not available. If you need to run iRIC on another operating system, you would have to use a Windows machine or a Windows virtual machine.

The internet background image is fetched from Google Maps, and it will not appear unless a valid Google Maps API key has been registered in iRIC. The steps are:

1. Obtain an API key from the Google Maps Platform (your own Google account is needed).
2. In the iRIC GUI open the Preferences dialog (Option menu) and enter the API key in the corresponding field.

After the key is registered, the online map should load as the background image. The exact location of the field is described in the Preferences section of the iRIC GUI user manual.

iRIC is updated with the built-in maintenance tool: choose Option > Maintenance in the iRIC menu bar, click Close iRIC and launch iRIC Maintenance, then follow the Next buttons to see the update information and start the update.

If iRIC closes but the maintenance window does not show up, try starting the tool directly from the installation folder: %userprofile%\iric\maintenancetool.exe (paste this path into the Windows Explorer address bar or the Run dialog). This workaround does not resolve every case; if it still fails, reinstalling from the latest installer on the iRIC website is the remaining option.

MeanderJP is not bundled with the iRIC 2, 3 or 4 installers. It was distributed by a third party through a separate website (meanderjpiric.wordpress.com, page Solver and Grid Generator), and the solver files had to be copied manually into the solvers folder of the iRIC installation. The code was never updated for newer iRIC releases, so it only works with iRIC 2.x (for example 2.0 or 2.3), not with iRIC 3 or 4. Note that recent reports say the files can no longer be found on that site, so the solver may effectively be unavailable now.

Nays2DH cannot handle tidal flow: it is a single-layer, depth-averaged model for a fluid of a single density, so salt-water intrusion or stratified tidal flow cannot be represented. If the phenomenon of interest is a vertical two-dimensional flow such as a salt wedge, Nays2DV is the solver to consider. The theoretical background of these models is covered by iRIC Academy.

Nays2DH and Nays2DFlood support multi-threaded computation on a multi-core PC. Open the calculation condition dialog (Calculation Condition > Setting), go to the Others group and set Number of threads for parallel computation (Only multi core PC) to the number of cores you want to use. GPU (GPGPU) acceleration is not offered as a setting, and the availability of parallel computation in other solvers depends on each solver.

The upstream side is defined by the bed elevation of the grid, not by a separate flag. When a straight channel grid is created with the grid generator, the bed slope you enter fixes which end is higher (upstream). When the grid is built from imported river cross sections, the slope and elevations come from the cross-section data. To check the result, open the Bird's-eye view of the grid and display the bed elevation as a contour; the flow enters at the higher end. Note that this is one interpretation of the question given in the thread.

A crash on re-running a simulation that uses cg_iric_write_sol_particle was a bug in the iRIClib / iRIC GUI release of May 2020 (2020.05.22). It was fixed in the following release, so updating iRIC resolves it: choose Option > Maintenance in the iRIC GUI and apply the update. A separate problem with cg_iric_write_sol_particlegroup (only final particle positions shown with NaN scalar values) was acknowledged but no fix was described in the thread, so it may or may not be resolved in later versions.

The standard solvers do not include dam-breach erosion, but a modified version of Nays2DH for breach simulation has been published and may cover this kind of problem, depending on what you want to obtain from the simulation. It can be downloaded from the CERI website (http://river.ceri.go.jp/contents/tool/nays2d-breach.html). Be aware that all documentation for that modified solver is available in Japanese only.

This display problem is caused by the graphics driver, and there are two things to try:

1. If the PC has a dedicated graphics card, open Windows Graphics Settings, add iRIC under Apps and explicitly set it to use the high-performance graphics card. Since Windows 10 version H1, Windows chooses the GPU per application, and by default iRIC may be running on the integrated GPU.
2. If there is no dedicated card, the pink lines indicate that the Intel integrated graphics driver is out of date; install the latest driver from the Intel website.

Reinstalling iRIC itself does not fix the issue.

There is no dedicated water quality module, but the UTT solver can be used for general advection and diffusion of a dissolved or suspended material, which covers many water quality problems. Its documentation, including a simple bend example, is available at https://i-ric.org/yasu/UTT_EN/03/02_Symple_Bend.html.

In the iRIC 4 installer, roughly 43 % is the point where all required files have been downloaded and the actual installation begins (when Miniconda is not selected). First check the detailed log in the installer window to see what it is doing, and wait a while. If it still does not proceed, the installation is possibly being blocked by folder access permissions or security software on the PC. Try the following:

• Temporarily disable your security (antivirus) software.
• Run the installer with administrator privileges.

A normal installation should not take hours; a stall of that length indicates that something is blocking it.

Nays2D+ itself is not provided as a Python-callable solver. If you want to drive a 2D flow simulation from Python, the suggested option is NaysMini, which is designed to be used with Python. Try NaysMini as the starting point for Python-based workflows.

In iRIC 4.x the resolution of exported images and videos follows the size of the visualization window, so a wide domain rendered in a small window looks coarse and blurry. Two things help:

1. Zoom in on the area of interest before exporting; the polygons are then drawn at a finer scale and the output is noticeably sharper.
2. Use the menu option that sets the size of the visualization window. The window can be made larger than the monitor's own resolution (you then navigate it with scroll bars), and the enlarged window is what gets exported, which effectively raises the pixel dimensions of the image or video.

There is no separate DPI setting; adjusting the window size is the intended way to obtain high-resolution output. A larger monitor (for example 4K) also gives sharper results by default.

A crash with no warning or message when opening projects or examples is most likely related to insufficient available memory, especially on a machine with only about 6 GB of RAM. Whether a given case runs depends on the model size and the grid resolution: larger domains and finer grids need considerably more memory and computation time. Possible ways forward are to close other applications to free RAM, try a smaller example or a coarser grid to confirm that memory is the issue, or use a machine with more RAM. This is a probable cause rather than a confirmed one, so if the problem persists with small cases, report the details of your environment on the forum.

This happens when Rivmaker.exe is launched directly from Explorer (for example <iRIC install folder>\guis\rivmaker\Rivmaker.exe); the executable cannot find sqlite3.dll and zlib.dll in its own folder. It is not caused by skipping the Miniconda installation. Two approaches work in iRIC 4.x:

1. Start RivMaker from inside iRIC: open iRIC v4 and choose Option -> Tools -> RivMaker. Launched this way it finds the DLLs and starts normally.
2. If you need to launch it directly, copy sqlite3.dll and zlib.dll from <iRIC install folder>\guis\prepost into <iRIC install folder>\guis\rivmaker, then run Rivmaker.exe again. Note that the DLLs must come from the guis\prepost folder; placing them only in the iRIC root folder does not help.

If the error persists after copying, uninstall iRIC v4, reinstall the latest version, and repeat the steps above.

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.