I have compiled the delft3d codes (7545) on my computer,
with the OS being fedora 16 x86_64 and the GNU 7.4.0 compiler for c,
c++, and fortran. I was trying to run all the test cases in
delft3d_repository/examples, and an error occured when I was runing
the 06_delwaq. To be specific, when I was running the run_delwaq.sh
(under the path delft3d_repository/examples/06_delwaq/), an error
occured and the message went like:
The input file is "com-tut_fti_waq.inp" . To fix this,
should I just edit the "com-tut_fti_waq.inp" file? or do I
have to re-compile all the delft3d codes? Could anyone please help me?
The odd thing is that that example runs fine on our machines - using
the GNU compilers. The message does not include much information on
where in the program things went awry, but it does say that the core
was dumped. Do you have a file called "core"? What happens
if you run delwaq2 via the debugger (gdb)? In case you do not know how
to do this:
go to the directory where you ran the calculation
start the command "gdb delwaq2". delwaq2 will either start
and ask for the name of the input or gdb will show that it crashed
before - using the core file - and should then be able to show a bit
more on the cause of the crash. The command "where" will
then list in detail (if we are lucky ;)) where in the program the
problem occurred/was detected.
Thank you very much for your timely reply.
I tried to debug the delwaq2 following the method you suggeted. No
progress is achieved yet, mainly because I am not familiar with the
GDB tool. I will keep trying. Once I solve the problem, I would like
to let you know.
I really appreciate your help.
It should be simple: instead of starting "delwaq2" via the
script, you start "gdb delwaq2" - but of course, I have a
few years' experience with such stuff. I have adjusted the run script
a bit - see attachment to give you some more instructions. However,
when I tried this myself, there still was not much more information in
the traceback. If that is the case for you as well, we will have to
take more drastic measures, I am afraid.
Thank you for the detailed instruction. I ran the bash script you
sent me, and the debuging information is below (start at the line 47
of the script):
I don't know how to fix this according to these information. Maybe
I should learn more about the GDB tool. Given that the delft3d model
works well on your PC with GNU compilers, what if I install all the
binaries and compilers, with all the version numbers being same with
yours? Currently, the version number of all the binaries and GNU
compilers on my PC are:
(1) for gcc installation
gcc-7.4.0.tar.gz, gmp-4.3.2.tar.bz2, mpc-0.8.1.tar.gz, mpfr-2.4.2.tar.bz2
(2) for expat-devel installation
(3) for netcdf installation
(4) for mpich installation
(5) for uuid-dev installation
If possible, could you please provide the version numbers of all
the binaries and compilers you used?
Thanks a lot!
It took me a while to realise what was happening. Okay, the script
first runs delwaq1 to process the input. Then - via the debugger - it
runs delwaq2. Because it got no argument, it will ask about the name
of the input file and you gave it a name. Apparently there was
something wrong with that name and therefore the program stopped. That
is also why there is no trace - there is no process (program) to examine.
Be sure to give it the same name as for the run script itself. In the
meantime I am trying to assemble the information about the compiler we
normally use. That may take a while and tomorrow I have no
oppportunity to try and work out any answers.
I was assured that this testcase/demo worked fine, but now that I try
it myself, I get a crash in delwaq1. So there definitely is something
strange going on. I will have a closer look - this was a red herring,
Okay, I found the culprit - if you do an update of your source code
and re-build Delft3D, it should now work
Dear Arjen Markus,
I was few days off these days, and I feel sorry for not
replying you during these days. Your replies are very informative.
However, I am still confused, below is my point-by-point response
to your replies.
Your reply 1:
My response 1: In my understanding, it seems that the input
files of both delwaq1 and delwaq2 are the file named
“com-tut_fti_waq.inp”, based on the "run_delwaq.sh"
script. To be specific, there is a line in
"run_delwaq.sh" which goes like:
$exedir/delwaq1 $argfile -p "$procfile"
where the $argfile in my computer is
If the "com-tut_fti_waq.inp" was created by delwaq1, the
removal of "com-tut_fti_waq.inp" from current directory
should not prohibit the execution of delwaq1. However, when the
"com-tut_fti_waq.inp" was removed from the current
directory, running of the run_delwaq.sh would be accompanied by
the errors below:
Therefore. I do not think the input of delwaq2 was created by
delwaq1. Otherwise, an odd thing would occur, that is, based on the
exactly same input file (
com-tut_fti_waq.inp), delwaq1 ran well while
delwaq2 did not. So I guess the error lies in the progress when
compiling the delwaq2.
My response 2: I do not know why a crash occurred when you were
running delwaq1. In my computer, I ran delwaq1 well. The real problem
lies in the delwaq2. This is quite strange.
My response 3: do you mean that you have found source of the errors
in delwaq2? You suggested that I should update my delft3d source code.
The current version I am using is 7545, which is the newest version at
the URL: https://svn.oss.deltares.nl/repos/delft3d/tags/delft3d4/.
I am confused, which version should I use? Could you please tell me
the exact delft3d version you are using to avoid the delwaq2 error?
The first part of my reply had to do with running delwaq2 via the
debugger. There is no need anymore to do that - I have been able to
run the programs via the debugger myself, after building with gfortran.
When I did this, I found a mistake in the code which caused the
behaviour. It was however in the first part, delwaq1, that things went
wrong on my machine. I see that your situation is slightly different:
delwaq1 runs fine, but delwaq2 crashes. I suspect they have to do with
the same thing, but as the behaviour was different between our
machines, I cannot be sure.
The code you are using is from a specific tag. You can also update
the code to the trunk - that is where I put the improvement.
Please let me know if with this updated code (from the trunk, not the
tag) solves the problem.
I will try to update the code from the trunk. I would like to let you
know if any progress is achieved.