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: 
/web/delft3dfm/forum

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

=======================================================

** PLEASE TAG YOUR POST! **

 

 

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

 


Message Boards

Different results using Delft3D-FLOW version 5.01.00.2163

YL
yun lang, modified 7 Years ago.

Different results using Delft3D-FLOW version 5.01.00.2163

Youngling Posts: 10 Join Date: 3/14/12 Recent Posts
Hi everyone.

I have a problem when using Delft3D-FLOW version 5.01.00.2163.

I used vs2010+Intel fortran 12.0 to compile the downloaded source code of version 5.01.00.2163, however there are 8 errors when realeasing,as shown below:

error 990 error RC2104: undefined keyword or key name: Unversioned D:\d3d\src\utils_lgpl\nefis\packages\nefis_version_number\include\version_number.rc 31 1 nefis_dll
error 995 error RC2104 : undefined keyword or key name: Unversioned D:\d3d\src\engines_gpl\waq\packages\delwaq1_version_number\include\version_number.rc 31
error 997 error RC2104 : undefined keyword or key name: Unversioned D:\d3d\src\engines_gpl\waq\packages\delwaq2_version_number\include\version_number.rc 31
error 1112 error RC2104 : undefined keyword or key name: Unversioned D:\d3d\src\tools_gpl\mormerge\packages\mormerge_version_number\include\version_number.rc 31
error 1116 error RC2104: undefined keyword or key name: Unversioned D:\d3d\src\tools_gpl\vs\packages\vs_version_number\include\version_number.rc 31 1 vs (tools_gpl\vs\vs)
error 1117 error RC2104: undefined keyword or key name: Unversioned D:\d3d\src\tools_gpl\lint\packages\lint_version_number\include\version_number.rc 31 1 lint (tools_gpl\lint\lint)
error 1118 error RC2104: undefined keyword or key name: Unversioned D:\d3d\src\tools_gpl\kubint\packages\kubint_version_number\include\version_number.rc 31 1 kubint (tools_gpl\kubint\kubint)
error 1124 error RC2104: undefined keyword or key name: Unversioned D:\d3d\src\tools_gpl\datsel\packages\datsel_version_number\include\version_number.rc 31 1 datsel (tools_gpl\datsel\datsel)

Despite these errors,I have got the d_hydro.exe and flow2d3d.dll to run a calculation. But I am afriad the results may be wrong.


I downloaded the process demos in this website:http://oss.deltares.nl/web/delft3d/process-demos, which give simulated results out already.

I calculated the "cnz.mdf" in "DEMO 2: Simple channel flow" , however, the results confused me. The water level of an observation using my Delft3D(version 5.01.00.2163) is different from the given simulations(Version 3.54.25.00), as shown below:



The blue line is of trih-cnz.dat downloaded from the output in "DEMO 2: Simple channel flow" .And the red line is of trih-cnz.dat calculated by my Delft3D(version 5.01.00.2163).

I have no ideas why they are different.Is that because of 8 errors mentioned before or different Delft3D versions?


Thanks a lot.
Adri Mourits, modified 7 Years ago.

RE: Different results using Delft3D-FLOW version 5.01.00.2163 (Answer)

Yoda Posts: 1221 Join Date: 1/3/11 Recent Posts
Hi Yun Lang,

Everytime you compile the source code, the subversion revision number is obtained and added to the version number of the newly created executable. This "obtain the svn revision number" does not work correctly on your machine and causes the errors. Luckily not in Delft3D-FLOW, so you did manage to compile that. I expect that the version number of this Delft3D-FLOW binary, as echoed in the tri-diag file says "5.01.00.Unversioned" or "5.01.00.00000".

These errors do not cause the difference in your plot.

"cnz.mdf" is the Z-model layered version of this calculation. This Z-model approach is rigorously updated in version 5.01.00.2163, see the release notes for more details. I expect that these changes cause the difference.

Regards,

Adri
YL
yun lang, modified 7 Years ago.

RE: Different results using Delft3D-FLOW version 5.01.00.2163

Youngling Posts: 10 Join Date: 3/14/12 Recent Posts
Adri Mourits:
Hi Yun Lang,

