running roms with debugger

Message

andreykoch · Mon Jul 09, 2007 5:47 pm

I compiled the ROMS with debug option "on". And I wonder, how to run it with debugger? What command should I use instead of oceanG <file> file.dat ? Thank you!

jcwarner · #2 Unread post by **jcwarner** » Mon Jul 09, 2007 6:06 pm

when you select the "debug option" , this activates different compiler flags to be used during the build. A common debug flag is "-g" or sometimes "/debug:full" or "/check:bounds" or something like that.
You can then just run ROMS as you normally would, but make sure to use the oceanG executable.

Additionally, there are other software programs that can be used to run the oceanG executable, such as Totalview or idb (intel debugger), etc. These other software programs may also want additional compiler flags when building the executable. You would need to read the documentation for the debugging program that you are running.

andreykoch · Mon Jul 09, 2007 8:40 pm

>You can then just run ROMS as you normally would, but make sure to use the oceanG executable.

Yes, I ran ROMS with executable oceanG, but I got the same effect, as I ran it without debug option "on". I do expect appearence of some environment like debugging window, don't it? Actually I run ROMS under Linux OS and don't have any additional dubugging software

jcwarner · #4 Unread post by **jcwarner** » Mon Jul 09, 2007 9:34 pm

You wont get an "environment like debugging window" from roms.
My experience is 2 ways:
1) just run oceanG. This often will give more description of errors/crashes, but not always.
2) Using another softwre such as totalview, and this will open a new window with many options.

kate · #5 Unread post by **kate** » Tue Jul 10, 2007 1:04 am

You will have to find out if any debuggers are available on your system. Some free options are gdb and ddd. I've never tried ddd, but I know it originally did not support Fortran. There may also be gui interfaces for gdb - I used to use xxgdb I think it was called. Ask your system guy if you have one. Totalview is a visual debugger but it costs extra. One great feature of totalview is that it can be used to debug parallel programs and it does understand modern Fortran.

If you are running without a debugger, the only thing oceanG will do better is have the symbols so that core files are potentially more useful. It might also check for out of bounds references in arrays if a -C flag was used. Other than that, it will just run more slowly with all the optimizations turned off. There are times when I go back to the optimized code and print statements.

stef · #6 Unread post by **stef** » Tue Jul 10, 2007 8:34 am

Hi!
I recently ran into troubles with segmentation faults and it was the first time that I tried the debug option. I'm using ifort on Linux. As m.hadfield suggested in another post, I also added a '-traceback' option the the '-g -check bounds' in the Linux-ifort makefile.

Now when I start oceanG, the output gives a hint on what's wrong:

Code: Select all

ps -forrtl: severe (408): fort: (2): Subscript #5 of the array T has value 2 which is greater than the upper bound of 1

Image              PC                Routine            Line        Source
oceanG             00000000008D76D0  Unknown               Unknown  Unknown
oceanG             00000000008D559E  Unknown               Unknown  Unknown

and some more of those oceanG... Number Unknown ... lines

I understand that I'm trying to access an index of t array that wasn't allocated, because I have undefined salinity. But do these lines also tell me *WHERE* the error is?

If not, do you think idb is a good thing to use? Do you know if it supports fortran 95 well? Will the output of idb contain more info than the lines above?

Thanks,
--Stefan

andreykoch · Tue Jul 10, 2007 3:59 pm

Hi Stefan!

Could you kindly provide a define form of a '-traceback' option and the '-g -check bounds' to be added in the Linux-ifort makefile. And where definetly it should be written, i.e. in what part of makefile

Thank you!

Andrey

stef · #8 Unread post by **stef** » Tue Jul 10, 2007 5:31 pm

Hi!
The post I was referring to is the one from Mon May 28, 2007 10:34 pm in:
viewtopic.php?t=538

There seem to be a lot of other posts on this topic, but I haven't read them yet...

m.hadfield · Wed Jul 11, 2007 3:00 am

Hi Stef

That traceback output is not as helpful as it could be! Perhaps ifort has another option that causes it to tell you more?

I have access to several different compilers on several different platforms and in situations like this I often switch to a combination that gives more info. I find g95 pretty good, with "-ftrace=full -fbounds-check".

Hmm, array T, subscript 5, that might well be the one associated with the tracer index, itrc. Most ocean simulations use two tracers, temperature and salinity. Are you doing a simulation with SALINITY undefined? There are probably some corners of the code that don't handle this correctly.

By the way, I debug by adding print statements, recompiling and rerunning. But I probably should invest the effort to learn how to use a debugger efficiently.

stef · #10 Unread post by **stef** » Wed Jul 11, 2007 7:38 am

Hi Mark!
Yes, I will read the manual for ifort to see what kind of options it has. I also will ask our sysadmin to install g95 and idb.

SALINITY is undefined. I think the error was caused by my altering the files over and over again and making some copy-paste error with emacs, because the error showed up suddenly although I haven't changed anything (willingly) concerning tracers. No big deal, I have a similar configuration that works. But anyways, I want to trace the error with those tools, so I learn how to use them. I also think that in the long run it's probably worthwile to take the effort. First I have to get them installed, though...

--stefan

nacholibre · Mon Sep 17, 2007 5:52 am

I've recently switched to ROMS 3.0 and I am trying to do the same run that I did with the previous version.

I copied the part from the cppdefs.h to a new header file. I modified the 'Upwelling' input file according to my previous input file. However, I get a segmentation error. I read the messages on the board and run it with DEBUG on. But I still need some help on interpreting the result.

It goes like this:

Thread # 0 (pid= 18738) is active.

Model Input Parameters: ROMS/TOMS version 3.0
Monday - September 17, 2007 - 12:50:24 AM
-----------------------------------------------------------------------------
forrtl: severe (408): fort: (2): Subscript #1 of the array IDSVAR has value 7 which is greater than the upper bound of 6

Image PC Routine Line Source
oceanG 085C85FC Unknown Unknown Unknown
oceanG 085C80F4 Unknown Unknown Unknown
oceanG 085A65C5 Unknown Unknown Unknown
oceanG 08579548 Unknown Unknown Unknown
oceanG 08579BFA Unknown Unknown Unknown
oceanG 084E29FA mod_ncparam_mp_in 1088 mod_ncparam.f90
oceanG 0836D6CB read_phypar_ 344 inp_par.f90
oceanG 0835E15B inp_par_ 58 inp_par.f90
oceanG 0804A9D2 ocean_control_mod 80 ocean_control.f90
oceanG 0804A8D1 MAIN__ 67 master.f90
oceanG 0804A878 Unknown Unknown Unknown
libc.so.6 002E7DE3 Unknown Unknown Unknown
oceanG 0804A731 Unknown Unknown Unknown

What does the IDSVAR refer to? Or am I missing a simple step?

Thanks a lot!

jcwarner · #12 Unread post by **jcwarner** » Mon Sep 17, 2007 2:05 pm

idsvar is with the Adjoint stuff. Are you running the adjoint?

nacholibre · Tue Sep 18, 2007 1:36 am

Mr. Warner,
When transferring my model from ROMS 2 to 3, I simply overlooked the fact that some of the parameters in mod_param.F are now included in the *.in input file. In order to prevent riffraff information, I wanted to delete my previous posting, but it was not possible. I tried to change my new posting subject to be helpful...
Thanks a lot!

PS. I am not sure if IDSVAR is related to adjoint. Did you mean ISDVAR maybe? We might need to edit our posting accordingly maybe?

Ocean Modeling Discussion

running roms with debugger

running roms with debugger

running ROMS with debugging

debug option

from ROMS 2 to ROMS 3