[GerhardHolzinger]

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:

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:

    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"

makeFvOption(SemiImplicitSource, scalar);

The file makeFvOptions.H defines the called macro:

#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:

#Type#Option

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

"scalar""SemiImplicitSource"

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

The macro

makeFvOption(SemiImplicitSource, scalar);

expands to

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

#Type#Option

needs to be replaced with

Type##Option

as ## concatenates arguments instead of stringifying them.

[wyldckat]

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:

$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

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:
  

  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:
  

  "scalar""SemiImplicitSource"

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

  "scalarSemiImplicitSource"

Best regards,
Bruno

[GerhardHolzinger]

Originally Posted by wyldckat

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:
  

  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:
  

  "scalar""SemiImplicitSource"

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

  "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.

[GerhardHolzinger]

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

        /* 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

        /* 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

       /* 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.

[wyldckat]

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

[GerhardHolzinger]

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

[wyldckat]

Originally Posted by GerhardHolzinger

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:

• http://www.openfoam.org/mantisbt/view.php?id=211#c3316
• http://www.openfoam.org/mantisbt/view.php?id=256#c3317