Everytime you compile the source code, the subversion revision number is obtained and added to the version number of the newly created executable. This "obtain the svn revision number" does not work correctly on your machine and causes the errors. Luckily not in Delft3D-FLOW, so you did manage to compile that. I expect that the version number of this Delft3D-FLOW binary, as echoed in the tri-diag file says "5.01.00.Unversioned" or "5.01.00.00000".

These errors do not cause the difference in your plot.

"cnz.mdf" is the Z-model layered version of this calculation. This Z-model approach is rigorously updated in version 5.01.00.2163, see the release notes for more details. I expect that these changes cause the difference.

Regards,

Adri


Dear Adri

Thanks for your help.The tri-diag files I calculated really says "5.01.00.00000".
Is these errors due to the subversion client? How can I avoid them?

It is very glad to see the improvements of the Z-model. However, I found another question when using the executable file compiled by my computer.The Sigma-model is also different from the given calculation result, as shown below:



When I used the "cns.mdf" in "DEMO 2: Simple channel flow" to run a calculation, the depth averaged velocity of "M=all, N=3" is ploted as the red line, while the blue line presents the given result downloaded from the website. I suppose the difference is acceptable?


Regards,

yun
Qinghua Ye, modified 7 Years ago.

RE: Different results using Delft3D-FLOW version 5.01.00.2163

Jedi Council Member Posts: 612 Join Date: 3/2/11 Recent Posts
dear yun lang,

The difference is from the update of our z-model code. It is not from the errors. You might have to download a clean version and recompile the code to avoid the errors.

Indeed, we do have a lot of improvement for the z-model from the end of 2012 to the beginning of 2013. Thus I would expect the difference if you use an older version generated than 5.00.10.1983. and we verified the new code of z-model and accepted the difference. I would expect you should use the newer z-model in practice.

Regards,

Qinghua
YL
yun lang, modified 7 Years ago.

RE: Different results using Delft3D-FLOW version 5.01.00.2163

Youngling Posts: 10 Join Date: 3/14/12 Recent Posts
Qinghua Ye:
dear yun lang,

The difference is from the update of our z-model code. It is not from the errors. You might have to download a clean version and recompile the code to avoid the errors.

Indeed, we do have a lot of improvement for the z-model from the end of 2012 to the beginning of 2013. Thus I would expect the difference if you use an older version generated than 5.00.10.1983. and we verified the new code of z-model and accepted the difference. I would expect you should use the newer z-model in practice.

Regards,

Qinghua


Dear Qinghua

Thanks for your reply.
But I am a little confused by what you said.

What is called "a clean version"? An older version generated than 5.00.10.1983?

Do you mean that the differece in an older version generated than version 5.00.10.1983 is accepted or in the newer version is accepted?


Regards,

yun
Qinghua Ye, modified 7 Years ago.

RE: Different results using Delft3D-FLOW version 5.01.00.2163

Jedi Council Member Posts: 612 Join Date: 3/2/11 Recent Posts
dear yun lang,

Sorry... my reply introduced more confusion. My fault.

We recently updated the kernel of the Z layer model. These actions are regarded as the causes of the differences between results. We noticed that already and examined the new results carefully and we thought the new results are acceptable. Thus we accept the update of the code update.

Thus you are strongly suggested to use the new 6.**.**.00 versions for your practice.

Hope this will help a bit?

Qinghua YE
YL
yun lang, modified 7 Years ago.

RE: Different results using Delft3D-FLOW version 5.01.00.2163

Youngling Posts: 10 Join Date: 3/14/12 Recent Posts
Qinghua Ye:
dear yun lang,

Sorry... my reply introduced more confusion. My fault.

We recently updated the kernel of the Z layer model. These actions are regarded as the causes of the differences between results. We noticed that already and examined the new results carefully and we thought the new results are acceptable. Thus we accept the update of the code update.

Thus you are strongly suggested to use the new 6.**.**.00 versions for your practice.

Hope this will help a bit?

Qinghua YE


Dear Qinghua Ye,

Sorry to trouble you again...

