[philippose]

Hello,

A Good Day, and belated Merry Christmas :-)!

I am using the spare time I now have till my work starts again to look into some pending OpenFOAM related matters, and found something which I need some advice on.....:

When using the equationReader (as present in the OpenFOAM-ext Git branch: origin/feature/equationReader) in combination with the variable expansion features already present in OpenFOAM for dictionary entries, there seems to be a problem / bug which can be explained using the following example:

This is the "U" dictionary of a simple case:

#include "$FOAM_CASE/testVariables.dat"

dimensions      [0 1 -1 0 0 0 0];

internalField   uniform (0 0 0);

boundaryField
{
    inlet
    {
        type            fixedValue;
        value           uniform ("$Uinlet/5.0" 0 0);
    }

    outlet
    {
        type            zeroGradient;
    }

    upperWall
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }

    lowerWall
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }

    frontAndBack
    {
        type            empty;
    }
}

In the above dictionary, I have used an "#include" statement to include an external file into the current one. This external file has the following variable definition:

Uinlet          20.0;

However, when I run the simulation, I get the following error:

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Reading field p

Reading field U



--> FOAM FATAL ERROR: 
Parsing error in the equation for fromScalar, given by:

        "$Uinlet/5.0"

Error occurs withing the < angle brackets >:

        "<$Uinlet>/5"

"Variable name $Uinlet not found in any available sources."

    From function equationReader::parse
    in file db/dictionary/equation/equationReader/equationReader.C at line 72.

FOAM aborting

Aborted (core dumped)

It looks like the OpenFOAM keyword substitution does not work with expressions within quotes ("...."), because they are treated by the dictionary processing system as a literal string.

However, the "fromScalar" function intercepts this string (present in Scalar.C) and passes it on to the equationReader subsystem.

The problem is, that the string passed on to the equationReader still contains the unsubstituted "$...." variable, which causes an error to be thrown.


Any way this can be solved, or is there any other method I could use to emulate this functionality?

The reason I would like to use this is because, it would allow me to create one include file which contains different variables defined in usual physical dimensions like:

density              850; // density in kg/m^3

inletPressure       10;  // pressure in bar

inletFlowRate      2.5; // flow rate in l/min

etc....etc...., and then use expressions in the respective boundary condition files like for example:

For the "p" boundary:

inlet
{
    type      fixedValue;
    value     uniform "$inletPressure * 100000 / $density";
}

or...

for the "U" boundary:

inlet
{
    type         flowRateInletVelocity;
    flowRate    uniform "$inletFlowRate / 60000";
}

etc....

Any ideas?

Have a nice day!

Philippose

[philippose]

Hello again,

I have submitted a bug-report to the OpenFOAM-extend Mantis server regarding this issue.

It would be great if we could find a solution for it, because this combination of the equationReader with macro expansion would ease things by a great deal.... it basically would let you use expressions to set up boundary conditions without having to step out of the stock OpenFOAM functionality.

Have a great evening ahead!

Philippose

[marupio]

Hi Phillipose,

Sorry for the delay, Bernhard Gschaider just drew my attention to this. (I check the forums, but I don't usually check Bugs.) He also just set my project up on Mantis.

I am just finishing up a paper, and will jump on this next. Don't get your hopes up, though, because it looks like it could be a problem with how OpenFOAM handles macro expansion, outside the scope of the equationReader... we may be able to hack something.

-Dave

[philippose]

Hello David :-)!

A Good Morning to you :-)! Just the person I was hoping would reply to this message :-)! A Happy New Year to you!

You are right.... in the bug-report I submitted, I have mentioned that this is not directly a problem related to the equationReader system, but rather the fact that the underlying OpenFOAM structures seem to "ignore" macros which are present within quotes.

I was able to reproduce this using one of the old set of unit-tests which were present in the OpenFOAM sources, which tests basically functionality of dictionaries.

However, I dont think there are any other situations other than when using swak4Foam, groovyBC or the equationReader, when macro expansions might be present within quotes.

So basically, it looks like a situation where the basic framework of OpenFOAM has not been able to keep up with the new functionality added to OpenFOAM above the base framework :-)!

I looked at trying to find some kind of fix at the low level, but I must confess, that the flow-of-events at the level of reading dictionaries and detecting / assigning tokens and parsing text is (not yet) one of my strong-points :-)!

I would be glad to help though..... :-)!

Have a great day ahead!

Philippose

[marupio]

Hi Philippose,

I've finished the paper I was working on, but now I have several other pressing issues. I hope you can wait a little longer! There's a few work arounds.

1. You can define *everything* in your testVariables.DAT file. e.g.:

Uinlet          0.01;
// Uinlet / 5
Uinlet|5        0.002;

inletPressure    0.2;
// inletPressure x 100000 / rho
inletPressureX100k|rho    203000.12;

... and so forth.

2. You could try to import #codeStream from OF2.0. See src/OpenFOAM/db/dictionary

My plan to resolve this bug is to release a new set of versions for equationReader. You are actually working with an older version that modifies OpenFOAM's core. The new version is "stand alone", but it doesn't let you use it in place of a scalar in a dictionary. My fix will be to release a stand-alone (for those who don't like to modify the core), and a set of integrated versions (probably one for each version of FOAM). Since I'm modifying the core, I'll modify the macro expansion feature to expand macros within quotes... but I'll probably do something like this:

macrosWontTouchThisQuote "untouchable string";
macrosWillTouchThisQuote \"please change this one $now\";

where \" means it can change it.

Anyways, I hope this will do for now!

-Dave

[philippose]

Hello David,

A Good Day to you!

Great to hear that you are done with your paper :-)! I hope I did not sound like I was putting any form of pressure on you regarding this issue....

Just to make it clear..... I am not in "dire" need of a fix for this issue :-)! Its something I noticed while I was trying to make the case setup for OpenFOAM a little more "Engineer-friendly" :-)! I basically wanted to stick with the usual physical variables we use, and bunch them all up into one file, and let your Equation reader do the magic of converting them to units which OpenFOAM requires in the background.

Hence, defining everything in one place is definitely an option, but not one which is aligned with my initial goal.


I think your idea of providing a form of "quoting" which OpenFOAM also expands is a great one! Personally, I am fine with using a [\"] instead of a ["] at all the places where a macro which needs to be expanded is present.

However, I guess you will have to discuss with Hrv, whether this would be aligned with the general principles or standards followed in OpenFOAM so far.


So... you can take your time :-)!

I find the Equation Reader really nice..... I think the ability to specify boundary conditions and other constants (for example, "nu", "rho", etc...etc...) using expressions (without having to go to the extent of using groovyBC or swak4Foam) very very (very) useful :-)!


............... Some Ramblings (Optional ;-)!) ...................

Another option would be, if you make it possible to create variables in a dictionary, without having to modify the code for a solver..... And then, use these variables in expressions.

I know you already have this functionality, but so far, it cannot be used without modifying the solver code (or?)..... In a way, it will be like a parallel stream to the already existent OpenFOAM Macros.

I may not have understood the concept too well.... but....Would something like a "default data source" for the integrated version of the EquationReader let arbitrary variables to be added to the EquationReader Data sources via a dictionary in a file in say the "system" or "case" folder?

Or even better, what about a new entry in "controlDict" where you can specify the name of an Equation-Dictionary file, where user variables can be defined? This Dictionary is then used when evaluating the other expressions found in the different Boundary condition and properties files.....


Philippose