Sorry to bother you, this is solved.
The warning happens due to the syntax is different for the latest OpenFOAM version.
The current syntax should goes like this:
Code:
dimensionedScalar rho3("rho3",transportProperties);
lookup is not needed for reading properties from dictionary.
Question from newbe me before:
------------------------------------------------------------
There is a warning info when I try to compile a solver.
HTML Code:
readTransportProperties.H: In function int main(int, char**):
readTransportProperties.H:18:5: warning: Foam::dimensioned<Type>::dimensioned(Foam::Istream&) [with Type = double] is deprecated: Since 2018-11 [-Wdeprecated-declarations]
18 | );
| ^
I include the "readTranspotProperties.H" in my "createFields.H" file
Here is the "readTranspotProperties.H"
Code:
IOdictionary transportProperties
IOobject
"transportProperties",
runTime.constant(),
mesh,
IOobject::MUST_READ,
IOobject::NO_WRITE
dimensionedScalar rho3
transportProperties.lookup("rho3")
The code is pretty simple, but warning happens.
Does anyone have an idea about how to debug the warning?
Thank you very much for your kindness and patience.
The dictionary "lookup" method returns a stream of tokens. If you construct from that, the constructor will use as many tokens as needed. This works fine, so you can simply ignore the compilation warnings.
However, consider the following example:
Code:
nu nu [ 0 2 -1 0 0 0 0 ] 1e-05
enabled true;
nu0 nu0 [ 0 2 -1 0 0 0 0 ] 1e-06
At first it looks OK, but it you look closely, you'll see there is a missing ';' on the first entry. Thus it really looks like this (for the parser):
Code:
nu nu [ 0 2 -1 0 0 0 0 ] 1e-05 enabled true;
nu0 nu0 [ 0 2 -1 0 0 0 0 ] 1e-06;
If you use the new syntax (specifying name and dictionary, without the lookup), you are telling the constructor that you expect the evaluation of the dictionary lookup to consume all of the tokens. The constructor can now report an IO warning or error that there are unexpected trailing tokens.
If you use the lookup syntax, you are less likely to notice your bad input. In this case, you thought you had an "enabled" entry, but it's just some trailing rubbish on the "nu" entry. Much better to have the bad input flagged immediately instead of waiting a day for the simulation to run and not even realise that the "enabled" wasn't actually seen.
