#if DEBUG or diag_on_off

[kslong]

We have two separate mechanisms for switching on code for diagnostica purposes

We have a variable called diag_of_off (in python.h) which is used in the following places:
diag.c:// diag_on_off = 0; // 0=off everything else is on
estimators.c: if (diag_on_off == 1 && ncstat > 0)
extract.c: if (diag_on_off && 1545.0 < 2.997925e18 / pp.freq
python.c: rdint ("Extra.diagnostics(0=no)", &diag_on_off);
python.c: if (diag_on_off)
python.c: if (diag_on_off)
radiation.c: if (diag_on_off == 1 && ncstat > 0)
trans_phot.c: if (diag_on_off && plinit == 0)
trans_phot.c: if (diag_on_off)

This is turned on through a rdint in python.c.

Then we have:

if DEBUG

which is used in the following places:

get_atomicdata.c:#if DEBUG
gradv.c:#if DEBUG
python.c:#if DEBUG
trans_phot.c: /* 05jul -- not clear whether this is needed and why it is different from DEBUG */
trans_phot.c:#if DEBUG
which is a compile time option, depending on how the DEBUG variable is set in python.h

We should agree on one of these options and eliminate the other. At the same time, my guess is we can eliminate some of the lines surrounding these statements altogether. This question is related a bit to the question of how we want to handle hidden code that we might not want to expose to a general user community.

[jhmatthews]

The diag_on_off variable is used, at least fairly regularly, when we want to look at photon stats and also save wind files each cycle. This can be used for diagnostics of actual physics and I think it's useful/

The DEBUG compilation flag can possibly be eliminated. Perhaps the -d flag on runtime could control a global variable for debugging- not just in the new Debug statements? I also think compilation flags are sort of a bad way to do this anyway.

The point I guess is that it would be nice to have a separate debug of some kind to 'diagnostics', which might feasibly be used by an advanced user. I'm not particularly bothered if we don't have a debug kind, but the extra_diagnostics should remain, possibly with future improvements (the sort of advanced mode diagnostics we talked about in the last meeting).

[kslong]

Right now in dev, I've used DEBUG to "comment out" the Compton torus. It would of course be easy to use -d to control this if that is what we think is best.

[jhmatthews]

I've created a test version for implementing an 'advanced mode' in Python. This way we would dispense with both DEBUG and diag_on_off. Instead the user would do something like the following at the end of the pf file:

Use.advanced.mode(1=yes)    1
keep_ioncycle_windsaves(1=yes)     1
save_cell_statistics (1=yes)     1

In this example, the user would then be asking to save windsave files after each cycle and save photon statistics in each cell. They can specify as few or as many allowed options as they like, and if advanced mode is 0 then it won't look for any.

These are read in and set as global variables in python.h, allowing us to control various diagnostic procedures from here. It would also allow more flexibility in future- say if an advanced user wanted to turn off certain things, or adjust the grid.

The code I've implemented, which is not robustly tested or merged but does work in beta, can be viewed in this commit: jhmatthews@5f934de

Would be good to know if people think this is sensible: @kslong, @Higginbottom @lazygun37

[Higginbottom]

I'm a big fan of this approach.

[kslong]

It’s not clear to me how this handles a variable that appears in the middle of the .pf file, e.g the compton torus which is now accessible only through a command line switch. At some level a command line switch seems to me most flexible …. But one issue about it is that we then need to make sure all of the “advanced” variables have an “off” option. Knox

[jhmatthews]

While we're on this topic, why do we still use the function mytrap() - I think this should be deleted as it offers no info to the user, an Debug/Error/Log offer more than enough options for reporting.

Also, just to make a record, we decided in a telecon that we could to the following:

• The -d flag will, for the moment, allow a load of advanced options to be specified in the pf file
• #DEBUG will be removed
• This solution will probably need to be adapted, but this is our philosophy: a command line flag that gives access to more parameter options.

[kslong]

The point of mytrap was to allow one to use a debugger and force the program to stop easily at a fixed position. I don’t really know whether it is a good idea to delete it or not, but I don’t think there should be any calls to it right now. My bigger problem right now is that I don’t have a good gui based debugger that works on Macs, since ddd no longer works there given that they removed In the absence of a decent gui-based front end for a debugger my_trap may remain useful.

I suggest we check for any calls to mytrap and remove them or convert them to additional outputs …. With a strong preference for removing them as I don’t think any should be left over of a long time. Then I suggest you put a note on my_trap which says that use of it is deprecated or something.

Knox

[jhmatthews]

This is closed by #120 - detailed/advanced mode