CFD Online Discussion Forums - Inactive debug switches for fvOption SemiImplicitSource

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Bugs (https://www.cfd-online.com/Forums/openfoam-bugs/)

- - Inactive debug switches for fvOption SemiImplicitSource (https://www.cfd-online.com/Forums/openfoam-bugs/140992-inactive-debug-switches-fvoption-semiimplicitsource.html)

Inactive debug switches for fvOption SemiImplicitSource

I seem to be unable to report an issue with the mantis system. However, I post the information here, and will report it later, unless someone has an alternative explanation.

When I run the injection tutorial case from the twoPhaseEulerFoam tutorials and I add the following lines to controlDict no debug information is printed:

Code:

DebugSwitches

{

    scalarSemiImplicitSource    1;

    vectorSemiImplicitSource    1;

}

In the injection case both options are active, thus, I expect some debug information.

The class SemiImplicitSource contains some debug output like this:

Code:

    if (debug)

    {

        Info<< "SemiImplicitSource<" << pTraits<Type>::typeName

            << ">::addSup for source " << name_ << endl;

    }

in the method void Foam::fv::SemiImplicitSource<Type>::addSup()

The file semiImplicitSource.C contains the following "macro call"

Code:

makeFvOption(SemiImplicitSource, scalar);

The file makeFvOptions.H defines the called macro:

Code:

#define makeFvOption(Option, Type)                                            \

                                                                              \

    defineTemplateTypeNameAndDebugWithName                                    \

    (                                                                         \

        Option<Type>,                                                         \

        #Type#Option,                                                         \

        0                                                                     \

    );                                                                        \

                                                                              \

    option::adddictionaryConstructorToTable<Option<Type> >                    \

        add##Option##Type##dictionary##ConstructorTooptionTable_

The part of the code I suspect is:

Code:

#Type#Option

which is the stringification of both Type and Option. When called (with Type=scalar, Option=SemiImpicitSource)
the macro argument is

Code:

"scalar""SemiImplicitSource"

Compiling the file semiImplicitSource.C with the g++ option -E we gain the output of the preprocessor.

The macro

Code:

makeFvOption(SemiImplicitSource, scalar);

expands to

Code:

template<> const ::Foam::word SemiImplicitSource<scalar>::typeName("scalar""SemiImplicitSource");

template<> int SemiImplicitSource<scalar>::debug(::Foam::debug::debugSwitch("scalar""SemiImplicitSource", 0));

option::adddictionaryConstructorToTable<SemiImplicitSource<scalar> > addSemiImplicitSourcescalardictionaryConstructorTooptionTable_;

Here we also see the argument "scalar""SemiImplicitSource"

I wonder why there is no compiler error message, however, the debug switch does not work.

I think

Code:

#Type#Option

needs to be replaced with

Code:

Type##Option

as ## concatenates arguments instead of stringifying them.

Greetings Gerhard,

Fortunately there is no bug, but in fact it's a missing feature.
The problem is that the flags defined in the case's "system/controlDict" only work in some situations. In this situation, you will need to define it at the level of the global "controlDict" or similar, such as:

Code:

$HOME/.OpenFOAM/2.3.x/controlDict

As for cases where it works or not, I found the following comment on this bug report: http://www.openfoam.org/mantisbt/view.php?id=640#c2737

Quote:

Originally Posted by mattijs

The DebugSwitches entry in the case controlDict is pretty good (for non-templated classes). See e.g.
http://www.openfoam.org/version2.2.0...me-control.php

Therefore, the problem is in fact that this will not work for templated classes, such as "SemiImplicitSource".

As for your suggestion of using "Type##Option" instead of "#Type#Option", that's incorrect. The interpretation of the two is as follows:

"Type##Option" means that the resulting macro generated code will be a concatenation of the names defined for each macro:

Code:

scalarSemiImplicitSource

without any quotes. This would be interpreted as being code and not text.
"#Type#Option" means that the content of the two macro variables are to be converted to text:

Code:

"scalar""SemiImplicitSource"

which the compiler will in turn automatically concatenate and convert to:

Code:

"scalarSemiImplicitSource"

:)

Best regards,
Bruno

Quote:

Originally Posted by wyldckat (Post 508535)

Greetings Gerhard,

As for your suggestion of using "Type##Option" instead of "#Type#Option", that's incorrect. The interpretation of the two is as follows:

"Type##Option" means that the resulting macro generated code will be a concatenation of the names defined for each macro:

Code:

scalarSemiImplicitSource

without any quotes. This would be interpreted as being code and not text.
"#Type#Option" means that the content of the two macro variables are to be converted to text:

Code:

"scalar""SemiImplicitSource"

which the compiler will in turn automatically concatenate and convert to:

Code:

"scalarSemiImplicitSource"

:)

Best regards,
Bruno

My guess was that the macros that create all this debug run-time magic need to get the data type passed instead of a string.

I will take another close look and compare the workings of the pre-processor magic with non-templated and templated classes.

Anyway, I will post my findings when I had a look.

Some time ago I took a look at the non-templated macro magic of the SchillerNaumann drag model class, see the attached pdf.

There the macro

Code:

/* Layout-provided Styles */ div.standard { margin-bottom: 2ex; }defineTypeNameAndDebug(SchillerNaumann, 0);

is with the type name un-stringyfied, this leads me to the assumption, that in the templated case, the macro should also be provided with the unstringyfied type name.

The macro above is defined as

Code:

        /* Layout-provided Styles */ div.standard { margin-bottom: 2ex; }      //- Define the typeName and debug information 

  #define defineTypeNameAndDebug(Type, DebugSwitch)                             \

      defineTypeName(Type);                                                     \

      defineDebugSwitch(Type, DebugSwitch)

after some further macro expansion we end up with

Code:

       /* Layout-provided Styles */ div.standard { margin-bottom: 2ex; }      defineTypeNameWithName(Type, Type::typeName_()) 

       /* Layout-provided Styles */ div.standard { margin-bottom: 2ex; }      int Type::debug(::Foam::debug::debugSwitch(Name, DebugSwitch))

       /* Layout-provided Styles */ div.standard { margin-bottom: 2ex; }      registerDebugSwitchWithName(Type, Type, Type::typeName_())

The argument Type is needed to correctly address namespaces and datatypes.

However, I still have to look more closely into the templated stuff.

Hi Gerhard,

The ability to also control the debug flags for template classes has been implemented in the OpenFOAM-dev repository: https://github.com/OpenFOAM/OpenFOAM-dev/

It was implemented in this commit: https://github.com/OpenFOAM/OpenFOAM...09b8cb4b967baa

Best regards,
Bruno

Hi Bruno,

thanks for the hint.

Allow me a related off-topic question.

Is the OpenFOAM-dev repo something new or newly made public? I started noticing links and references to this repo a few month ago.

Cheers Gerhard

Quote:

Originally Posted by GerhardHolzinger (Post 537773)

Is the OpenFOAM-dev repo something new or newly made public? I started noticing links and references to this repo a few month ago.

Quick answer: OpenFOAM-dev repo was started soon after OpenFOAM's 10th year anniversary: