null

Message Boards

Time and Depth Varying Boundary Condition and others...

NN
Nill Ng, modified 5 Years ago.

Time and Depth Varying Boundary Condition and others...

Youngling Posts: 23 Join Date: 4/16/15 Recent Posts
Dear DELWAQ users,

I am trying to setup WAQ at estuary area and encountered a few technical issues.

(1) I am trying to setup a time-varying and depth-varying boundary condition for the model to simulate for whole year. Yet this is only possible to set this up by editing the .inp file directly. Can anyone provide me with a template with that particular section? That template is not discussed in the DELWAQ Manual.

(2) The discharge of fresh water at the estuary is expected to significantly increase the level of vertical mixing at the opening of the river. I understand vertical mixing can be increased locally by editing a dispersion array file (.dsp). Is there anyway that I could determine the extent and magnitude of such enhanced vertical mixing based on the Delft3D FLOW results?

(3) The DELWAQ Manual suggested that statistic over the whole water column (i.e. depth-averaged, depth minimum and depth maximum value) by selecting "depth averaging" in the "Select Statistical Output" window in the GUI. This works for stat.mon file but not stat.map file. Is there any way that I could include depth-averaged output in stat.map file as well?

(4) I understand there is a specific code in the .inp file that allows the use of more the one CPU core for DELWAQ computation. Is there any manual that I could make reference to?

Nill
AM
Arjen Markus, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others... (Answer)

Jedi Knight Posts: 223 Join Date: 1/26/11 Recent Posts
I will try to answer your questions as well as possible:

ad 1.
The GUI does not support time- and depth-varying boundary conditions because it was too much effort for too little gain. Quite often such conditions are much easier to obtain via nesting. For this reason you can use a binary file (produced by the nesting programs) to specify these conditions.

If you want to specify the boundary conditions by explicit timeseries, then have a look at the input file:
- Boundary segments have an index, a name and a type (well, actually they have three strings associated with them).
You can use these strings to specify the timeseries per segment, per section of segments or per type. The first string must be unique,
but IIRC the other two are free.
Timeseries are associated with the name you give them and the boundary segments are associated with the timeseries
that is associated with the strings you give these segments. That way, things are very flexible.
For instance: use one timeseries per layer and use the last string to connect all the boundary segments in one layer to the corresponding timeseries.

Hopefully I explained it clear enough emoticon.

ad 2.
You can use the vertical diffusion file from Delft3D-FLOW automatically. It has the extension .vdf and you need to activate the process "Vertical Dispersion". This should actually be turned on automatically via the GUI. (Look for ".vdf" and "ACTIVE_VERTDISP" in the .inp file)

ad 3.
That is a bit surprising - I would not have thought that the statistical output is not written to the map file. Any chance you select specific parameters?

ad 4.
This feature is controlled by the constant NOTHREADS. Hm, the manual does not seem to document it. I will make a note of that.
Here is the idea:
NOTHREADS = 0: use the default number of threads (usually equal to the number of cores on the machine)
NOTHREADS > 0: use that number of threads irrespective of the hardware
Not specifying NOTHREADS means the default is used, that is: NOTHREADS = 1.

Threading mainly works on the evaluation of the processes in some of the integration routines.
CT
Christophe Thiange, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others...

Jedi Knight Posts: 125 Join Date: 11/15/12 Recent Posts
NOTHREADS and other special constants are documented in the input file manual.

The syntax for boundary definitions can also be found in this manual.
AM
Arjen Markus, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others...

Jedi Knight Posts: 223 Join Date: 1/26/11 Recent Posts
Ah, thanks, I was not aware of that.

That manual also explains the strings that you can associate with each boundary segment.
NN
Nill Ng, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others...

Youngling Posts: 23 Join Date: 4/16/15 Recent Posts
Thanks for the response from Arjen and Christophe.
(1) I know that time and depth varying boundary condition can be generated by nestwq. But at the model domain boundary I have long term depth varying water quality monitoring data. So making those data into time series would not be difficult for me. I have gone through the relevant section of the Input file manual provided by Christophe. The syntax for the block stipulating the open boundary looks quite different. For instance, in the manual the end of the boundary reads, "5 ; delimiter for the fifth group of input dat". But in the input file generated by my Delft3D version reads, "#5 ; delimiter for the fifth block". I suppose the version of Delft3D Suite I am using matters a lot. I am indeed using a subscribed version of Delft3D in my company and I expect the version maybe a little bit different from commonly used version here. Is there an archive that I could look for the appropriate manual for my version? I have attached the D3D version file for information.
(2) Thanks for your information. I will check on this.
(3) I have also attached a typical statistic file being used. The file was generated from the D3D WAQ GUI. I generally use GPP for preparing contour plots. The atttached png picture shows what items I can select. There are no option for depth averaged value plots of water quality parameters from stat.map file.
(4) The key word cannot be found in the input file. It seems there is a problem with my version of Delft3D.
AM
Arjen Markus, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others... (Answer)

