View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003583 | OpenFOAM | Bug | public | 2020-10-27 15:26 | 2020-10-28 08:45 |
Reporter | peksa | Assigned To | henry | ||
Priority | low | Severity | minor | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Platform | GNU/Linux | OS | Ubuntu | OS Version | 15.04 |
Fixed in Version | dev | ||||
Summary | 0003583: magSqr functionObject produces unnecessary warnings | ||||
Description | Hey, 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 Reproduce | In 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; } | ||||
Tags | No tags attached. | ||||
|
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. |
|
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. |
|
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 |
|
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; } } |
|
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 |
|
> 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. |
|
Looks good and effective solution which seems to work. |
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 |