View Issue Details

IDProjectCategoryView StatusLast Update
0002616OpenFOAMFeaturepublic2017-07-21 15:51
ReporterStephanG Assigned Tohenry  
PrioritylowSeverityfeatureReproducibilityN/A
Status closedResolutionno change required 
PlatformGNU/LinuxOSUbuntuOS Version14.04
Product Versiondev 
Summary0002616: Definition of variables in blockMesh using #calc
DescriptionWhile creating meshes with blockMesh I often find myself in a situation where I need to define the negative of already defined variables. While it is possible to add these with #calc functions it blows up the creation process unnecessarily. Instead of:

var1 #calc "0.50*$radius"
negvar1 #calc "-$var1"

vertices
(
($var1 $var1 $var1)
($negvar1 $negvar1 $negvar1)
...

I'd like to have the possibility to simply do the following:

var1 #calc "0.50*$radius"
vertices
(
($var1 $var1 $var1)
(-$var1 -$var1 -$var1)
...

Since every #calc function needs to be compiled this slows down the creation process substantially and creates confusing variable definitions. This often appears in parameter studies. For the simple multiplication with 0.5 each time the radius is changed the code is recompiled.
radius 10;
var1 #calc "0.50*$radius"

While I am aware of many ways to circumvent this by external means like m4 or sed I'd like to make a point for changing it in a way to allow definitions of simple variables without the use of code compilation. Maybe by adding precompiled versions for simple tasks like multiplication of a veriable with a value or sin/cos operations.
TagsblockMesh

Activities

henry

2017-07-15 20:20

manager   ~0008400

I don't see the problem with

negvar1 #calc "-$var1"

and the compilation would only need to be done once and reused on subsequent calls. Using #calc is a general solution to the problem and is easier to maintain than creating an special interpreted sub-language and your proposal would require.

If you can propose a method which avoids the compilation of simple #calc tasks without the need to write an interpreter please then that would be interesting. Please submit a patch which does this for consideration.

wyldckat

2017-07-17 22:20

updater   ~0008408

I have gone through this issue myself, namely expecting that "-$var1" would work, given that a C/C++ pre-processor would expand the macro variable before compiling.
But as far as I know, the current parsing implementation that is available in OpenFOAM does the parsing on-the-fly in a single pass, therefore this isn't straight forward at the moment. It currently reads the minus sign and expects a number to come up, therefore it does not expand the "$var1" after said minus.

What comes to mind is that perhaps we could implement a special "#include" sub-type that could parse the file twice: once for getting the constant variable definitions and respective substitutions, then a second pass for the final interpretation, as it there were no further expansions required within that included file. Although in some cases, it might need more than one pass, until all expansions are completed...
In order to start looking into this, the entry point is "$FOAM_SRC/OpenFOAM/db/dictionary/functionEntries/", where there are several interpretations classes for the various special entries.



However, it is possible to make it easier to do parametric studies without relying on compiling the dictionary into C/C++, thanks to the "#include" et al feature, as indicated in the User Guide, subsection "4.2.10 Including files": https://cfd.direct/openfoam/user-guide/basic-file-format/#x17-1290004.2.10

What I mean is that by having the variables defined in a separate file, then that file can be generated separately by whatever the user prefers, may it be Python, Bash, sed, awk, Perl, m4 and so on. Furthermore, this would enforce the need to ensure that the tests are reproducible, namely by keeping copies of just these parametric files for each file (or at least how they are generated), instead of keeping several nearly identical "blockMeshDict" files.


As for supporting sin/cos and other mathematical operations directly from 'blockMeshDict', without relying on compiling it into C/C++ on-the-fly... what comes to mind would be something along the lines of either:

 - using something how patches deal with this, such as Function1, namely the classes listed here: https://cpp.openfoam.org/v4/namespaceFoam_1_1Function1Types.html

 - or function objects that would have the inputs pre-compiled and be able to feed into blockMesh to build the mesh...

but I'm not seeing yet how this could be done.


Beyond this, having a Python interpreter (as an alternative to a C/C++ compiler) is an interesting idea, but having the Python library as an additional dependency can be a bit of a pain during the installation phase and could prove to be a bit of a maintenance issue, namely the support of multiple Python versions... which doesn't feel right to me at the moment to integrate into OpenFOAM just for this feature (albeit a very powerful one).

henry

2017-07-21 15:51

manager   ~0008430

It is not clear what should be done for this request. Either way it would require a contribution.

Issue History

Date Modified Username Field Change
2017-07-15 20:06 StephanG New Issue
2017-07-15 20:06 StephanG Tag Attached: blockMesh
2017-07-15 20:20 henry Note Added: 0008400
2017-07-17 22:20 wyldckat Note Added: 0008408
2017-07-21 15:51 henry Assigned To => henry
2017-07-21 15:51 henry Status new => closed
2017-07-21 15:51 henry Resolution open => no change required
2017-07-21 15:51 henry Note Added: 0008430