Jedi Knight Posts: 223 Join Date: 1/26/11 Recent Posts
Hi Niil,

here are my remarks:

ad (1)
That must be a typo in the manual - DELWAQ has always used a hash sign to close off a section. Well, ever since it was thoroughly revised in the early 1990s or thereabout emoticon. I will check this.

ad (3)
You are looking at the wrong dialogue ;). All statistical output is treated as a new output parameter. So you should scroll down the list of available parameters.

ad (4)
We should been clearer about this: NOTHREADS is a constant that is entered in the section of process constants, parameters and so on.
So insert in the list of constants a line like:

CONSTANTS NOTHREADS DATA 0
AM
Arjen Markus, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others...

Jedi Knight Posts: 223 Join Date: 1/26/11 Recent Posts
ad (1)
In my version of the document there is:

#5 ; delimiter for the fifth group of input dat

it appears on page 41 and there is no other occurrence of the text "5 ; delimiter for the fifth group of input dat" (without the #)

Can you tell on which page it occurs in your version? To be sure: my document is marked as "Version: 2.00.33361" on page "i" - the last part of the version number is an automatically assigned number, so we can not mess it up emoticon.
NN
Nill Ng, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others...

Youngling Posts: 23 Join Date: 4/16/15 Recent Posts
Hi Arjen,

(1) That missing # is just a typo from me. I am sorry for this. But the main point for this is the delimiter statement is different.

(3) I did not miss anything from the stat.map file. I have attached a picture showing the full list of parameters available from the stat.map file. As shown, there is no depth-average statistics available. Or did you mean some where else that I missed?

(4) I managed to start the modelling with multiple core (though with a slightly different code from what you have provided). Since I am using a PC that is specifically built for modelling, I tried to make use of 30 out of 32 cores of the CPU. Yet that does not work. I then tried with 16 cores and then it works. Is there any specific rule for the number of core that can be used? Also, is there any similar application for Delft3D FLOW? Generally it takes much longer for model run of FLOW than PART and WAQ, it would be much more useful to speed up the FLOW run.
AM
Arjen Markus, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others...

Jedi Knight Posts: 223 Join Date: 1/26/11 Recent Posts
ad (1)
Hm, you mention a different delimiter statement, but the only thing that is required is "#5" - anything after a semicolon (;) is considered comment and is simply ignored.

ad (3)
This is really odd - I will check this. The depth-averaged parameters are indeed missing.

ad (4)
What were the symptoms when you specified 30 threads from which you concluded it did not work? The algorithm behind this all builds a structure of processes that can be evaluated in parallel or that need to be evaluated one after the other. Your model set-up may not be suitable for more than 16 threads (representing 16 groups of processes that do not influence each other), but that is merely a guess.

As for accelerating Delft3D-FLOW calculations, that is best asked in the FLOW forum - I know one option, domain decomposition, but that requires some work and I do not know what others are possibly avaliable.
AM
Arjen Markus, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others... (Answer)

Jedi Knight Posts: 223 Join Date: 1/26/11 Recent Posts
ad (3)
Ah, the riddle is solved:

Depth-averaged parameters are in fact time-dependent and are therefore stored in the ordinary map file, not in the stat-map file. This is not the case for some other statistically processed parameters, like the mean over a period, because effectively there is no time-dependency left. It would be inefficient to store these in the ordinary map file.

Of course, with depth-averaged parameters you lose the third dimension, but we decided against introducing yet another map file to specifcally store this type of output.
NN
Nill Ng, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others...

Youngling Posts: 23 Join Date: 4/16/15 Recent Posts
Arjen,

(1) Noted on the delimiter. But still I need some reference on how time and depth varying boundary can be specified in the input file. The input file manual provided by Christophe does not match with my version of DELWAQ. Is there a corresponding version of input manual available?
(3) I see. I mistakenly think that depth-average statisticis stored in the stat.map file. The WAQ manual stated this and I overlooked it. Having map files with depth-average statistic but not time-average statistics still troubles me, but this solved part of my problem anyway. I still need to find a way to create mean / 10th-percentile statistics for specified period of time throughout the water column.
(4) Please find the attached error message for run with 30 cores. As I said before, the same settings works with 16 cores.
AM
Arjen Markus, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others... (Answer)

Jedi Knight Posts: 223 Join Date: 1/26/11 Recent Posts
ad (1)
There has not been that much change in the DELWAQ input file over the years, so the manual you have ought to be adequate. However, I will try to explain the way to do what you want in a bit more detail:
- Suppose you have a boundary section that contains three boundary "cells" (so adjacent in the horizontal) and there are two layers. That means six actual boundary cells.
- Let us call them "bnd 1, lay 1", "bnd 2, lay 1", "bnd 3, lay 1", "bnd 1, lay 2", "bnd 2, lay 2", "bnd 3, lay 2". The boundary cells are indexed from -1 to -6 but you are free to give them any
name you want. Unless I am mistaken, the horizontal index increases first and then the layer index - at least if you have a Delft3D-FLOW model for the grid and hydrodynamics.
- You will have to provide a time series for all of these boundary cells. If you want to keep the boundary value constant over the horizontal, you can do so by using the "type" instead of the actual name, because then the time series for the type will be used for any boundary cell that has that particular type. To do that: use types like "section 1, lay 1" for the cells "bnd 1, lay 1", "bnd 2, lay 1", "bnd 3, lay 1" and likewise "section 1, lay 2" for the cells in the second layer.

For example:

ITEM
'bnd 1, lay 1' 'bnd 2, lay 1', 'bnd 3, lay 1'
CONCENTRATIONS
USEFOR 'Continuity' 'Continuity'
TIME LINEAR
DATA
'Continuity'

1996/01/03-00:00:00 1.0 1.0 1.0 ; Three values, one for each boundary cell
1996/01/04-01:00:00 1.0 1.0 1.0

ITEM
'section 1, lay 2'
CONCENTRATIONS
USEFOR 'Continuity' 'Continuity'
TIME LINEAR
DATA
'Continuity'

1996/01/03-00:00:00 1.0 ; One value, reused for each boundary cell with the type "section 1, lay 2'
1996/01/04-01:00:00 1.0


(Note: Delft3D-WAQ actually is very flexible in what it accepts - you can override time series you gave for a particular boundary cell later in the file. )

ad (3)
I may be mistaken, but I think you can use the output of the depth-averaging process as input for the time-averaging process. Be sure to:
- Specify the full name of the resulting output parameter in the definition of the time-averaging
- Specify the time averaging statistical block after the depth-averaging one in the stt file.

This requires you editing the stt file directly.

ad (4)
This is not something I would have expected. Can you send us the input files for this particular case? I can open up an FTP account if you need that (the files may be too large to attach them here or you do not want them to become public).
NN
Nill Ng, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others...

Youngling Posts: 23 Join Date: 4/16/15 Recent Posts
Arjen,

(1) I will give a try and reply to you on this later.
(3) Do you mean I can treat the depth-averaged parameters as a water parameter and add statistic of that depth-averaged parameters directly? That is a good news for me. Is there any specific rule for it? One obvious limitation I can think of is that the time-statistics parameters of the depth-averaged parameters should be presented in the depth-averaged parameters in the statistics files. Any other?
(4) If you could help with the checking for the reason on why 30 cores does not work, please set up the FTP so I can upload the file.

Nill
AM
Arjen Markus, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others... (Answer)

Jedi Knight Posts: 223 Join Date: 1/26/11 Recent Posts
Nill,

You should be able to "chain" these statistical operations. There are two limitations I can think of:
- The names of any output parameters have a limited length (20 characters)
- The input for an operation must be available, so you need to take care of the ordering

The FTP account:

Host name = ftp.deltares.nl
Ftp account = cores
Password = bbai789
Expires = 2015-07-02
Capacity = 10 Gb

The URL representation of the account, e.g., for use in a browser, is:

ftp://cores:bbai789@ftp.deltares.nl

Regards,

Arjen
NN
Nill Ng, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others...

Youngling Posts: 23 Join Date: 4/16/15 Recent Posts
Arjen,

I have uploaded the WQ model files to the server.
Please have a try.
My connection to the FTP site is not quite stable and it took me very long period of time for the upload.

By the way, I am trying to prepare observation area (.dmo) file in another project following the template stated in the WAQ manual.
My purpose is to determine the flushing time of tracer from certain region of a fine grid model.
Previously I though of using the tracer functionality of the FLOW module. Yet the number of observation points required higher than the upper limit of the FLOW module.
So I try the inert tracer in the WAQ module.
To minimize the massive postprocessing required to export and organize the results of a few hundred timeseries dataset, I would like to make use of the observation area function instead of observation point.
I would like to confirm whether the grid indices stated in the manual refer to the segment number or not.
Also the number of grid cells being taken into account is very high in my case.
Is there a limitation on the number of grid cells for each monitoring area?
The prepared .dmo file is attached for your information.

Thanks for your help.

Attachments:

AM
Arjen Markus, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others...

Jedi Knight Posts: 223 Join Date: 1/26/11 Recent Posts
Hi Nill,

I had a look at the dmo file - it should not be a real problem, with the possible exception of the last line: it seems to be incomplete. Some editors do not add an "end-of-line" character to the end of the file. I suggest you add an empty line at the end as quite possibly there will be a read error otherwise. The number of segments should be no problem.

Indeed, DELWAQ only knows about segments, not cells in the two- or threedimensional grid.

I will retrieve the files from the FTP server and we will have a look at what is going wrong. Not sure if I can report anything soon though.

Regards,

Arjen
AM
Arjen Markus, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others...

Jedi Knight Posts: 223 Join Date: 1/26/11 Recent Posts
Hi Nill,

I ran the calculation with 30 processors (well, threads, not separate processors) and it finished normally. The only thing I had to change was the initial condition, as the .ini file was missing. Maybe that makes a difference? Could you put that file on the FTP server too?

Regards,

Arjen
NN
Nill Ng, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others...

Youngling Posts: 23 Join Date: 4/16/15 Recent Posts
Arjen,

The multiple-core issue is not urgent; having 16 cores running in parallel is quite an improvement for me.

Regarding the issue of monitoring area file, I notice there is a way to prepare the .dmo file using DIDO module.
Since the previously prepared version of .dmo file does not works, so I prepare an updated version using DIDO as attached.
The problem with preparing .dmo file using DIDO is that when I look at the output history file, the output values do not seem right.
As my purpose of for this project is to evaluation the flushing of tracer from certain area of the model domain, I set up the monitoring area files to include areas that occupied by a fixed level (1000 kg/m3) of tracer in the initial condition.
Yet the level of tracer at the monitoring areas does not maximum out (1000 kg/m3) at the beginning of the model.
The level of tracer is zero at the most of the monitoring areas at the beginning, reaching it maximum a few hours or a few days later.
For certain monitoring areas, strange initial level of tracer is observed (of instant, one of the monitoring areas shows a initial tracer level of 2000 kg/m3) .
Also, the output water depth at these monitoring areas are strange too.
The modelled area is an embayment with maximum water depth around or below 50m.
Yet output water depth from the largest monitoring areas (consisted of a few hundred grid cells) reached 2970 m.
I have reviewed the output map file and the initial position of the tracer is correctly set.
So the only problem should be the .dmo file.
I have also tried to set up observation points one by one in all the grid cells within some of the smaller monitoring areas.
The results looks reasonable (i.e. all started with an initial tracer concentration of 1000 kg/m3).
But setting up observation points for all grid cells (a few hundreds) covered by all monitoring areas are way too demanding in terms of data postprocessing.
I also tried to have the coupling done for both "Remove inactive cell" and "No aggregation". Yet the results looks the same and are both not reasonable.
Would you be able to identify this problem as well?

Thanks,
Nill

Attachments:

CT
Christophe Thiange, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others... (Answer)

Jedi Knight Posts: 125 Join Date: 11/15/12 Recent Posts
Hi Nill,

When using monitoring areas consisting of more than 1 segment you need to specify how the results should be averaged (by segment surface, segment volume or just summed up).
Have a look at section 9 of the input file manual.

Best,
Chris
MC
Mathieu Chatelain, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others...

Padawan Posts: 28 Join Date: 12/13/12 Recent Posts
Hi Nill,
May i offer a little observation because I see quite large segment numbers in your DMO-file (e.g. 50,728).
From the segment numbers in your first observation area, I reckon that you have 5 layers and 11,816 segments per layers.

The DMO-file should only contain the segment numbers in the top layer. When creating a DMO-file with Dido, this is done automatically. Then, when importing the DMO-file into Delwaq GUI, the segment numbers of the underlying layers are automatically added and written in the INP-file.

You can either:
#1 remove the segment numbers from the layers 2 to 5. Your DMO-file can then be loaded in the GUI.
#2 leave the DMO-file as it is and include it directly in your INP-file, in block 2, by manual editing as:

9  ; number of monitoring points/areas (2 arbitrary points + your 7 areas)

obspt1 1 10
obspt2 1 3944

INCLUDE [your_relative_path]/PS.DMO


For #2, also make sure to remove the comments at the top of your DMO-file, and the number of areas. Header should look like:
; my observation areas
'LeungShuenWan' 5 8615 20431 32247 44063 55879
'MaNamWat' 15 3334 3463 3464 15150 15279 15280 26966 27095 27096 38782 38911 38912 50598 50727 50728
[...]


Hope this helps.
And, as Christophe recommended, specify a keyword (e.g. 'volume') for the HIS output (block 9) to make sure the results for observations areas are averaged (and not summed up).
Cheers,
-Mathieu.


EDIT: Before posting, I did not see that you also attached the DMO-file created by Dido. In that file, you can see that only the segment numbers in the top layer are reported.
NN
Nill Ng, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others...

Youngling Posts: 23 Join Date: 4/16/15 Recent Posts
Chris and Mathieu,

Noted on the keywords required for the input file.
The output tracer level does not exceed the maximum 1000 kg/m3 level now.
But the problem with monitoring areas still persist and the the locations of the monitoring areas are still incorrect
I notice the locations of monitoring areas are different from the corresponding locations of observation points input by GUI.
For instance, the observation point “LSW” is actually the same as the monitoring area “Leung Shuen Wan” which consist of only one grid cell.
Yet they have different segment number at all 5 different levels of the model.
The monitoring area “Local_8” are represented by a group of observation point “Local8_XX” (XX is two digit numbers).
Different segment numbers are also observed between “Local_8” and the corresponding observation point.
I notice the segment number for monitoring areas imported to the input file is the same as that generated using DIDO (in .dmo file attached in the reply dated 6/9/15 4:10 PM).
Yet for all kinds of coupling options (No aggregation / Use aggregation file (DIDO) / Remove inactive cells only), the segment number for monitoring areas imported to the input file remains the same.
The total number of segment should be reduced for the “Remove inactive cells” and the segment number for imported monitoring areas should decrease as well.
Attached are the input files for the three kinds coupling arrangements (No aggregation: PS_Dry_Tracer.inp; Use aggregation file (DIDO): PS_Dry_Tracer_.inp; Remove inactive cells only: PS_Dry_Tracer=.inp).
None of these input files show the correct segment number of the monitoring area.
Am I preparing the monitoring area using DIDO in a wrong way?

Regards,

Nill
MC
Mathieu Chatelain, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others... (Answer)

Padawan Posts: 28 Join Date: 12/13/12 Recent Posts
You need to prepare different DMO-files for all your 3 runs, since the Delwaq grid (and segment numbers) will be different for all 3 cases. Quite unfortunate, but that is how is works.
Now you are importing observation areas that haven't been defined on the correct Delwaq grid, and hence you get wrong numbering for the areas.

Steps in DIDO are the following:
  • Import the relevant MDF-file (to include thin dams and boundaries).
  • Import the DWQ-file, if appropriate.
  • Add observation areas by drawing polygons. (note: you can save them for re-use)
  • Export the DMO-file.

Repeat that operation for your 3 distinct cases. Issues with areas numbering should then resolve itself, hopefully emoticon
If not, please attach LGA and CCO-files to this thread.
Cheers,
-Mathieu.
NN
Nill Ng, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others...

Youngling Posts: 23 Join Date: 4/16/15 Recent Posts
Mathieu,

Thank you for the instruction. I tried a lot of combinations in DIDO, including:
(1) import grid only
(2) import MDF
(3) import grid, dry point and thin dam separately
Yet it seems there is no different between .dmo files generated from the above trial. The segment numbers in these .dmo files are the same.
Since my project is time-bounded, I eventually gave up with DIDO and manually prepare the .dmo file offline. That file works.

Thanks for your help and those from Chris and Arjen.

Regards,
Nill
MC
Mathieu Chatelain, modified 5 Years ago.

RE: Time and Depth Varying Boundary Condition and others...

Padawan Posts: 28 Join Date: 12/13/12 Recent Posts
(2) and (3) should indeed give you the same DMO-file.
The only case I can think of where (1) would give you the same results as (2) is if you do not have inactive cells in your observation area.
But glad to hear you managed to manually prepare a working DMO-file!
Good luck with the rest of your project,
-Mathieu.
NN
Nill Ng, modified 4 Years ago.

RE: Time and Depth Varying Boundary Condition and others...

Youngling Posts: 23 Join Date: 4/16/15 Recent Posts
Arjen Markus:
ad (3)
Of course, with depth-averaged parameters you lose the third dimension, but we decided against introducing yet another map file to specifcally store this type of output.


Arjen,

I have another thought.
Since the process of doing the statistics in stat map and stat mon file are both conducted after the completion of the modelling, this mean with the exception of depth-average statistics, all other statistics procedures can be separated from the modelling work itself.
Would it be more efficient to prepare separate programme(s) which generate stat map and stat mon file separately from the original map and mon file?

Regards,
Nill