intro story Coast / Estuary

Coast / Estuary

Coastal systems are among the most dynamic physical systems on earth and are subject to a large variety of forces. The morphodynamic changes occurring to coastlines worldwide are of great interest and importance. These changes occur as a result of the erosion of sediments, its subsequent transport as bed load or suspended load, and eventual deposition. 
Estuaries are partly enclosed water bodies that have an open connection to the coast. Estuaries generally have one or more branching channels, intertidal mudflats and/or salt marshes. Intertidal areas are of high ecological importance and trap sediments (sands, silts, clays and organic matter).
Within the Delft3D modelling package a large variation of coastal and estuarine physical and chemical processes can be simulated. These include waves, tidal propagation, wind- or wave-induced water level setup, flow induced by salinity or temperature gradients, sand and mud transport, water quality and changing bathymetry (morphology). Delft3D can also be used operationally e.g. storm, surge and algal bloom forecasting. 
On this discussion page you can post questions, research discussions or just share your experience about modelling coastal and/or estuarine systems with Delft3D FM. 




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.