A new problem came when I tried version 6.00.00.2367. The codes can be compiled successfully. However, when started the QUICKPLOT from delft3d_ohmw_4.01.00.rc.03.zip, it returns a message:
Catch in d3d_qp\initialize:
The following error occurred converting from cell to double:
Error using ==>double
Conversion to double from cell is not possible.


Since the QUICKPLOT can properly work when using Delft3D-FLOW version 5.01.00.2163 with Delft3D 4.00.02, there is no problem with the MCR. I am afraid something may be wrong with the matlab codes(*.m).

Thanks,
Yun Lang
Bert Jagers, modified 7 Years ago.

RE: Different results using Delft3D-FLOW version 5.01.00.2163

Jedi Knight Posts: 201 Join Date: 12/22/10 Recent Posts
Dear Yun Lang,

QuickPlot remembers settings between sessions via a Delft-QUICKPLOT.ini file. There might be something wrong when interpreting the old file; I would be interested in seeing your version of that file to identify what the problem is exactly. As a work-around you may try to remove the file (but please keep a copy for me to analyze :-) ). Where the Delft-QUICKPLOT file is located depends on your operating system. On Linux it should be located in the folder .Deltares (note the dot at the start which makes it hidden by default) in your home directory. On a typical English Windows 7 installation it is located in c:\Users\[YourUserID]\Application Data\Deltares (note the Application Data folder - actually a link to AppData\Roaming - is hidden by default). On other Windows systems, it may be located in a different folder but with similar character. Please contact me through delft3d. support at deltares. nl if you can't find it.

Best regards,

Bert
YL
yun lang, modified 7 Years ago.

RE: Different results using Delft3D-FLOW version 5.01.00.2163

Youngling Posts: 10 Join Date: 3/14/12 Recent Posts
Bert Jagers:
Dear Yun Lang,

QuickPlot remembers settings between sessions via a Delft-QUICKPLOT.ini file. There might be something wrong when interpreting the old file; I would be interested in seeing your version of that file to identify what the problem is exactly. As a work-around you may try to remove the file (but please keep a copy for me to analyze :-) ). Where the Delft-QUICKPLOT file is located depends on your operating system. On Linux it should be located in the folder .Deltares (note the dot at the start which makes it hidden by default) in your home directory. On a typical English Windows 7 installation it is located in c:\Users\[YourUserID]\Application Data\Deltares (note the Application Data folder - actually a link to AppData\Roaming - is hidden by default). On other Windows systems, it may be located in a different folder but with similar character. Please contact me through delft3d. support at deltares. nl if you can't find it.

Best regards,

Bert

Dear Bert,

I can find the Delft-QUICKPLOT.ini file.(The attachment shows)

Since I cannot use QUICKPLOT in delft3d_ohmw_4.01.00.rc.03, I open the *.dat files through QUICKPLOT with Delft3D 4.00.02. I suppose the Delft-QUICKPLOT.ini file just remerbered this operation.

After I removed this file, the QUICKPLOT still does not work.

Thanks for help

Yun Lang
Adri Mourits, modified 7 Years ago.

RE: Different results using Delft3D-FLOW version 5.01.00.2163 (Answer)

Yoda Posts: 1221 Join Date: 1/3/11 Recent Posts
Hi Yun,

About the differences you noticed with respect to the sigma situation (cns.mdf):

Attached is the "same" picture as you created, with some additional lines:
Blue: Delft3D-FLOW, Version 3.54.25.00, timestep = 1.0
Red: Delft3D-FLOW, Version 5.01.00.2163, timestep = 1.0
Green: Delft3D-FLOW, Version 5.01.00.2163, timestep = 0.1
Pink/purple: Delft3D-FLOW, Version 3.54.25.00, timestep = 0.1

A run with timestep=0.01 gives the same result as with timestep=0.1.

Conclusion: If you are interested in this "level of detail" in this case, the time step should be about 0.1 instead of 1.0.

Regards,

Adri

Attachments:

YL
yun lang, modified 7 Years ago.

RE: Different results using Delft3D-FLOW version 5.01.00.2163

Youngling Posts: 10 Join Date: 3/14/12 Recent Posts
Adri Mourits:
Hi Yun,

