intro story D-Flow FM


D-Flow Flexible Mesh

D-Flow Flexible Mesh (D-Flow FM) is the new software engine for hydrodynamical simulations on unstructured grids in 1D-2D-3D. Together with the familiar curvilinear meshes from Delft3D 4, the unstructured grid can consist of triangles, pentagons (etc.) and 1D channel networks, all in one single mesh. It combines proven technology from the hydrodynamic engines of Delft3D 4 and SOBEK 2 and adds flexible administration, resulting in:

  • Easier 1D-2D-3D model coupling, intuitive setup of boundary conditions and meteorological forcings (amongst others).
  • More flexible 2D gridding in delta regions, river junctions, harbours, intertidal flats and more.
  • High performance by smart use of multicore architectures, and grid computing clusters.
An overview of the current developments can be found here.
The D-Flow FM - team would be delighted if you would participate in discussions on the generation of meshes, the specification of boundary conditions, the running of computations, and all kinds of other relevant topics. Feel free to share your smart questions and/or brilliant solutions! 


We have launched a new website (still under construction so expect continuous improvements) and a new forum dedicated to Delft3D Flexible Mesh.

Please follow this link to the new forum: 

Post your questions, issues, suggestions, difficulties related to our Delft3D Flexible Mesh Suite on the new forum.





Sub groups
D-Flow Flexible Mesh
Cohesive sediments & muddy systems


Message Boards

Coupled D3D-FLOW/WAVE: Wave spectra error in nested wave model

Ruairi MacIver, modified 5 Years ago.

Coupled D3D-FLOW/WAVE: Wave spectra error in nested wave model

Padawan Posts: 45 Join Date: 5/1/13 Recent Posts
I have a coupled FLOW/WAVE model: the FLOW model uses domain-decomposition to link two domains while the WAVE model consists of three nested domains (referred to as Coarse, Transition & Local). Coupling is achieved 'on-line'.

About 10 days into a 30-day simulation, the simulation failed at the point where the WAVE Local model was being initiated. The cause appears to be the occurence of a single '******' (six stars) as one of the elements of a spectrum contained in the boundary condition file (NEST003) being passed from the Transition model. This prevented the reading of the boundary conditions and caused the the WAVE model to stop.

A '******' suggests that the value being written was 'out-of-range' in some way in relation to the formating statement. The elements of a spectrum are clearly written as (up to) 6 digit integers although I haven't tracked down the actual format statement in the source code.

In this case it is possibly an 'underflow' as the '******' appears in a part of the spectrum which otherwise contains zeroes. The FACTOR for this spectrum isn't dissimilar to those for other spectra in the file and results in the largest element having an integer value of 661302.

I've experienced a similar situation in a previous coupled FLOW/WAVE simulation but never in a stand-alone WAVE simulation. In the previous case the the FACTOR for the spectrum containing the '******' had an exponent E-04 in contrast to the E-02 of all other spectra in the file. This clearly resulted in an 'overflow' out-of-range as all the '******' were located around the spectral peak.

Has anyone else observed this situation?
Why isn't an potential upper and lower 'out-of-range' situation trapped and the FACTOR adjusted to prevent it?

Many thanks,


Haven't resolved this issue but thought I would update observations.
Latest instance was with a coupled FLOW-WAVE model. A single instance of '******' in the NEST00# file caused the simulation to crash, yet a simple re-run of the simulation from scratch concluded without error. So looks like a random (non-repeatable) error.

I looked deeper into how the NEST00# file is created by the SWAN code (using the source code for version 40.72ABCDE)
The NEST???? 2D spectra file is created in subroutine WRSPEC (at line 5463 of swanser.ftn). Routine first calculates the FACTOR parameter as (line 5585)
where DEC_SPEC determines the number of digits to be written in the integer part of the 2D spectrum {set at line 218 of swmod2.ftn}.

FACTOR is written to file as (2 ?^2)/180*E FAC where the modification ‘account for change from radians to degrees and for transition from radians/s to Hz’. The integer representation of energy density is calculated and written in a single command (line 5592)
MSC/MDC - number of frequency/direction components
ACLOC – is the energy density
FIX_SPEC – format specification for writing the integer value {set at line 211 in swmod2.f}. This is ’(200(1X,I4))’ in the SWAN source code (i.e. a four digit integer field width) but it must be I6 in the binary distributed with Delft3D. FIX_SPEC must be greater than or equal to DEC_SPEC. If DEC_SPEC is 6 then the peak integer will 990099 ((1/1.01)*10^6).

Reading of boundary conditions appears to take place in subroutine RDFILE in swanmain.ftn. This is where the error following the attempt to read ‘******’ is trapped as the programme is expecting to see either FACTOR, ZERO or NODATA. FACTOR read at line 5583. Subroutine RESPEC (line 5758 of swanmain) is used to read in spectrum (called from line 5630 of swanmain.f). Reading of SWAN spectra commences at line 6072 using free format.

Hope that helps.
Adri Mourits, modified 5 Years ago.

RE: Coupled D3D-FLOW/WAVE: Wave spectra error in nested wave model

Yoda Posts: 1224 Join Date: 1/3/11 Recent Posts
Hi Ruairi,

If the swan behaviour is random/non-repeatable, try to run it in a not-parallel way. You can force this by activating the line
in the "swan.bat" file used (Linux: "export OMP_NUM_THREADS=1" in file "").