ABINIT Discussion Forums

Hi,

when I build abinit with enable_debug=yes, the current behavior is to print to the log file (std_err, I guess) a statement when a routine is entered, and a statement when it is exited. For example, m_paw_numeric.F90:824 : enter and m_paw_numeric.F90:875 : exit.

I am currently trying to debug (again! I don't know who or how broke the code) the parallel part of berryopt with PAW, and when running a simple test calculation, the log file is over 1.5 GB in size. It contains for example 47.8 million references to m_paw_numeric. I don't think this is always helpful (sometimes it is of course) and it is making the test calcs take forever. Is there a way to control this behavior globally?

thanks,
Joe

Hi,

The way I do is to configure with the enable_debug="yes,enhanced,..." flag and compilte abinit.
Then I just open the config.h file and comment the #define ENABLE_DEBUG 1 line.
I "touch" paw_numerics module (or whatever module bothering you) and compile again so the DBG_ENTER and DBG_EXIT are not defined anymore.
That trick allows to control which file/module/routine uses the DEBUG verbosity.
Then if you are debuging a routine that needs this macro, don't forget to uncomment the line in the config.h file so the next time you compile your routine it still has the debug verbosity.

Also you could maybe use the fcflags_opt_repertoirename (eg fcflags_opt_62_ctqmc) variable in you .ac file and add the -UENABLE_DEBUG flag to it.
That should undefine the macro for the corresponding directory only.

Hope that helped.

Jordan

Thanks, Jordan, those are good ideas. What I'm doing now is "enable_debug = no", "enable_optim = no", and then adding FCFLAGS and CFLAGS that do the job like "-O0 -g -fbounds-check". But I think the project needs a better solution. When a simple "enable_debug = yes" triggers 1.5 GB of output, it's really not useful.

Joe

If the trick proposed above is too much work, you can add

right after

and before

in any file/module/routine that is too talkative

And then feel free to configure with enable_debug=yes,... and compile as usual.

But yes, I agree with you, this sentinel can be awkward !

Jordan

Hi all,

I usually use DEBUG_MODE in a slightly different mode. First of all, I do not enable ENABLE_DEBUG in the
compilation, then I enable the sentinel on a per file (per module) basis by just adding

#defined DEBUG_MODE

#include "abi_common.h"

at the beginning of the file (module) so that all the procedures included in the file (module) will call the sentinel when entering/exiting.

When I have to debug the code without the help of a debugger, I usually have some idea
on the interested routines and I enable the debug mode only in these files.

I agree with Joe that ENABLE_DEBUG is not useful if it produces tons of Gigabytes.
I can easily change the code in m_errors so that we reduce to amount of output, we only have to specify some kind of
policy in terms of the numerical value of DEBUG_MODE e.g.

#ifdef DEBUG_MODE
#if DEBUG_MODE == 1
/* standard debugging level, call the sentinel every 20 procedure calls */
#elif DEBUG_MODE == N
/* Very verbose mode, call sentinel at every enter|exit */
...
#endif

Best,
Matteo

This is a good idea, maybe one should consider a full verbosity for high level routines whereas a low verbosity is needed for low level routines
That is to say, e.g. dirs >70 always states de debug sentinel and dirs <70 call the sentinel once every X calls.

What do you think ?

Jordan

We could indeed use a heuristic based of the frequency of calls to a routine during a run, for which what you propose is a good approximation.