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

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.