FAQ - Delft3D
Frequently Asked Questions
if you want to download the sourcecode: yes
If you want to participate in this community: yes
- Is it possible to have two versions of Delft3D installed on my machine, next to each other?
- Uninstalling DS_Flex version 184.108.40.206 or older does not work on Windows 10
The advise is to have only one Delft3D version installed on a machine. If you install a second one, the first one will be moved to a directory with a name like "C:\Delft3D_backup\w32". If you use Delft3D, the second installation will always be used. There are two ways to use the first installation:1. Redefine environment parameter "D3D_HOME". It will have a value like "C:\Delft3D" and you have to change that into something like "C:\Delft3D_backup". 2. Use self written scripts to start the Delft3D executables and refer to executables in "C:\Delft3D_backup". If you have two versions installed and you run a simulation, please check in the output that the expected version is used.
The advise is to have only one Delft3D version installed on a machine. If you want to install a second one, you have to unpack the rpm and install it locally. See the installation manual. To use the locally installed version, you have to write your own scripts.
To uninstall the old DS_Flex on Windows 10, some manual actions are needed:
On 64-Bits windows:
1. Remove directory: C:\Program Files (x86)\DS_Flex
2. Remove from Registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\WL | Delft Hydraulics\DS_Flex
On 32-Bits windows:
1. Remove directory: C:\Program Files\DS_Flex
2. Remove from Registry:
HKEY_LOCAL_MACHINE\SOFTWARE\WL | Delft Hydraulics\DS_Flex
Then everything is clean and you can install the latest DS_Flex.
- Do I really need exactly the named compiler/developer tools?
- On Linux, should I use "build.sh" to compile or not?
- On Linux, I do not have the latest or mentioned version of autoconf/libtool/automake/mpi on my system, what should I do now?
- On Linux I get the error message "cannot access './third_party_lgpl/version_number/bin/linux/version_number.exe': No such file or directory"
- On Linux the file "logs/autoreconf.log" reads "/build.sh: line 129: autoreconf: command not found"
- On Linux problems with mpich
- On Linux in WAVE: undefined reference to `small_' (and much more)
- On Linux, I keep getting odd compile/link errors
- On Windows, I get the error message "the project (.vfproj) is not compatible with your Visual Studio version".
- On Windows, I have problems related to warnings/error messages like "C:\Program Files\MSBuild\Microsoft.Cpp\Microsoft.CppBuild.targets(990,5): warning MSB8012"
- On Windows compilation of some projects fail with the message "LINK : fatal error LNK1104: cannot open file 'ifconsol.lib' (or 'libifcoremt.lib', ...)"
- On Windows, problems with compiling "tools_gpl\vs"
- How do I create a single precision executable?
- How do I create a 64-bit executable?
Well, that's what we use. You can try others if you want.
The official binaries are currently built using VS2015 and Intel 16
There are two ways to compile on Linux (see "src/README"):
1) Execute "autogen", "configure" and "make" with the correct flags (see "src/README)".
Use this method when all used tools (automake, libtool, mpich, etc.) are installed on their default location.
2) Use the script "build.sh". In this script you have to specify paths to tools explicitly.
Use this method when some tools can not be found by default. Start by editing "build.sh" to have it pointing to the correct tools on your system.
On Linux, I do not have the latest or mentioned version of autoconf/libtool/automake/mpi on my system, what should I do now?
Check if you have the latest version provided by your package management system (yum, dpkg, apt, port). You can sometimes find a more up to date version in one of the community repositories, such as EPEL. If the package is not provided by your package management you can install the software manually into either your personal directory (/home), the directory for additionally installed software (/usr/local) or for external software (/opt). To do this you often need to configure that specific package using a prefix (
./configure --prefix=/home/user/.local) and to set the
On Linux I get the error message "cannot access './third_party_lgpl/version_number/bin/linux/version_number.exe': No such file or directory"
That message is produced by the script "build.sh" itself (line 115). You can replace "third_party_lgpl" by "third_party_open" and the message will disappear. This is solved in revision 82.
The GNU Autoconf environment is not installed. See "Prerequisites Linux" on 4. Compile the source code.
One of the prerequisites for compiling on Linux is that mpich is properly installed. This means that you have to download the mpich source code and compile it with exactly the same compiler as you intent to use for the Delft3D source code. After having compiled it using the default mpich directory, you can compile the Delft3D source code by executing "autogen", "configure" and "make", see 4. Compile the source code. If you don't use the default mpich directory, the easiest way to compile the Delft3D source code is by using the script "build.sh": open it in a text editor, search for mpich and fill in the correct paths as used on your local machine.
Currently, if mpich is not properly installed:
- the make log may contain an error message like:
"dfinitmpi.f90(48): error #7002: Error in opening the compiled module file. Check INCLUDE paths."
- the make log may contain an error message like:
"undefined symbol: mpi_"
- Delft3D-FLOW may compile without problems but does not run in parallel. The safest way to check whether Delft3D-FLOW is build with a proper mpich version: check the make log; the link step should contain something like "-L/path/to/mpich/compiled/with/same/compiler/lib -lfmpich -lmpich".
- the make log may contain an error message like:
relocation R_X86_64_32 against `MPIR_ThreadInfo' can not be used when making a shared object; recompile with -fPIC
If this error appears, your MPICH version is too old. Switching to MPICH version 3.1.2 or newer should solve the problem.
Try installing the X11 development tools.
Your environment settings may hamper the build process. Have a colleague building the source code or try with an empty/clean (virtual) environment.
On Windows, I get the error message "the project (.vfproj) is not compatible with your Visual Studio version"
Probably the Fortran compiler is missing.
When you install the Intel Fortran compiler, it will cooperate with Visual Studio: Visual Studio will recognize the .vfproj projects as being Fortran projects and will activate the Fortran compiler automatically.
On Windows, I have problems related to warnings/error messages like "C:\Program Files\MSBuild\Microsoft.Cpp\Microsoft.CppBuild.targets(990,5): warning MSB8012"
These messages are generated by MSBuild: a Microsoft plugin of VisualStudio. The Delft3D source code can not be compiled when using MSBuild. You have to disable/remove it in VisualStudio.
MSBuild seems to be added recently to the trial version of VisualStudio.
On Windows compilation of some projects fail with the message "LINK : fatal error LNK1104: cannot open file 'ifconsol.lib' (or 'libifcoremt.lib', ...)"
These projects contain a main subroutine written in C. When linking them, the linker needs the path to the fortran runtime libraries. This directory is specified explicitly in the properties of the related project. This path differs for each version of the Intel compiler. It may be necessary to adapt this property as follows (assuming that you use "d_hydro_open_source_vs2010.sln", optionally upgraded by VisualStudio to VS20xx):
1. Find out what the name of the environment parameter is pointing to the Intel compiler installation directory. As an example, for Intel 13 this is IFORT_COMPILER13
2. Search for the string "IFORT_COMPILER12" in the following files:
3. Replace all occurences of the string "IFORT_COMPILER12" in the files above by the correct name on your system, for example "IFORT_COMPILER13".
4. Compile again
Remark: NetCDF support on output files is introduced in revision 4649. This complicates the compilation as follows:
1. You have to be sure that the NetCDF libraries are available, compiled with exactly the same compiler as you use for Delft3D. Check directory "...\src\third_party_open\netcdf\lib\win32\Release" for the available precompiled NetCDF versions.
2. You have to change "...\src\engines_gpl\flow2d3d\packages\flow2d3d\flow2d3d.vcxproj", such that it points to the correct version of the precompiled NetCDF libraries.
"vs" is a small tool that can be used to inspect nefis files. Most probably, you will not use it. You can ignore compilation problems related to "vs".
In case you do want to solve these compilation problems: When downloading the source code, two binaries are included called "Lex" and "Yacc", see sub-directory "...\src\third_party_open\lexyacc\bin\win32". These are used to convert *.l and *.y source code files in the "vs" project into C-code. Intermediate files are placed in directory "tmp" on the current drive. The "vs" project tries to create this directory.
Most problems are related to compiling on the C-drive, without having administrator rights. This might result in errors due to missing permissions to create directory "C:/tmp". There are two ways to solve this problem:
- Checkout the Delft3D source code on the D-drive, where all users have write-permission
- With help of your system administrator: Arrange directory "C:\tmp" with you having write permission in there.
Go to directory "src/utils_lgpl/precision/scripts",
Linux: execute "./changeprecision.tcl single",
Windows: double click "singleprecision.bat",
Recompile the complete tree. This will result in "flow2d3d_sp.dll" (Windows) or "libflow2d3d_sp.so" (Linux) respectively.
Delft3D is 64-bit. Check file "src/README" for compile instructions. There is a known bug on using the 32-bit version.
Delft3D is 64-bit by default. Compiling and running a 32-bit version is possible.
- The example testcases don't run because the needed executables are missing
- The example testcases don't run with 64 bit executables
- On Windows, the message 'Cannot load component library "flow2d3d.dll"' appears
- On Windows, the message 'ERROR: child killed: unknown signal' appears
- On Windows, my single domain parallel run crashes after a few days of calculation
- On Windows, the message 'couldn't read file ".../create_config_xmlt.tcl": no such file or directory' appears
- On Windows, the message "The program can't start because MSVCP110.dll is missing" appears
- On Linux, the message "ERROR: Can not open shared library "libflow2d3d.so"" appears
- On Linux, the message "ERROR: unexpected PLT reloc type 0x25" appears
- Errors when running FLOW with WAVE online
- When running FLOW via Delft3D-menu, the computation hangs just before starting the calculation
- Parallel FLOW calculation crashes during initialization with the message "Cannot create URL file".
- Why do the newly compiled exe/dyn_libs not work with the 2010 distribution/setup of Delft3D?
- The message "ERROR in real array allocation" appears
- How do I run a single precision executable?
- When running SWAN via Delft3D-WAVE, how can I control the number of parallel processes started?
- How do I run a calculation in parallel?
- When running in parallel: what is the optimum number of cores?
That's correct, you have to build the executables yourself. If you do not build the executables yourself then the Delft3D user interface will show the message that the executable "d_hydro.exe" could not be found.
Please compile the executables as described at 4. Compile the source code and follow the instruction at 5. Run a calculation to get the simulation running with the free open source code. Use a service package if you want to obtain a fully tested set of binaries.
That's correct, currently building 64 bit executables is possible. And if you are lucky, a simple testcase will run fine. But there are still problems with running 64 bit cases. That's why we can not deliver fully tested 64 bit executables at this moment. We are looking at these problems with low priority. Please feel free to participate in this topic.
D3D_HOMEdefines the root of the Delft3D installation:
Exediris supposed to contain the executables and the dlls, resulting from the compilation of (in this case) the flow2d3d source code.
Libdiris supposed to contain the dlls, specific for the operating system you work on (Windows) and the compiler used (Intel). Both directories must be added to environment parameter
D3D_HOME, exedir, libdir, PATH) is not correctly defined.
deltares_hydro.exe" is actually a (temporary) script starting the real executable "
d_hydro.exe". Starting "
d_hydro.exe" directly may give more information. To do this:
%exedir%\deltares_hydro.exe %argfile% -keepXML
deltares_hydro.exe" will leave the input file for "
d_hydro.exe" in the working directory. It will have a name like "
%exedir%\deltares_hydro.exe %argfile% -keepXML
PATH. What you have to do depends on what dll is missing and what caused this error to appear. It may help to have a look at the script that builds the install directory:
On Windows, the message 'couldn't read file ".../create_config_xmlt.tcl": no such file or directory' appears
The file "create_config_xml.tcl" is inside the source code. If you compile the (release version of the) source code, a directory named "<mysourcecodelocation>\bin\win32" will be created, containing also the file "<mysourcecodelocation>\bin\win32\menu\bin\create_config_xml.tcl". If you want to use the Deflt3D-GUI (version 4.01.00 or higher), you have to copy the full contents of "<mysourcecodelocation>\bin\win32" on top of the Delft3D installation directory (default directory "c:\Program Files (x86)\Deltares\Delft3D <versionnumber>\win32"), including the tcl file in the correct subdirectory. See also running a calculation.
This error might appear when you compile Delft3D on a machine (named A) using Microsoft Visual C++ 2010 and try to run the executables on another machine (named B), not containing that C++ version. The easiest solution is to install the related redistributable on machine (B). Download links to both the 32-bit and the 64-bit version are at the middle of this Microsoft page.
This means that when trying to run libflow2d3d.so, another so-file is needed and can not be found. If you execute the Linux command
you will get an overview of all so-files needed and whether the system can find their location. Probably some of the so-files can not be found on your system. This is signalled as follows by the ldd command
libDelftOnline.so => not found
You can solve that problem by locating them (libDelftOnline.so in the example) on your system and adding their path to the environment parameter LD_LIBRARY_PATH. You can do this in the runscript "examples\01_standard\run_flow2d3d.sh". Example lines to add, assuming "libDleftOnline.so" is in directory "/oss_delft3d/src/lib":
libdir=/oss_delft3d/src/lib export LD_LIBRARY_PATH=$libdir:$LD_LIBRARY_PATH
This message may appear when Delft3D is built on a machine with a newer Linux kernel, and then the resulting binaries are copied to a machine with an older Linux kernel. There is no solution yet for this problem. You have to avoid this error by compiling it on a machine with an older kernel or run it on a machine with a newer kernel.
The data exchange between FLOW and WAVE is via the nefis file "com-<runid>.dat". The synchronisation is handled via an internal module named "DelftIO", steered via file "dioconfig.ini" (must be present in the working directory). Everytime that FLOW writes data to the com-file, a WAVE calculation is started at that time step.
The communication between FLOW and WAVE is sensitive. In case of problems:
1. Check that a file named "dioconfig.ini" is present in the working directory. Here is an ready-to-use example.
2. Keep the working directory as clean as possible. Remove output files and temporary files before a new run, especially files named "com-*" and "WAVE2FLOW*".
3. The switch from FLOW to WAVE and vice versa is slow. You may speed this up by opening the dioconfig.ini file in a text editor and replace the top three lines:
by something like:
But you have to be careful with this: the com-file must be accessible for the other program. This may take a while, especially when the working directory is on an external network drive.
This may be caused by RemoteOLV being switched on by default. As a workaround, switch it off as follows:
In the Delft3D-FLOW UserInterface, open the mdf-file you want to run. Go to the "Output" definitions. Disable "Online visualisation" in the lower right corner of the window.
The behaviour is being improved at this moment; Delft3D-FLOW will report that it is waiting for the RemoteOLV to attach and it will be switched off by default.
This is a known bug. See release notes version 6.01.04.3058.
Some Intel related runtime dynamic libraries must be updated.
The start method has been changed (deltares_hydro.exe instead of delftflow.exe, config.ini file instead of commandline arguments on one line in an input file).
The model is too big to fit in the memory of your machine. This can be checked by looking to the memory usage in the TaskManager (Windows) or by using the "top" command (Linux) while starting a calculation.
There are two restrictions to memory usage:
1. A 32bit executable can not use more than about 3 Gb of RAM memory. By default, Delft3D-FLOW on Windows and on Linux is 64bit.
2. The amount of memory used is limited by the amount of RAM memory in your machine.
There are four options to solve this problem:
1. Simplify your model; decrease the number of cells in a dimension, or the number of processes/constituents.
2. Use the single precision executable.
3. Run the calculation in parallel using MPI.
4. Windows XP/Vista and 32bit only: by default, a 32bit executable can not use more than 2 Gb of RAM memory. This can be increased to about 3 Gb as follows:
Add the flags /PAE /3GB to file "c:\boot.ini". Example lines:
Windows XP Professional" /fastdetect /NoExecute=AllwaysOff /PAE /3GB
When using a script:
Be sure that the single precision dynamic library is located in the same directory as the double precision version. On Windows the (default) double precision dll is named "flow2d3d.dll" and the (optional) single precision dll is named "flow2d3d_sp.dll". On Linux these names are "libflow2d3d.so" and "libflow2d3d_sp.so" respectively.
Edit the "config_d_hydro.xml" file in your testcase directory as follows:
Replace the line
When using an older Delft3D-FLOW version (4.xx or 5.xx), the "config_flow2d3d.ini" file must be changed in a comparable way:
Replace the line
Name = flow2d3d
Name = flow2d3d_sp
When using the Windows GUI:
The GUI does not support "Name = flow2d3d_sp" in the config file. The only way to do a single precision calculation is by renaming "flow2d3d_sp.dll" into "flow2d3d.dll".
In case of doubt, check in the tri-diag file whether the calculation was indeed single precision:
*** MESSAGE Single precision computation using reals of kind 4
or double precision:
*** MESSAGE Double precision computation using reals of kind 8
WARNING: Results may differ when switching from double to single precision. The differences depend on the sensitivity of the model.
By default, Delft3D-WAVE uses the OpenMP version of SWAN. This means that SWAN will run in parallel, using (by default) as many partitions/processes as there are cores/CPUs on the local system. To change this default, explicitly specify the number of threads to start in the swan batch file:
The batch file is named "swan.bat" and is located in subdirectory "win32\swan\scripts" in the Delft3D installation directory (default: "c:\Program Files (x86)\Deltares\Delft3D <versionnumber>"). Line 8 reads:
rem set OMP_NUM_THREADS=1
The "rem" at the front of the line ensures that this line is disabled. To ENable it, you have to remove the "rem":
The batch file is named "swan.sh" and is located in subdirectory "lnx64/swan/scripts" in the Delft3D installation directory (default: "/opt/delft3d"). Line 70 reads:
# export OMP_NUM_THREADS=1
The "#" at the front of the line ensures that this line is disabled. To ENable it, you have to remove the "#":
- The number, one in the examples above, can be replaced by any number.
- In case the method above "does not work": the most common problem is that Delft3D-WAVE uses another swan batch script on your system. Delft3D-WAVE uses environment parameter PATH to search for it and uses the first one found. You can check whether the changed batch script is being used by adding a write statement that should appear in the screen output.
There are two ways to use multiple cores and/or multiple machines for a calculation:
1) When DomainDecomposition is used to create the model, the subdomains will be spread automatically over the available cores in the machine by the operating system.
2) Single domain models can be spread over several cores/machines using MPI.
- Method 1) uses several cores on one machine by default (Windows and Linux).
- Method 1) using several machines is not working properly. This is a known bug.
- Method 1) and method 2) can not be combined in one calculation.
- Method 2) is implemented for both Linux and Windows. But on Windows it can not be used to spread over several machines but only to spread over several cores on the (local) machine.
- Method 2) does not work in combination with some functionalities, e.g. non-hydrostatic. See file "https://svn.oss.deltares.nl/repos/delft3d/trunk/src/engines_gpl/flow2d3d/doc/parallel_status.txt" for a detailed description of the current status.
- Recently added: Method 2) does work with WAVE-online. On Linux it also works using more than one machine/node, both by FLOW and SWAN. But you have to be sure that all data is written in one directory.
- Method 2) calculations can not be started using the Delft3D-MENU Graphical User Interface. Example scripts to start a parallel calculation are included when downloading the source code, see "...\examples\01_standard".
- When running SWAN via Delft3D-WAVE: by default, the OpenMP version of SWAN is used, using all cores of the local machine in parallel. This can be changed by editing the "swan.bat/swan.sh" file used. See the example scripts in directory "https://svn.oss.deltares.nl/repos/delft3d/trunk/src/third_party_open/swan/scripts"
- When running Delft3D-FLOW with Delft3D-WAVE online: it is useless to have FLOW running on one core and WAVE on another: they run in serial, alternating.
WARNING: Results may differ when switching to a parallel computation. The differences depend on the sensitivity of the model.
This depends on a lot of factors:
1. The size and shape of your model area
For small models, ONP is lower.
When mmax is more or less equal to nmax, ONP is lower.
2. The amount of processes switched on for your model (salinity, sediment transport, morphology, 3D, etc.)
For 2D, ONP is lower.
When having only a few processes, ONP is lower.
3. Disk I/O
4. RAM memory size
5. Communication speed between partitions
In general, the communication between Delft3D-FLOW partitions is relatively intensive, regarding both the number of exchange moments and the amount of data being exchanged. As a result, ONP might be lower than expected.
- How can I commit code changes?
- Can I get my own branch to work in?
- What documentation is available for programmers?
If you have the right to commit changes yourself (for example in your own branch) you can use SVN or TortoiseSVN to commit the changes directly. If you don't have the right to commit, use SVN or TortoiseSVN to create a patch containing your changes. This will result in a file you can sent to email@example.com with the request to merge it in the trunk.
Yes you can. Please sent a mail to the web master.
Doxygen is used as documentation tool for the source code. It's rather new to us and not complete, but at least the API and the structure will become clear.
You can download and install Doxygen yourself (see www.doxygen.org) and use the config file "src\doxyfile_delft3d" to generate the documentation.
Version number info
Delft3D is a suite containing several engines (Delft3D-FLOW, DELWAQ, Delft3D-WAVE, etc.), GUIs (for each engine) and tools (QuickPlot, RGFGRID, QUICKIN, etc.). Each component has its own version number. The complete Delft3D suite also has its own version number. With the "Delft3D version number" is normally meant the "Delft3D suite version number".
Delft3D version 4.01.00.rc.09 contains (among others):
- RGFGRID version 4.20.00.30984
- Delft3D-FLOW version 6.01.04.3058
- Delft3D-WAVE-GUI version 4.94.01.15654
All version numbers consist of 4 integers, separated by dots, e.g. 1.02.03.0004. Except the Delft3D suite itself which consists of 3 integers, e.g. 1.02.03. An additional string can be attached, e.g. 1.02.03.0004.rc.09. Description:
- If the first integer is increased then the related component is not backwards compatible.
Recently, the Delft3D-FLOW version number increased from 5.xx.xx.xxxx to 6.xx.xx.xxxx. The 5-version needs an input file in ini-format, the 6-version in xml-format. See the release notes for more details.
- The second integer denotes major changes, normally new functionality has been added.
- The third integer denotes minor changes, bug fixes.
- The fourth integer is a unique reference (revision number in the repository) to the version of the source code used to built this specific component version.
- A string is attached when it's not standard official release. "rc" means "release candidate".
Up to February 2013, Delft3D-FLOW was the only main kernel in the open source code (Delft3D-WAVE is just a shield around SWAN) and the tags are named using the full Delft3D-FLOW version number. Starting from March 2013, the DELWAQ source code was added with it's own different version number. The only similar part is the revision number. Since then, the tag names only contain the revision number. All tagged versions are fully tested.