RE: delwaq1 error reading block 5 - Forum - Delft3D-Old
Message Boards
RE: delwaq1 error reading block 5
delwaq1 error reading block 5
RE: delwaq1 error reading block 5
RE: delwaq1 error reading block 5
Jedi Knight Posts: 219 Join Date: 1/26/11 Recent PostsThe intriguing question however is how this came about. Did you change the underlying hydrodynamic model grid and then use an existing input file? That is one reason I can think of - the input file was created with the user-interface judging from the style, but then it would have maintained a consistency between these bits of information. So something else happened.
RE: delwaq1 error reading block 5
RE: delwaq1 error reading block 5
RE: delwaq1 error reading block 5
RE: delwaq1 error reading block 5
Jedi Knight Posts: 219 Join Date: 1/26/11 Recent PostsI would not expect this type of difficulties from a z-layers model. I know there are/have been problems with getting that right, but that is more on the side of mass balance errors and the like.
If this works (no aggregation at all), that would be great, otherwise we will have to dig into the cause of the trouble.
RE: delwaq1 error reading block 5
RE: delwaq1 error reading block 5
RE: delwaq1 error reading block 5
Jedi Knight Posts: 219 Join Date: 1/26/11 Recent Posts- The hyd-file
- The lga- and cco-files
- The pointer table (.poi)
Perhaps I will need more files later, but this should suffice to make a first step in the analysis.
RE: delwaq1 error reading block 5
RE: delwaq1 error reading block 5
RE: delwaq1 error reading block 5
RE: delwaq1 error reading block 5
Jedi Knight Posts: 219 Join Date: 1/26/11 Recent PostsRE: delwaq1 error reading block 5
Jedi Knight Posts: 219 Join Date: 1/26/11 Recent PostsIn this set-up each domain may have a different number of z-layers - that causes a different number of boundary cells, as the boundaries extend over some horizontal stretch as well as over the vertical. I assume that this is the case.
Now, since the overall hyd-file contains just a single number of layers, 10 in this case, the GUI decides that each boundary section stretches over 10 layers - independent of whether that is actually the case for the domain that section belongs to (in pathologically complicated cases, the boundary section could even belong to several domains at the same time, each with its own number of layers). This can not be helped - the GUI knows only the entire grid, not the individual domains.
The simplest solution is to make the z-layers the same for all domains. That may not be suitable for your modeling situation, though.
Another solution would be to make the number of z-layers the same for all domains - I am merely reasoning from the DELWAQ/Delft3D-WAQ point of view - I am not sure at the moment what the restrictions from Delft3D-FLOW are.
Yet another, but for that I need to examine things a bit more closely, is to fool DELWAQ into thinking there are enough boundaries, by adjusting the pointer table. It is mayhap the trickiest one, but from a modelling point of view the "best".
RE: delwaq1 error reading block 5
RE: delwaq1 error reading block 5
Jedi Knight Posts: 219 Join Date: 1/26/11 Recent PostsRE: delwaq1 error reading block 5
Jedi Knight Posts: 219 Join Date: 1/26/11 Recent PostsRE: delwaq1 error reading block 5
RE: delwaq1 error reading block 5
Jedi Knight Posts: 219 Join Date: 1/26/11 Recent PostsThe GUI sees 10 layers and 1389 boundary cells per layers and therefore writes 13890 boundary cells to the input file. But according to the pointer table there are only 11112 boundary cells. Hence the mismatch.
The solution I came up with is to replace one of the boundary cell numbers in the pointer table by the value 13890. That will satisfy the input processor DELWAQ1 (though you get a lot of informational messages about boundary cells not having actual effect). As the boundary cell which is treated in this way, is the cell with number 11112 (i.e. the cell in layer 8 which would be above the boundary cell 13890 in layer 10 if it were there), the effect on the calculation will be non-existent if the boundary condition is uniform over the vertical and negligeable if it does vary.
I have attached the corrected pointer table. To use it in the calculations, just replace the original name in the hyd-file by "corrected.poi" and regenerate the input file via the GUI. Or edit the input file directly - replace the name of the pointer table in there.
Please let us know if this still gives problems - I could not accurately test it (I lack a few files for that)
Attachments:
RE: delwaq1 error reading block 5
RE: delwaq1 error reading block 5
RE: delwaq1 error reading block 5
Jedi Knight Posts: 219 Join Date: 1/26/11 Recent PostsRE: delwaq1 error reading block 5
Jedi Knight Posts: 219 Join Date: 1/26/11 Recent Posts- It occurs with option 21 as well as option 15 (they both use the lsolve routine, but crash at a different location)
- It also occurs if I use the original pointer table and remove the offensive lines from the input (that would make a somewhat inconsistent set-up, but for this test that does not matter)
So the conclusion is that there is something fishy going on and we need to sort this out
RE: delwaq1 error reading block 5
RE: delwaq1 error reading block 5
Jedi Knight Posts: 219 Join Date: 1/26/11 Recent PostsWhat is more interesting is the fact that DELWAQ2 crashes in routines that have been in intensive use for many years now on a wide variety of models.
As for the last update of ddcouple: if a program works fine or seems to work fine and there are no new features to implement, it makes no sense to change the source code. This has been the case with ddcouple, though in february 2017 there was an enhancement regarding the options you can specify.
RE: delwaq1 error reading block 5
Jedi Knight Posts: 219 Join Date: 1/26/11 Recent PostsThe number of segments is much larger than the total number of exchanges in the horizontal. That mean that the segments are not all connected in the horizontal direction. The same holds for the vertical. Again the segments are not all connected in that direction. It means that the matrix that is set up using the exchanges is singular. Now the next question is: where is this coming from?
I noticed there is a large number of domains and the files are going to be big - but could you provide me with the raw files anyway - just two output times will suffice, like you did the other day.
RE: delwaq1 error reading block 5
Jedi Knight Posts: 219 Join Date: 1/26/11 Recent Posts- The number of domains is 111 - that is very large, this means you have very narrow elongated domains
- The grid cells in the river section are very narrow (down to half a meter, it seems) and elongated (10 meters orlonger). That is not recommended. Such small grid cells actually violate the assumptions underlying the numerical method in the FLOW model.
While the ddcouple program ought to be capable of handling so many domains, there is a tricky issue - each domain boundary has a number of "ghost cells" connected to it to enable transfer of information to the adjacent domain. These ghost cells should probably be not lie in more than two domains. With the very narrow domains we have seen now there is a remote chance that there is some overlap.
Could you try the hydrodynamic calculation with a smaller number of domains? Say, 20 domains instead of 111? The communication between all these domains is likely to consume quite a bit of computational time, so that 20 domains will probably not be that much less efficient than 111. With 20 domains there is certainly no risk of overlaps and we want to preclude that this is the cause of the strange issues we see now.
RE: delwaq1 error reading block 5
RE: delwaq1 error reading block 5
RE: delwaq1 error reading block 5
Jedi Knight Posts: 219 Join Date: 1/26/11 Recent PostsI can arrange for an FTP site - that may be easier to transfer large files (and access is restricted).
RE: delwaq1 error reading block 5
RE: delwaq1 error reading block 5
Jedi Knight Posts: 219 Join Date: 1/26/11 Recent PostsRE: delwaq1 error reading block 5 (Answer)
RE: delwaq1 error reading block 5
Youngling Posts: 13 Join Date: 7/7/15 Recent PostsHi, I am also having many issues when trying to run Delwaq in Linux after doing ddcouple in Linux. However, when doing ddcoupling in Windows, Delwaq runs properly in Linux, but the files are too big to copy them to Windows for the ddcoupling. Can you please provide me the most recent ddcouple version to check if it solves my problem?
Many thanks,
Amelia
Attachments:
RE: delwaq1 error reading block 5
Jedi Knight Posts: 128 Join Date: 1/21/13 Recent PostsHi Amelia,
Attached are the latest Windows and Linux ddcouple versions. I am not sure it this will help your problem. What I read from your screen is that the attributes file (atr) is to long. It continues to read a typical attribute value (31), while it should read the volume option (usually in the range of -1 to 4). It could be that you point to the wrong atr-file...
greetings,
Michelle
Attachments:
RE: delwaq1 error reading block 5
Youngling Posts: 13 Join Date: 7/7/15 Recent PostsHi Michelle, many thanks for sending the files. I have tried the Linux ones and you were right, it didn't solve my problem, I got exactly the same errors as before. I do not understand when you say that it could be pointing to the wrong atr file, as the atr file being used in inp file is the one created by running the ddcouple. I also do not understand how can I have too many data. Do you have any suggestions I can try, in order to solve my problem?
To be more clear, I am sending you attached the lsp file with the errors. The strange thing is that if I do the ddcouple in Windows, instead of Linux, then delwaq runs properly on Linux.
Thank you very much.
Amelia
Attachments:
RE: delwaq1 error reading block 5
Jedi Knight Posts: 128 Join Date: 1/21/13 Recent PostsHi Amelia,
I'm sorry, but my remark about the wrong atr file was merely a suggestion what might be wrong based on the little information that I have from your post, not that it was wrong. Some for the length of the file. With a new look at your screenshot, I think something is wrong in the inp-file, just after #2 in the file.
It would be better if you post the inp-file and the lst-file. That would give some more information. And I don't know what is the size of the atr-file, but that might be useful too.
Michelle
RE: delwaq1 error reading block 5
Youngling Posts: 13 Join Date: 7/7/15 Recent PostsHi Michelle,
yesterday I wanted to send you the lst file with the errors, but by mistake I have sent the lsp, sorry. Please find the inp, lst and atr files attached.
Thanks for your help,
Amelia
RE: delwaq1 error reading block 5
Jedi Knight Posts: 128 Join Date: 1/21/13 Recent PostsHi Amelia,
I don't know exactly why this goes wrong, but the GUI should have recognised the keyword 'DELWAQ_COMPLETE_ATTRIBUTES' at the top of the atr file, and the have left out some of the settings that are in this type of file (as written by ddcouple) that are not in single domain (sigma layer) atr-files. Attached a modified inp-file with the lines commented out around the mentioning of the atr file that the GUI should have left out:
; features
; 1 ; one time-independent contribution
; 1
; number of items
; 2 ; only feature 2 is specified
; 1 ; input in this file
INCLUDE
'com-Long_run_discharge_60_year2010_adjusted_BC2.atr' ; attributes
file
; 0 ; no time-dependent contributions
Hope this helps!
Michelle
Attachments:
RE: delwaq1 error reading block 5
Youngling Posts: 13 Join Date: 7/7/15 Recent PostsHi Michelle,
yes, the problem was definitely those lines, now Delwaq runs properly! I have been checking and those lines do not appear in the inp file when I did the ddcouple in Windows, and for that reason Delwaq was running in that situation. Although I still do not understand why those lines are created when I do ddcouple in Linux, I do not mind to comment the lines every time I run a Delwaq simulation. That will be much faster than copying all the files into my pc for doing the ddcouple in Windows!!
Many thanks for your help!
Regards,
Amelia