[Opm] Suggestion: new debug configuration
Joakim Hove
joakim.hove at opm-op.com
Thu Jun 3 10:32:19 UTC 2021
Hi;
thank you Atgeirr for chiming in. We agree on many points - and
hopefully we can find good solution also for the points where we have
not yet agreed. I think the min point of disagreement - or just
different perception is how tightly the not-yet-existing debug
configuration should be integrated with the logging system. Your
suggestion implies a quite tight integration, whereas I had envisioned a
much looser - more bolted on approach.
On 6/3/21 11:17 AM, Atgeirr Rasmussen wrote:
> - I think that the default configuration should print something useful.
Something useful always sounds good; if we agree that the default
configuration should output "something" I hope we can configure that by
setting the default levels to nonzero values, i.e. to always get PVT
debugging:
struct DebugConfig {
xyz_debug = 0;
pvt_debug = 1;
abc_debug = 0;
}
> - It should also be possible to turn off and on via the command line. The full flexibility of the keyword, especially changing it in the schedule, will not be available on the command line.
I understand - one possibility was that the command line would take
presedence over the DEBUGF keyword in the RUNSPEC section, but that
DEBUGF keywords in the SCHEDULE section had top priority.
> - The proposed code changes are somewhat intrusive. It is not clear how this configuration is passed around.
Well - the simulator would get this from the Schedule object:
const auto& debug_config = sched[report_step].debug_config()
if (debug_config.well_debug > 0) {
...
}
> - I think the existing code should work as before, until explicitly changed.
Always a good plan. The way I have pictured this the current output to
the debug file will be initially unchanged; i.e.
_current code:_
OpmLog::debug("Wells are difficult today");
_new code:_
if (debug_config.well_debug > 0)
OpmLog::debug("Wells are difficult today");
So before the code is sprinkled with if (debug_config.xxx_debug) the
output will be totally unchanged.
>
> I propose that we attach a DebugConfig (and perhaps name it LogVerbosityConfig) to each logging backend (different for each is possible). Then we add new overloads for the logging function.
>
> Example of existing logging function:
> static void debug(const std::string& message);
>
> Example of new function:
> static void debug(const MessageCategory cat,
> const MessageVerbosityLevel level,
> const std::string& message);
My plan was a much weaker integration between the new DebugConfig and
the existing log configuration. I agree that my proposed solution is not
ideal; I might even agree that your solution is better from an
"end-developer" perspective, but I do fear it is going to be a really
complex and ugly implementation. The logging system is a
time-independent Singleton - whereas the natural way to manage a time
dependent configuration like the suggested DebugConfig - is through the
Schedule class - coupling the two through some kind of statefull back
channel seems very iffy from an implementation point of view.
> ________________________________
> From: Opm <opm-bounces at opm-project.org> on behalf of Joakim Hove <joakim.hove at opm-op.com>
> Sent: 03 June 2021 10:39
> To: opm at opm-project.org <opm at opm-project.org>
> Subject: [Opm] Suggestion: new debug configuration
>
> Fellow opm'ers;
>
> we would like to suggest a new system for controlling and configuring
> debug information. The plan consists of both a change affecting the end
> users with a new keyword - e.g. DEBUGF - and updates to the code at
> callsites.
>
> _
> _
>
> _Keyword DEBUGF_
>
> The new keyword should be modelled after e.g the RPTSHCED keyword with
> use of mnemonics:
>
>
> RUNSPEC
>
> DEBUGF
>
> INIT=1 /
>
> ...
>
> SCHEDULE
>
> -- Turn on the PVT debugging (default level)
>
> DEBUGF
>
> PVT /
>
>
> DATES
>
> 10 'MAI' 2020 /
>
>
> -- Turn on maximum debugging of wells, debug level 1 for groups and
> turn off the PVT debugging.
>
> DEBUGF
>
> WELL=3 GROUP=1 PVT=0 /
>
>
> DATES
>
> 20 MAI 2020 /
>
>
> -- Turn off all debugging
>
> DEBUGF
>
> /
>
>
> Some points/thoughts:
>
> 1. As indicated the keyword can be both in RUNSPEC section and the
> SCHEDULE section - the latter is important to turn debugging on and off.
> 2. The set of mnemonics is quite relaxed - this should be developer
> centric and it should be simple to add more mnemonics.
> 3. In the default configuration with no DEBUGF keyword in the deck the
> .DBG output file should be empty.
> 4. ...
>
>
> _Changes to code:
> _
>
> The DEBUGF keyword should be internalized to datastructure looking
> something like this:
>
> struct DebugConfig {
>
> int well_debug = 0;
>
> int group_debug = 0;
>
> pvt_debug = 0;
>
> ....
>
> };
>
> Such DebugConfig reference should be passed around in the simulator (and
> other places), and then every debug call should be protected in C++
> code as:
>
> if (debug_config.well_debug > 0) {
>
> OpmLog::debug("The wells are difficult today");
>
> if (debug_config.well_debug > 3)
>
> OpmLog::debug( lots_of_details_about_problematic_well );
>
> }
>
>
> Observe that:
>
> 1. The actual printing to the debug file will still be handled with
> OpmLog::debug() calls.
> 2. The system with DebugConfig will add to the debug configuration from
> OpmLog - maybe not 100% logical but hopefully not too bad.
>
>
> Bring on the critque and suggestions!
>
>
> Joakim
>
>
>
>
>
>
>
>
> __
>
> __
>
>
>
>
>
>
> --
> OPM-OP AS
> Heyerdahlsvei 12b, 0777 Oslo, Norway
> Joakim Hove
> CEO
> T: +47 92 68 57 04
> E: joakim.hove at opm-op.com
>
> _______________________________________________
> Opm mailing list
> Opm at opm-project.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopm-project.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopm&data=04%7C01%7CAtgeirr.Rasmussen%40sintef.no%7Cdfacd4ea185444bb9e1308d9266b208d%7Ce1f00f39604145b0b309e0210d8b32af%7C1%7C0%7C637583063834294959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2%2Fbf9ri3Tx9%2FKHPaXeXWyoPZMCO3%2FGOh6z66joPFe5o%3D&reserved=0
> _______________________________________________
> Opm mailing list
> Opm at opm-project.org
> https://opm-project.org/cgi-bin/mailman/listinfo/opm
--
OPM-OP AS
Heyerdahlsvei 12b, 0777 Oslo, Norway
Joakim Hove
CEO
T: +47 92 68 57 04
E: joakim.hove at opm-op.com
More information about the Opm
mailing list