intro story DELWAQ


DELWAQ is the engine of the D-Water Quality and D-Ecology programmes of the Delft3D suite. It is based on a rich library from which relevant substances and processes can be selected to quickly put water and sediment quality models together.

The processes library covers many aspects of water quality and ecology, from basic tracers, dissolved oxygen, nutrients, organic matter, inorganic suspended matter, heavy metals, bacteria and organic micro-pollutants, to complex algae and macrophyte dynamics. High performance solvers enable the simulation of long periods, often required to capture the full cycles of the processes being modelled.

The finite volume approach underlying DELWAQ allows it to be coupled to both the structured grid hydrodynamics of the current Delft3D-FLOW engine and the upcoming D-Flow Flexible Mesh engine (1D-2D-3D) of the Delft3D Flexible Mesh Suite (or even other models such as TELEMAC).

'DELWAQ in open source' is our invitation to all leading experts to collaborate in further development and research in the field of water quality, ecology and morphology using Delft3D. Feel free to post your DELWAQ related questions or comments in this dedicated forum space. If you are new to DELWAQ, the tutorial (in the user manual) is a good place to start. A list of DELWAQ related publications is available here.




Sub groups
D-Flow Flexible Mesh

Cohesive sediments & muddy systems


Message Boards

ZMODEL and generating WAQ-compatible hydrodynamics

Rusty Holleman, modified 5 Years ago.

ZMODEL and generating WAQ-compatible hydrodynamics

Youngling Posts: 4 Join Date: 8/3/15 Recent Posts
We have an existing, calibrated, unstructured 3D z-layer model from a different code (SUNTANS).

This model has been modified to output volumes, flows, etc. in the format expected by delwaq, and we are able to run passive tracer studies which appear correct except for mass input.

Mass sources (outfalls) in the original hydrodynamics are included as boundary exchanges (i.e. negative entry in pointers). I am trying to add a unique passive tracer to each of these inputs, but the resulting mass in the domain accumulates an order of magnitude faster than the flow rate implies. For one specific case outfall which enters in exactly one segment, the outfall has a flow rate of about 3 m3/s, while the mass of passive tracer accumulates at an average rate of about 60 m3/s (where the tracer has unit concentration prescribed for this boundary).

Comparing d mass / dt with the flows in and out of the segment (i.e. the segment connected to the boundary exchange), I see patterns in the mass accumulation which reflect flow through the other exchanges. In the attached plot, the black line denotes the rate of mass accumulation, and colored lines are flow rates, with signs adjusted to all represent flow into the segment. I would expect that the black line, d mass / dt, would coincide with the cyan line, which is the flow rate through the boundary. Legend entries in the plot give the number of the exchange, and the from/to segments for each.

Instead, the black line appears to be some mix of the much larger, tidal flows going through the other exchanges associated with this segment. In particular, the black line appears similar to the sum of the inflows, as if all of the in-flows are being treated like the boundary condition.

Only at the end, where the segment essentially dries out and has no flows, does the mass accumulation rate revert to the boundary inflow rate.

I have tried adding

to the inp file (attached), but that results in "ERROR in PSOLVE", where psolve.f asserts that [# of segs]==[# of layers]*[segments per layer], which doesn't hold in my z-layer model as cells below the bed are omitted from the input.

Does anyone have guidance on what could be going wrong, or what invariant my hydrodynamics might be violating?

thank you --
Rusty Holleman, modified 5 Years ago.

RE: ZMODEL and generating WAQ-compatible hydrodynamics

Youngling Posts: 4 Join Date: 8/3/15 Recent Posts
Update - the solution appears to be including "NODISP-AT-BOUND" (I mistakenly thought that this was the default).

I am still unclear on the usage of 'ZMODEL' and 'NOLAY' when the input is a z-layer model. I am unable to run delwaq with the ZMODEL flag enabled, which makes me concerned that there are other issues yet to be unearthed...
Michel Jeuken, modified 5 Years ago.

RE: ZMODEL and generating WAQ-compatible hydrodynamics

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

Thanks for your interest in Delwaq. I think I can help you out with a few suggestions.

First of all, you do not need to add the multigrid settings. Those are for some special actions, like for example layered sediment.

You are right about number of segments not being correctly the number of layers*number of segments per layer. Although delwaq is quite unstructured by nature, it is only unstructured in the horizontal direction. In the vertical every column of volumes needs to be the same number of layers. Also you first have to give the volumes of the first, top layer, then the second, third, etc, until the bottom layer. The number of volume should be the same for all layers (nosegl = number of segments per layer), and order in such a way that the volume in the layer below is the current number + nosegl. E.g. when nosegl is 105, segment 115 is the segment just below segment 10. At least some of the processes rely on this rule.

To deal with z-layer, you can label the lower segments as inactive using the attributes. Unfortunately that means that you have to provide some or a lot of dummy data (depending on your model), because you have to provide dummy values for the inactive volumes. But, fortunately the flow pointer is allowed to be sparse, only you first need to provide the horizontal flows (in first and second direction, but in unstructured models that can be zero), then the vertical flows in the third direction. The latter have to be specified from top to bottom.

The reasons for this have historically grown because initially Delwaq only worked with sigma-models, and the rule next layer is current + nosegl. To be more flexible we would need quite a lot of reprogramming.

But, I don't think this will solve the problem you talk about. I don't have an answer to that problem, but I would suggest to put dispersion to 0.0 (or 10^-7) to reduce the effects of dispersion, and also, I would start with a smaller model that is easier to overview.