[Tobi]

Hi all,

I never got the point of the correct debug switch name that we can manipulate either global or local. In some particular cases it is obvious e.g. ODE solvers have the ODE or ODESolver debug switch. Lets assume we want to activate the debug output in the fvMatrix class e.g. to output the stuff in the relax(const scalar alpha) function. Right now, I was always checking the TypeName info to activate the debug output (this is also mentioned by sourceflux here http://www.sourceflux.de/blog/openfoam-debug-switch/). However, for the fvMatrix class there is actually no debug switch that I could figure out which is responsible for that class. I also went through older threads but there it was obvious which debug switch we should use.

In the following thread (Debug switch) it is mentioned that we build the debug switch using:

defineTypeNameAndDebug

However, for the fvMatrix class I cannot find any of them. I also checked the friend classes but without success and if, the debug switch for the fvMatrix was never activated. To be honest, there is no time for me to check it out so I would be very happy to have someone which can tell me the missing information because as far as I got it, the fvMatrix isnot in the debug switches, right?

[wwzhao]

Hello Tobias,

fvMatrix<Type> is a class template. I believe the debug switches are controlled by the specialization of fvMatrix<Type>, e.g., fvScalarMatrix, fvVectorMatrix and fvTensorMatrix etc. Examples can be found in $FOAM_ETC/controlDict.


Best,
Weiwen

[Tobi]

Hi Weiwen,

well that is really funny. So simple. I was thinking about the template character but I never searched for a fv<Type>Matrix debug switch in the controlDict. Thank you very much. That is the solution.

[Tobi]

Hi all,

I am facing again the same situation for the compressible::turbulentTemperatureCoupledBaffleMix ed boundary condition. In the source code, we find the debug switch:

    if (debug)
    {
        scalar Q = gSum(kappa(*this)*patch().magSf()*snGrad());

        Info<< patch().boundaryMesh().mesh().name() << ':'
            << patch().name() << ':'
            << this->internalField().name() << " <- "
            << nbrMesh.name() << ':'
            << nbrPatch.name() << ':'
            << this->internalField().name() << " :"
            << " heat transfer rate:" << Q
            << " walltemperature "
            << " min:" << gMin(*this)
            << " max:" << gMax(*this)
            << " avg:" << gAverage(*this)
            << endl;
    }

However, I cannot figure out which debug switch corresponds to that boundary condition. Any suggestion on how to proceed here? I still did not get the logic here.

[Andrew.Coughtrie]

Hi Tobi,

As far as I can tell in general the debug switch for a patchField is defined through the makePatchTypeField macro at the end of the .C file as you know.

so even though the debug switch for turbulentTemperatureCoupledBaffleMixedFvPatchScala rField isn't in the controlDict it should still be that as far as i can tell.

I haven't tested it though so....

Andrew

[wwzhao]

Dear Tobi,

I think you should add "compressible::turbulentTemperatureCoupledBaffleMi xed 1;" to DebugSwitches sub-dictionary in system/controlDict.

Best,
Weiwen

[excolade]

Hi all,


I am trying to turn on the debug switch in cyclicAMIPolyPatch.C. As far as I understood

namespace Foam
{
    defineTypeNameAndDebug(cyclicAMIPolyPatch, 0);

    addToRunTimeSelectionTable(polyPatch, cyclicAMIPolyPatch, word);
    addToRunTimeSelectionTable(polyPatch, cyclicAMIPolyPatch, dictionary);
}

if I set cyclicAMIPolyPatch to 1 in controlDict DebugSwitches subDictionary it will turn the debug switches on for that part of the code. Is this correct? Or do I have to compile the openfoam with certain debug definitions turned on? I am on OpenFoam 5.x by the way.


Cheers,


Orçun

[Mars409]

I ran into a weird debug switch error when I run MPPICFoam. It didn't happen until yesterday.

$ MPPICFoam
debug::switchSet(const char*, dictionary*&):
    Cannot find DebugSwitches in dictionary IStringStream.sourceFile

Yesterday I cloned my RaspberryPi-4 OpenFoam7 build to replicate on another RaspberryPi-4. Fortunately, and strangely, MPPICFoam runs fine there.

Today I was tinkering around with how to run MPI over multiple machines and setting up an NFS directory to place a clone case directory there. As soon as I tried running mpirun -np 7 --hosts <machinesfile> MPPICFoam -parallel, I got this error. So I tried running just MPPICFoam without MPI, still the same error.

And it's not just in this NFS directory, but happens also on a similar clone directory elsewhere on the same node. But running MPPICFoam from the clone node on the same NFS directory ran just fine.

It could be a file corruption somewhere under the OpenFoam directory. I still have the tarball for the OpenFoam build cloning purpose, so I could untar to overwrite my OpenFoam-7 directory and try again.

But perhaps before I take that drastic step someone in this thread could give me a tip-off as to where to look for the offending file?

===============

The problem went away as mysteriously as it had arrived. After powering it down, powering back up to do some unrelated work, powering down again, and finally powering back up 2nd time to re-try MPPICFoam, it runs without a hitch.

[jmt]

Originally Posted by wwzhao

Dear Tobi,

I think you should add "compressible::turbulentTemperatureCoupledBaffleMi xed 1;" to DebugSwitches sub-dictionary in system/controlDict.

Best,
Weiwen

I wanted to write a note to follow up that Weiwen is correct and I just followed this procedure for OpenFoam-5.x. In the main controlDict file,

$FOAM_ETC/system/controlDict

you can add the key to the list of debugSwitches:

DebugSwitches
{
    ...
    compressible::turbulentTemperatureCoupledBaffleMixed  1;
    ...
}

In the screen or log file output, you can now see the heat transfer rate and interface temperature. Thanks all!