ZMODEL and generating WAQ-compatible hydrodynamicsZMODEL and generating WAQ-compatible hydrodynamicshttps://oss.deltares.nl/c/message_boards/find_thread?p_l_id=183924&threadId=8158072019-07-15T21:55:30Z2019-07-15T21:55:30ZRE: ZMODEL and generating WAQ-compatible hydrodynamicsMichelle Jeukenhttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=183924&messageId=8170322016-01-18T07:55:13Z2016-01-18T07:53:55ZHi Rusty,<br /><br />Thanks for your interest in Delwaq. I think I can help you out with a few suggestions.<br /><br />First of all, you do not need to add the multigrid settings. Those are for some special actions, like for example layered sediment.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />MichelMichelle Jeuken2016-01-18T07:53:55ZRE: ZMODEL and generating WAQ-compatible hydrodynamicsRusty Hollemanhttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=183924&messageId=8158922016-01-15T23:54:30Z2016-01-15T23:54:30ZUpdate - the solution appears to be including "NODISP-AT-BOUND" (I mistakenly thought that this was the default).<br /><br />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...Rusty Holleman2016-01-15T23:54:30ZZMODEL and generating WAQ-compatible hydrodynamicsRusty Hollemanhttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=183924&messageId=8158062016-01-15T21:25:40Z2016-01-15T21:23:08ZWe have an existing, calibrated, unstructured 3D z-layer model from a different code (SUNTANS).<br /><br />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.<br /><br />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).<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />I have tried adding <br />MULTIGRID<br /> ZMODEL<br /> NOLAY 31<br />END_MULTIGRID<br /><br />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.<br /><br />Does anyone have guidance on what could be going wrong, or what invariant my hydrodynamics might be violating?<br /><br />thank you --<br />RustyRusty Holleman2016-01-15T21:23:08Z