Frequently Asked Questions

About this site

About installing Delft3D software

About compiling the open source code

About running a calculation

About code changes

Version number information

__________________________________________________________________________________________________________________________________________________________________

 

 

Frequently Asked Questions about this site

Frequently Asked Questions about installing Delft3D software

 

Frequently Asked Questions about compiling the open source code

Do I really need exactly the named compiler/developer tools?

Well, that's what we use. You can try others if you want.
The official binaries are currently built using VS2015 and Intel 16

On Linux, should I use "build.sh" to compile or not?

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 PATH accordingly export PATH=~/.local/bin:$PATH

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.

On Linux the file "logs/autoreconf.log" reads "/build.sh: line 129: autoreconf: command not found"

The GNU Autoconf environment is not installed. See "Prerequisites Linux" on 4. Compile the source code.

On Linux problems with mpich

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.

On Linux in WAVE: undefined reference to `small_' (and much more)

Try installing the X11 development tools.

On Linux, I keep getting odd compile/link errors

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:
...\src\engines_gpl\flow2d3d\packages\flow2d3d\flow2d3d.vcxproj
...\src\engines_gpl\flow2d3d\packages\flow2d3d_openda\flow2d3d_openda.vcproj
...\src\engines_gpl\part\packages\delpar\delpar.vfproj
...\src\engines_gpl\waq\packages\delwaq1\delwaq1.vfproj
...\src\engines_gpl\waq\packages\delwaq2\delwaq2.vfproj
...\src\engines_gpl\waq\packages\delwaq2_lib\delwaq2_lib.vfproj
...\src\engines_gpl\waq\packages\delwaq2_openda_lib\delwaq2_openda_lib.vfproj
...\src\engines_gpl\wave\packages\wave\wave_vs2010.vfproj
...\src\tools_gpl\datsel\packages\datsel\datsel.vcproj
...\src\tools_gpl\kubint\packages\kubint\kubint.vcproj
...\src\tools_gpl\lint\packages\lint\lint.vcproj
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.

 

On Windows, problems with compiling "tools_gpl\vs"

"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.

How do I create a single precision executable?

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.

How do I create a 64-bit executable?

On Linux

Delft3D is 64-bit. Check file "src/README" for compile instructions. There is a known bug on using the 32-bit version.

On Windows

Delft3D is 64-bit by default. Compiling and running a 32-bit version is possible.

 

__________________________________________________________________________________________________________________________________________________________________

Frequently Asked Questions about running a calculation (Delft3D-FLOW and/or Delft3D-WAVE)

The example testcases don't run because the needed executables are missing

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.

The example testcases don't run with 64 bit executables

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.

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

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.

On Windows, the message "The program can't start because MSVCP110.dll is missing" appears

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.

On Linux, the message "ERROR: Can not open shared library "libflow2d3d.so"" appears

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

	     ldd libflow2d3d.so

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

On Linux, the message "ERROR: unexpected PLT reloc type 0x25" appears

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.

Errors when running FLOW with WAVE online

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:

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.

Parallel FLOW calculation crashes during initialization with the message "Cannot create URL file".

This is a known bug. See release notes version 6.01.04.3058.

Why do the newly compiled exe/dyn_libs not work with the 2010 distribution/setup of Delft3D?

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 message "ERROR in real array allocation" appears

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:

[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /NoExecute=AllwaysOff /PAE /3GB

How do I run a single precision executable?

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

<library>flow2d3d</library>

by

<library>flow2d3d_sp</library>

 

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

by

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.

When running SWAN via Delft3D-WAVE, how can I control the number of parallel processes started?

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:

Windows:
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":
set OMP_NUM_THREADS=1
Linux:
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 "#":
export OMP_NUM_THREADS=1
Remarks:
- 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.

How do I run a calculation in parallel?

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.

Remarks:
- 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.

When running in parallel: what is the optimum number of partitions(ONP)?

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.

__________________________________________________________________________________________________________________________________________________________________

Frequently Asked Questions about code changes

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 delft3d.support@deltares.nl with the request to merge it in the trunk.

Can I get my own branch to work in?

Yes you can. Please sent a mail to the  web master.

What documentation is available for programmers?

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 information

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".
Example:
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".

 

Why are some tagged versions named only with their revision number?

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.