[braennstroem]

Hi,

I wonder, if anyone uses the regexp features and could show some small examples. I know this example, which is already quite complex:

http://www.cfd-online.com/Forums/ope...0787-openfoam-15-a.html



but this was still for 1.5 and 1.6.x should provide even more stuff!? In addition I wonder, if adjustments in include files for fvSchemes and fvSolution are runtime selectable as well? Right now, it seems, that they are not...

Best Regards!
Fabian

[olesen]

Originally Posted by braennstroem

but this was still for 1.5 and 1.6.x should provide even more stuff!? In addition I wonder, if adjustments in include files for fvSchemes and fvSolution are runtime selectable as well? Right now, it seems, that they are not...

Hi Fabian,
your link seems to have been truncated. Here it is for other people:
http://www.cfd-online.com/Forums/ope...foam-15-a.html

For something simpler, how about this:

// system/fvSolution
#include        "~OpenFOAM/system/fvSolution/simple"
SIMPLE
{
    convergence     5e-4;
}

And the site-wide or user-specific file (see foamEtcFile -list)

// system/fvSolution
solvers
{
    p
    {
        solver          GAMG;
        tolerance       1e-08;
        relTol          0.05;
        smoother        GaussSeidel;
        // nPreSweeps      0;
        // nPostSweeps     2;
        // nFinestSweeps   2;
        cacheAgglomeration      false;
        nCellsInCoarsestLevel   20;
        agglomerator    faceAreaPair;
        mergeLevels     1;
    }

    "(U|h)"
    {
        solver          PBiCG;
        preconditioner  DILU;
        tolerance       1e-06;
        relTol          0.1;
    }

    "(k|epsilon|omega)"
    {
        solver          smoothSolver;
        smoother        GaussSeidel;
        nSweeps         2;
        tolerance       1e-07;
        relTol          0.1;
    }
}

relaxationFactors
{
    p       0.3;
    rho     1.0;
    U       0.7;
    "(k|epsilon|omega)" 0.7;
    h       0.8;
}

Of course you are quite right that an edit to an included file won't get noticed during a simulation run. You'll have to use "touch" on the main file for the changes to be noticed.
Fortunately, since controlDict now also tracks the SHA1 of the functions entry, they will not be re-initialized by this (unless their contents have changed as well).

As you probably figured, since the solver controls are now dictionary entries, you can also use $variable interpolation to reuse values.
NB: only use the $variable to reference a plain (non-regex) entry. While referencing a regex might seem to work, just avoid it. I don't think it supposed to work like that at all.

[braennstroem]

Hi Mark,

quite interesting... and your blog stuff as well :-)
Do you know, if it is possible to do some simple calculations like adding/dividing as well?

Thanks!
Fabian

[olesen]

Originally Posted by braennstroem

Hi Mark,
quite interesting... and your blog stuff as well :-)

Hi Fabian,
Thanks, I'm glad that someone has looked at the blog.
I'm slowly putting together other misc. bits for it as well.

Do you know, if it is possible to do some simple calculations like adding/dividing as well?

At the moment there isn't anything like that, but it would be a fairly convenient thing to have. Depending on what exactly you need, you could try the m4 approach as a possible workaround, provided you don't have any binary data in the file. There are some examples in the tutorials where they've used it with blockMesh.

Another workaround that would be easy enough would be to add in something like an '#system()' directive that could let you do something like this:

flowRate  #system(perl -e 'print 500/3600');   // 500 kg/h

Done properly though, I think it should support the $entry syntax and allow stuff like this:

refRho     ...;
flowRate  #calc(500 / 3600);   // 500 kg/h
volFlow    #calc( $flowRate / $rho);

This would help for anyone who has suffered with having to deal with SCFM as a mass flowrate.

However, this would mean entail a small lexer/parser and thus a bit more work. Coincidentally, I've been looking at parsers recently anyhow, but I haven't managed to form a final opinion about what is really worth trying.
If it's really pressing, I could help you with implementing the #system() workaround, but I think it's a poor stop-gap measure and I'd also feel funny about knowing that my dictionaries could contain a "reliable move, really fast" command (ie, "rm -rf").