About the differences you noticed with respect to the sigma situation (cns.mdf):

Attached is the "same" picture as you created, with some additional lines:
Blue: Delft3D-FLOW, Version 3.54.25.00, timestep = 1.0
Red: Delft3D-FLOW, Version 5.01.00.2163, timestep = 1.0
Green: Delft3D-FLOW, Version 5.01.00.2163, timestep = 0.1
Pink/purple: Delft3D-FLOW, Version 3.54.25.00, timestep = 0.1

A run with timestep=0.01 gives the same result as with timestep=0.1.

Conclusion: If you are interested in this "level of detail" in this case, the time step should be about 0.1 instead of 1.0.

Regards,

Adri


Hi Adri,

Thanks for your help.

Now I am encountering another problem, not small differences.

When I simulated a reservoir using the depth-averaged two-dimensional model, and setted the upperstream with a "total discharge" boundary and the downstream with a "water level" boundary. The grid size is 50~100 metres, and timestep=1.0.
The calculation is between Delft3D-FLOW, Version 3.28.04 and Version 5.01.00.2163.
However, with the Version 5.01.00.2163, the discharge of the cross-section near the upperstream is nearly zero, not the discharge I gave as a boundary condition.
And the Version 3.28.04 gave a proper result.
Does it mean when I compiled the open source code, something wrong happened?
I do not know where was the discharge?
It is just a 2d model, not the z-layer.

Regards,

Yun
Adri Mourits, modified 7 Years ago.

RE: Different results using Delft3D-FLOW version 5.01.00.2163

Yoda Posts: 1221 Join Date: 1/3/11 Recent Posts
Hi Yun,

The total discharge boundary condition has not changed much between those two versions. Does the tri-diag file contain an error message? Can you zip the input files and attach it to a post here on the forum?

Thanks.

Adri
Richard Measures, modified 7 Years ago.

RE: Different results using Delft3D-FLOW version 5.01.00.2163 (Answer)

Jedi Knight Posts: 178 Join Date: 3/23/11 Recent Posts
Hi Yun,

You could try switching off the changes to the total discharge boundary implemented in version 5.01.00.2163 by inserting an additional line in your MDF file:
ZavgQt= #NO#

This is described in the release notes. By turning the changes to the total discharge boundary off you can test if this is the cause of the differences you are observing.

Cheers,

Richard
YL
yun lang, modified 7 Years ago.

RE: Different results using Delft3D-FLOW version 5.01.00.2163

Youngling Posts: 10 Join Date: 3/14/12 Recent Posts
Richard Measures:
Hi Yun,

You could try switching off the changes to the total discharge boundary implemented in version 5.01.00.2163 by inserting an additional line in your MDF file:
ZavgQt= #NO#

This is described in the release notes. By turning the changes to the total discharge boundary off you can test if this is the cause of the differences you are observing.

Cheers,

Richard


Hi Richard,

Thanks for your advice. The problem was solved through this method.


Regards,

Yun
YL
yun lang, modified 7 Years ago.

RE: Different results using Delft3D-FLOW version 5.01.00.2163

Youngling Posts: 10 Join Date: 3/14/12 Recent Posts
Hi everyone,

Sorry to trouble again.

Cause I have a new problem with Boundaries-"Transport Conditions"

I used Z-model, and the process of "Temperature" was involved.

When setting the "Transport Conditions", I chose The vertical profile of "Linear", and gave the temperatures of the botton and surface respectively. For example, the bottom is 14 degrees Celsius, and the surface is 16 degrees Celsius.

However, the transport boundary does not work at all.

The calculated surface temperature was about 14 degrees Celsius, and the calculated bottom temperature was near 0. I do not know why?

May the Sigma-model be ok?

Regards,

Yun
Adri Mourits, modified 7 Years ago.

RE: Different results using Delft3D-FLOW version 5.01.00.2163

Yoda Posts: 1221 Join Date: 1/3/11 Recent Posts
Hi Yun,

I'm not aware of any problem related to boundaries in Z-layers. Can you zip your files and attach it to a post here?

Thanks.

Adri