Message Boards

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

Nill Ng, modified 8 Years ago.

Time and Depth Varying Boundary Condition and others...

Youngling Posts: 15 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
Arjen Markus, modified 8 Years ago.

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

Jedi Knight Posts: 219 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.
Nill Ng, modified 8 Years ago.

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

Youngling Posts: 15 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.
Arjen Markus, modified 8 Years ago.

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

Jedi Knight Posts: 219 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
Arjen Markus, modified 8 Years ago.

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

Jedi Knight Posts: 219 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.
Nill Ng, modified 8 Years ago.

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

Youngling Posts: 15 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.
Arjen Markus, modified 8 Years ago.

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

Jedi Knight Posts: 219 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.
Arjen Markus, modified 8 Years ago.

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

Jedi Knight Posts: 219 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.
Nill Ng, modified 8 Years ago.

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

Youngling Posts: 15 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.
Arjen Markus, modified 8 Years ago.

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

Jedi Knight Posts: 219 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).
Nill Ng, modified 8 Years ago.

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

Youngling Posts: 15 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
Arjen Markus, modified 8 Years ago.

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

Jedi Knight Posts: 219 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
Nill Ng, modified 8 Years ago.

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

Youngling Posts: 15 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:

Arjen Markus, modified 8 Years ago.

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

Jedi Knight Posts: 219 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
Arjen Markus, modified 8 Years ago.

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

Jedi Knight Posts: 219 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
Nill Ng, modified 8 Years ago.

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

Youngling Posts: 15 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:

Nill Ng, modified 8 Years ago.

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

Youngling Posts: 15 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