[Opm] Suggestion: new debug configuration

Thu Jun 3 10:36:37 UTC 2021

I second your support for a new keyword. Currently, the DBG-file has become less useful due to the amount of information emitted. I have no opinion on implementation details, but my suggestions for the overall functionality is the following:
-printing something useful sounds sensible, even if it is only basic information to the user about the file and how to enable more output.
-We already have too many user facing command line options, and this feature is for developers. Hence, my preference is to avoid command line options for it. If we do implement command line options, please only have one (for instance a debug level, or even a complex string, hiding the flexibility of the command line option in its value)
-please also take this opportunity to integrate the output of the INFOSTEP file into the DBG file, so that we can avoid the INFOSTEP-file

Cheers,
Alf

________________________________
Fra: Opm <opm-bounces at opm-project.org> på vegne av Atgeirr Rasmussen <Atgeirr.Rasmussen at sintef.no>
Sendt: torsdag 3. juni 2021 11:17
Til: opm at opm-project.org <opm at opm-project.org>
Emne: Re: [Opm] Suggestion: new debug configuration

Hi all,

I agree with Joakim that it is a good idea to add DEBUGF, and think that suggestion should be followed through. Some comments:
 - I think that the default configuration should print something useful.
 - 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.
 - The proposed code changes are somewhat intrusive. It is not clear how this configuration is passed around.
 - I think the existing code should work as before, until explicitly changed.

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);

In the above, MessageCategory enum can be Pvt, Wells, Groups and similar as you suggested, and the MessageVerbosityLevel is either an integer or an enum similar to your suggestion. (A version taking tags would also be added.)

Then your example call would be:

OpmLog::debug(Wells, 1, "The wells are difficult today");
OpmLog::debug(Wells, 3, lots_of_details_about_problematic_well);

In case we really need to get the verbosity level, to avoid doing expensive extra calculations for example, we could access it like this:

auto level = OpmLog::verbosityLevel(Wells);

which would return the maximum level across all active logging backends.

Atgeirr

________________________________
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%7Cabir%40equinor.com%7Ca655d76777a644eea59608d926707ab1%7C3aa4a235b6e248d591957fcf05b459b0%7C0%7C0%7C637583086819460621%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=f9aFLC89lOs2GqBhd9UiFlzPDMuu33T%2BzVI3ueh9hBU%3D&reserved=0
_______________________________________________
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%7Cabir%40equinor.com%7Ca655d76777a644eea59608d926707ab1%7C3aa4a235b6e248d591957fcf05b459b0%7C0%7C0%7C637583086819470573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xqqAe1mLvuEcPV3jyioEyDkYU4v2%2FF5Z%2FYVzjVuv9aE%3D&reserved=0

-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorized use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you