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

bloominp.blm growing to 400 GB in Size!!!

Daniel Harrison, modified 4 Years ago.

bloominp.blm growing to 400 GB in Size!!!

Youngling Posts: 4 Join Date: 1/11/16 Recent Posts
Hi There,

I have a problem when I run a water quality simulation with DWAQ the file bloominp.blm grows in size to be almost 400 GB in size at the completion of the 1 year simulation I am running. This is in contrast to for example the map output file which output at 6 hourly intervals only reaches 2 GB for the entire run.

While this does not seem to preclude a 'normal completion' it is causing me HDD space issues as well as I/O failures if I try to run more than 1 simulation concurrently.

It seems that bloominp.blm is perhaps having the full grid written to it (in binary) every computation timestep. If this is the case is there any way to prevent this behavior?

See attached head of file, the remainder is more 'binary type' characters.

Kind Regards,

Dr Daniel Harrison
University of Sydney
Michel Jeuken, modified 4 Years ago.

RE: bloominp.blm growing to 400 GB in Size!!!

Jedi Knight Posts: 154 Join Date: 1/21/13 Recent Posts
Hi Daniel,

I'm sorry, that was a very nasty bug in the BLOOM section of the code. Accidentally the writing of debug information was always switch on. I hope it didn't cause too much trouble.

It has been in the code between revision 6008 and 6150, and was removed with revision 6151 and is caused by changes in /trunk/src/engines_gpl/waq/packages/waq_kernel/src/bloom/bloutc.f. Please use a version of the full code/this file outside this range of revisions.