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.

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.

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.

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.

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.

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

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.

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

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.

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.

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

This means that when trying to run flow2d3d.dll, another dll is needed and can not be found. See the section above (the exact message may vary depending on your operating system).

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 means that when trying to run flow2d3d.dll, another dll is needed and can not be found.

First have a look at ...\examples\01_standard\run_flow2d3d.bat. D3D_HOME defines the root of the Delft3D installation:

set D3D_HOME=..\..\bin\win32

Dlls may be located in two directories: exedir and libdir:

set exedir=%D3D_HOME%\flow2d3d\bin
set libdir=%D3D_HOME%\flow2d3d\lib

Exedir is supposed to contain the executables and the dlls, resulting from the compilation of (in this case) the flow2d3d source code. Libdir is 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 PATH:

set PATH=%exedir%;%libdir%;%PATH%

The most common error is that one of these parameters (D3D_HOME, exedir, libdir, PATH) is not correctly defined.

If this does not help, find out what dll exactly can not be found. This information is not in the error message (since version 5.00) because "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:

1) In the run script, replace the line:

%exedir%\deltares_hydro.exe %argfile%

by:

%exedir%\deltares_hydro.exe %argfile% -keepXML

This will ensure that "deltares_hydro.exe" will leave the input file for "d_hydro.exe" in the working directory. It will have a name like "TMP_config_flow2d3d_3552.xml".

2) In the run script, replace the line:

%exedir%\deltares_hydro.exe %argfile% -keepXML

by:

%exedir%\d_hydro.exe TMP_config_flow2d3d_3552.xml

When using this run script, a message box will appear containing the name of the missing dll.

3) Try to locate the missing dll and be sure that it can be reached using environment parameter 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: ...\src\scripts_lgpl\win32\oss-install.cmd (section "INSTALL_FLOW2D3D").

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.

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

This may be caused by anti virus sofware on your machine. It has been noticed that a file can not be written by Delft3D-FLOW while being scanned on viruses. It only has been noticed while running in parallel mode using MPI.

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.

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.

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.