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.

** PLEASE TAG YOUR POST! **

 

 

Sub groups
D-Flow Flexible Mesh
DELWAQ

Cohesive sediments & muddy systems

 


« Back to DELWAQ

.par file and bottomdept

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
.par file and bottomdept
Answer (Unmark)
9/20/16 1:27 PM
Hi there,

I am running delwaq in a 3D z-layer setup using forcing files generated by untrim. I recently stumbled across the *.par file that delwaq generates when I setup a new run using the gui. I can't find any good documentation of neither the .par file nor the bottomdept variable. In another post here I found the format to read the *.par-file and my file contained a 10993 x 31 matrix with all elements equal to zero. I have 10993 horizontal elements and 31 depth layers. Are the values the ones for the bottomdept variable? If so, why are they all zero? Should they contain depths in meter below sea surface?

Thanks in advance for your answers!

Cheers
Levin
RE: .par file and bottomdept
Answer (Unmark)
9/20/16 1:43 PMas a reply to Levin Nickelsen.
The .par file is indeed generated by the GUI to contain the values of the collected parameters (that is, the process parameters that vary over the segments but not in time). The depth is an example, but the surface area is actually more useful as then the depth at each moment can be computed from the volume and the surface area.

How did you get a parameter bottomdept (oh, I see, it is added automatically)? Or better, does the set of forcing files include the surface area? You should have a file with the extension .srf - this contains the surface area. DELWAQ can compute the depth via the processes DynDepth and TotDepth. And actually that should be included in the input automatically as well.
RE: .par file and bottomdept
Answer (Unmark)
9/20/16 2:14 PMas a reply to Arjen Markus.
Yes, the set of forcing files includes a .srf file (varying in time) and delwaq computes the depth via DynDepth. That is why I assumed that the zeros in the .par file are corresponding to the bottomdept variable that I did not specify anywhere else but maybe it is something different? Do I need a to specify bottomdept? And how can I find out what's in the .par file? I can't see any possibility to control that in the gui. Sorry if the answers are obvious but I can't figure it out right now and I am just a little worried about not knowing what the variable in the .par file is for.
RE: .par file and bottomdept
Answer (Unmark)
9/20/16 3:20 PMas a reply to Levin Nickelsen.
Well, there is a bit of "magic" going on: certain parameters, like the bottom shear stress and the surface area, are needed in a majority of cases, so the GUI picks these up automatically whenever files designated for these quantities are present (see the contents of the .hyd file). The GUI will gather that sort of information automatically and one type of information, the "scalar fields", is stored in the .par file.

If you select another file with "scalar field" data, say the extra shear stress due to shipping activities, then that information is stored in the .par file as well. The file itself contains no information about the parameters it contains, for that you can consult the .inp file. But the information is properly picked by DELWAQ.

If you need such process parameters (that is, process parameters varying over the area) - beyond what is automatically included - then you should do the following:
- click on the parameter in question
- click the Edit data button
- from the menu of the new window select Properties/Details.
- then you can select whether the parameter should be a constant, a timeseries of a scalar field.
- via the menu Data/Import you can select the file suitable for your purpose

The GUI takes care of the various details, so that the data are combined into the input files for the calculation.
RE: .par file and bottomdept
Answer (Unmark)
9/20/16 3:52 PMas a reply to Arjen Markus.
Ok, thanks a lot! That is good to know! In my case only the bottomdept parameter is picked up by the gui and stored in the .par-file (I know remember that I knew it was bottomdept because I saw it in the .inp file):

PARAMETERS
; 1 - number of parameters
'bottomdept'
ALL
; parameters in binary file
BINARY_FILE 'ln57_003.par' ; binary file

The procedure you describe is what I usually do with for instance salinity or temperature and that works fine. However, I am still not quiet sure yet where the gui takes the values for the bottomdept variable from, maybe from the grid-coordinates-file which is a netcdf file in our case. Anyways, is it a problem that bottomdept is set to zero everywhere? And what should be in there?
RE: .par file and bottomdept
Answer (Unmark)
9/20/16 3:59 PMas a reply to Levin Nickelsen.
Hm, bottomdept is not used anywhere in the processes library as far as I can tell, so no it doesn't matter. On the other hand I would expect the surface area (SURF) to be present.

Could you check that the file with extension .srf is referred to in the .hyd file?
RE: .par file and bottomdept
Answer (Unmark)
9/20/16 4:23 PMas a reply to Arjen Markus.
Ok, then I will just ignore it. If I delete it delwaq doesn't run though.

Yes the .srf file is stated in the .hyd file and seems to correctly read in the surfaces. I manipulated the .srf file a while ago because the calculated depths by DynDepth were not like I expected and after my manipulations the depths changed to what I wanted them to be.

This is the line from the .hyd file:

surfaces-file 'WAQ.utromp2009.srf'

Thanks again!
RE: .par file and bottomdept
Answer (Unmark)
9/20/16 4:28 PMas a reply to Levin Nickelsen.
You should be careful here: there are three output parameters involved:
Depth (which is actually a bit of a misnomer - it is the depth within the layer, a better name would have been the layer thickness)
LocalDepth - the distance from the surface to the lower bound of the layer
TotalDepth - the distance from the surface to the bottom of the water column

Could this explain the discrepancy?
RE: .par file and bottomdept
Answer (Unmark)
9/21/16 1:14 PMas a reply to Arjen Markus.
Hi Levin,

I know that UNTRIM has a flexible surface areas over time, So I belief dat for UTRIN Surf is actually a segmetn function. You are not happy with the depth that DynDepth Delwaq makes from Volume/Surf (what the proces simply does). Might it be an idea to switch of the proces DynDepth, and let UNTRIM write a segment function with the Depth variable with the depth for each layer, and connect it as a segment function? You can still use TotalDepth to calcualte total depths of the water column.

greetings,
Michel
RE: .par file and bottomdept
Answer (Unmark)
9/22/16 2:32 PMas a reply to Michelle Jeuken.
Hi Michel and Arjen,

related to the depth and surfaces:
right now Depth (or layer thickness), LocalDepth and TotalDepth look alright after I adjusted the way untrim writes the .srf file. The surface values are now calculated by dividing the volume of the cell by the maximum layer thickness that is present in a cell. We have to take the maximum because one cell contains several layer thicknesses due to the subgrid. This way the free surface is still represented. So that is fine for now but if I find more problems then I will try what you suggest. Thanks!

The question to the .par file was unrelated to the previous problem I had with the surfaces. I just wanted to understand the reason for all the zeros and what the bottomdept parameter does because I couldn't find it in the manuals.

I have to do a few more tests and let you know if everything works or more problems/questions come up.

Thanks!
Levin