running roms with debugger

Discussion on computers, ROMS installation and compiling

Moderators: arango, robertson

Post Reply
Message
Author
andreykoch

running roms with debugger

#1 Unread post by andreykoch »

:?: 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
Posts: 1172
Joined: Wed Dec 31, 2003 6:16 pm
Location: USGS, USA

#2 Unread post by jcwarner »

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

running ROMS with debugging

#3 Unread post by andreykoch »

>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
Posts: 1172
Joined: Wed Dec 31, 2003 6:16 pm
Location: USGS, USA

#4 Unread post by jcwarner »

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.

User avatar
kate
Posts: 4088
Joined: Wed Jul 02, 2003 5:29 pm
Location: CFOS/UAF, USA

#5 Unread post by kate »

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
Posts: 175
Joined: Tue Mar 13, 2007 6:38 pm
Location: Independent researcher
Contact:

#6 Unread post by stef »

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

debug option

#7 Unread post by andreykoch »

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
Posts: 175
Joined: Tue Mar 13, 2007 6:38 pm
Location: Independent researcher
Contact:

#8 Unread post by stef »

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...

User avatar
m.hadfield
Posts: 521
Joined: Tue Jul 01, 2003 4:12 am
Location: NIWA

#9 Unread post by m.hadfield »

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
Posts: 175
Joined: Tue Mar 13, 2007 6:38 pm
Location: Independent researcher
Contact:

#10 Unread post by stef »

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
Posts: 81
Joined: Thu Dec 07, 2006 3:14 pm
Location: USGS
Contact:

#11 Unread post by nacholibre »

I've recently switched to ROMS 3.0 and I am trying to do the same run that I did with the previous version.:D 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? :oops:
Thanks a lot!

jcwarner
Posts: 1172
Joined: Wed Dec 31, 2003 6:16 pm
Location: USGS, USA

#12 Unread post by jcwarner »

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

nacholibre
Posts: 81
Joined: Thu Dec 07, 2006 3:14 pm
Location: USGS
Contact:

from ROMS 2 to ROMS 3

#13 Unread post by nacholibre »

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?

Post Reply