View Issue Details

IDProjectCategoryView StatusLast Update
0003583OpenFOAMBugpublic2020-10-28 08:45
Reporterpeksa Assigned Tohenry  
PrioritylowSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version15.04
Fixed in Versiondev 
Summary0003583: magSqr functionObject produces unnecessary warnings
DescriptionHey,

I noticed that while using magSqr functionObject for non-scalar field (here U), the function produces a warning message:

--> FOAM Warning : functionObjects::magSqr magFn cannot find required object U of type volScalarField
--> FOAM Warning : functionObjects::magSqr magFn cannot find required object U of type surfaceScalarField

I believe this happens because the present implementation of the calc() function in magSqr.C calls the templated calcMagSqr function for each data type as shown below. How

bool Foam::functionObjects::magSqr::calc()
{
    bool processed = false;

    processed = processed || calcMagSqr<scalar>();
    processed = processed || calcMagSqr<vector>();
    processed = processed || calcMagSqr<sphericalTensor>();
    processed = processed || calcMagSqr<symmTensor>();
    processed = processed || calcMagSqr<tensor>();

    return processed;
}
Steps To ReproduceIn order to reproduce the problem, add the following fucntionObject into controlDict functions subdictionary of any tutorial (tested with compressible "aerofoilNACA0012" tutorial):

    magSqrU
    {
        type magSqr;
        functionObjectLibs ("libfieldFunctionObjects.so");
        field U;
        writeControl timeStep;
        writeInterval 1;
    }
TagsNo tags attached.

Activities

henry

2020-10-27 15:36

manager   ~0011642

That is correct. If we remove the warning messages then the user would not know if they have selected a field that does not exist. Personally I don't mind either way and am happy to remove the warning if that is what most users would prefer.

peksa

2020-10-27 15:56

reporter   ~0011643

There is a point to include the message as well, you're right. Could we consider having a general "checkExistence()" function in the constructor or in the calc() function, which would throw a warning only if no variable name with any dataType is found.

Only downside of having Warnings appearing always is that when using functionObjects at every time step (or very often), the log files become bloated with them which can be annoying and I could imagine that it could mislead the user in some cases during debugging. In particular if one wants to utilize various functionObject producing Warnings like this. And I think when creating complex simulations, this may be a case.

Let me know your thoughts.

henry

2020-10-27 15:59

manager   ~0011644

The warning needs to be delayed until after all the types are tested e.g.:

bool Foam::functionObjects::magSqr::calc()
{
    bool processed = false;

    processed = processed || calcMagSqr<scalar>();
    processed = processed || calcMagSqr<vector>();
    processed = processed || calcMagSqr<sphericalTensor>();
    processed = processed || calcMagSqr<symmTensor>();
    processed = processed || calcMagSqr<tensor>();

    if (!processed)
    {
        cannotFindObject(fieldName_);
    }

    return processed;
}

This change will need to be made to

field/CourantNo/CourantNo.C
field/Lambda2/Lambda2.C
field/PecletNo/PecletNo.C
field/Q/Q.C
field/components/componentsTemplates.C
field/ddt/ddtTemplates.C
field/div/divTemplates.C
field/enstrophy/enstrophy.C
field/fieldsExpression/fieldsExpressionTemplates.C
field/flowType/flowType.C
field/grad/gradTemplates.C
field/log/log.C
field/mag/magTemplates.C
field/magSqr/magSqrTemplates.C
field/pressure/pressure.C
field/randomise/randomiseTemplates.C
field/scale/scaleTemplates.C
field/streamFunction/streamFunction.C
field/vorticity/vorticity.C
field/wallHeatFlux/wallHeatFlux.C

peksa

2020-10-27 19:34

reporter   ~0011645

Hey,

I implemented a solution according thoughts above. So I extended the functionObjects::fieldExpression::foundObject function to include "bool verbose" variable to control verbosability. For example, in PecletNo.C it would be beneficial to keep the Warning behavior as it is, i.e. verbose=true, while in magSqr it would be set to false.

Regarding a case when the field does not exist, I realized that the functionObjects::fieldExpression::execute() includes already a warning which is activated if the calc() returns false (see below). Hence, I think it's not necessary to have a separate cannotFIndObject(fieldName_) in calc().

What do you think?


bool Foam::functionObjects::fieldExpression::execute()
{
    if (!calc())
    {
        Warning
            << " functionObjects::" << type() << " " << name()
            << " failed to execute." << endl;

        // Clear the result field from the objectRegistry if present
        clear();

        return false;
    }
    else
    {
        return true;
    }
}

henry

2020-10-27 20:05

manager   ~0011646

commit f7848e62a1722fb8a99ee67ba2fa8d229d50d8cd (HEAD -> master, origin/master, origin/HEAD)
Author: Henry Weller <http://cfd.direct>
Date: Tue Oct 27 20:03:19 2020 +0000

    functionObjects: Emit warning messages only for field names which do not exist for any type
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=3583

henry

2020-10-27 20:07

manager   ~0011647

> I realized that the functionObjects::fieldExpression::execute() includes already a warning which is activated if the calc() returns false

It does not provide any information about why it failed, i.e. that the field name could not be found.

peksa

2020-10-28 07:13

reporter   ~0011648

Looks good and effective solution which seems to work.

Issue History

Date Modified Username Field Change
2020-10-27 15:26 peksa New Issue
2020-10-27 15:36 henry Note Added: 0011642
2020-10-27 15:56 peksa Note Added: 0011643
2020-10-27 15:59 henry Note Added: 0011644
2020-10-27 19:34 peksa Note Added: 0011645
2020-10-27 20:05 henry Note Added: 0011646
2020-10-27 20:07 henry Note Added: 0011647
2020-10-28 07:13 peksa Note Added: 0011648
2020-10-28 08:45 henry Assigned To => henry
2020-10-28 08:45 henry Status new => resolved
2020-10-28 08:45 henry Resolution open => fixed
2020-10-28 08:45 henry Fixed in Version => dev