That's strange. foamVersion4swak.H is generated by the main Allwmake-file. And that is quite verbose about it (whether the file has changed ...). The relevant output must be within the first 10 lines of the output (right after the Bison-version).

BTW: are your sources new or did you upgrade them with "svn update"? In that case it might be a good idea to remove the lnInclude-directories (so they will be regenerated). Although I don't think that this is the source of your problems.

Thank you!

I tried to install again swak4foam:
no more error after ./Allwmake (in the followings you have the first lines of the output)

and when compiling interFoamWithSources I had a different error (look down)

maybe I made again some mistake...

manu@manu-hp:/opt/openfoam210$ svn checkout https://openfoam-extend.svn.sourcefo...ies/swak4Foam/

manu@manu-hp:/opt/openfoam210/swak4Foam$ mv swakConfiguration.example swakConfiguration


manu@manu-hp:/opt/openfoam210/swak4Foam$ ./Allwmake
Bison is version 2.4.1
Reading variables from 'swakConfiguration'
OpenFOAM-version: Major 2 Minor 1 Patch 0
No Libraries/swak4FoamParsers/foamVersion4swak.H. Generated
wmakeLnInclude: linking include files to ./lnInclude
Making dependency list for source file SurfacesRepository.C
Making dependency list for source file SetsRepository.C
Making dependency list for source file GlobalVariablesRepository.C
Making dependency list for source file ExpressionDriverWriter.C
Making dependency list for source file ExpressionResult.C
Making dependency list for source file StoredExpressionResult.C
Making dependency list for source file swakRegistryProxySurface.C
Making dependency list for source file swakRegistryProxySet.C
Making dependency list for source file FieldValueExpressionParser.yy
could not open file FieldValueExpressionParser.tab.hh for source file FieldValueExpressionParser.yy
Making dependency list for source file PatchValueExpressionParser.yy
could not open file PatchValueExpressionParser.tab.hh for source file PatchValueExpressionParser.yy
Making dependency list for source file SubsetValueExpressionParser.yy
could not open file SubsetValueExpressionParser.tab.hh for source file SubsetValueExpressionParser.yy


manu@manu-hp:/opt/openfoam210/swak4Foam/Examples/InterFoamWithSources/interFoamWithSources$ wmake

I think you stopped before you got to the interesting part (the problem with interFoamWithSources). The missing tab.hh-files are no problem: bison generates them later

Dear gschaider,

in my case (i created this thread) the whole swak package works nicely on version 2.1. with the latest Intel Compiler

thanks for your work

I see. You feel responsible for what you started. A OpenFOAM-user with a conscience. A very rare thing ;)

Seriously: Thanks for the feedback. Especially as this (Intel-compiler) is a setup I can't test

Bernhard

yes, I am sorry

manu@manu-hp:/opt/openfoam210/swak4Foam/Examples/InterFoamWithSources/interFoamWithSources$ wmake

Making dependency list for source file interFoamWithSources.C
SOURCE=interFoamWithSources.C ; g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3 -DNoRepository -ftemplate-depth-100 -I/opt/openfoam210/src/transportModels -I/opt/openfoam210/src/transportModels/incompressible/lnInclude -I/opt/openfoam210/src/transportModels/interfaceProperties/lnInclude -I/opt/openfoam210/src/turbulenceModels/incompressible/turbulenceModel -I/opt/openfoam210/src/finiteVolume/lnInclude -I../../../Libraries/swak4FoamParsers/lnInclude/ -I../../../Libraries/swakSourceFields/lnInclude/ -IlnInclude -I. -I/opt/openfoam210/src/OpenFOAM/lnInclude -I/opt/openfoam210/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linux64GccDPOpt/interFoamWithSources.o
In file included from ../../../Libraries/swak4FoamParsers/lnInclude/FieldValueExpressionParser_location.hh:44:0,
from FieldValueExpressionParser.tab.hh:65,
from ../../../Libraries/swak4FoamParsers/lnInclude/FieldValueExpressionDriver.H:18,
from ../../../Libraries/swakSourceFields/lnInclude/expressionSource.H:45,
from interFoamWithSources.C:49:
position.hh: In function ‘bool parserField::operator==(const parserField::position&, const parserField::position&)’:
position.hh:136:69: warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
interFoamWithSources.C: In function ‘int main(int, char**)’:
interFoamWithSources.C:90:21: error: ‘class Foam::pimpleControl’ has no member named ‘start’
interFoamWithSources.C:90:51: error: no ‘operator++(int)’ declared for postfix ‘++’ [-fpermissive]
interFoamWithSources.C:95:42: error: ‘class Foam::pimpleControl’ has no member named ‘nCorr’
In file included from interFoamWithSources.C:97:0:
pEqn.H:32:73: error: no matching function for call to ‘Foam::pimpleControl::finalInnerIter(int&, int&)’
pEqn.H:32:73: note: candidate is:
/opt/openfoam210/src/finiteVolume/lnInclude/pimpleControlI.H:80:13: note: bool Foam::pimpleControl::finalInnerIter() const
/opt/openfoam210/src/finiteVolume/lnInclude/pimpleControlI.H:80:13: note: candidate expects 0 arguments, 2 provided
/opt/openfoam210/src/finiteVolume/lnInclude/readTimeControls.H:38:8: warning: unused variable ‘maxDeltaT’ [-Wunused-variable]
make: *** [Make/linux64GccDPOpt/interFoamWithSources.o] Error 1

Ah. I see. Never tested those examples with 2.1

The interface of the pimpleControl-class changed (for the better I guess) and is now incompatible.

I currently don't have the time (especially not in a form that works with 2.1 and 2.0). Will fix it for the next release if I remember it (a Bug-report in the openfoam-extend will help)

So I'm afraid you'll have to copy over the sources of the regular interFoam-solver and adapt it. As far as I remember this is only necessary in three places:

- add the header for the expressionSource
- create the expressionSource in createFields.H
- add the expression in the PDE

Thanks! It works
Just 5 lines to be changed in interFoamWithSources.C and pEqn.H

Just to close this issue: For those interested see http://sourceforge.net/apps/mantisbt...iew.php?id=119

I am using OF2.1.x and latest version of swak4foam. I added a source term to reactingfoam using swak4foam (similar to interFoamWithSources, above post and http://www.cfd-online.com/Forums/ope...tml#post329700). I corrected "option" and "file" but when I compile the new solver, I encounter an error which states that mappedwallpolypatch header in expressionsource header could not found and compilation terminated.

also, I can not compile interFoamWithSources in example because of above error. how can I fix the error?

Thank you in advance,
Hossein

Add meshTools to the includes and the links

When encountering a missing header a good hint is to search for it using something like
and add the relevant lnInclude-directories

Hi.
I have problems installing swak4Foam on a linux machine.
I am using the Fujitsu compiler suite. (FCCpx etc.)

The error which occurs follows the same line as what was found in Mr. Fisch's post.

The error below is an example from compiling the file GlobalVariableRepository.C in swak4FoamParsers.
---------------------------------------

[c09006@oakleaf-fx-1 swak4FoamParsers]$ SOURCE=repositories/GlobalVariablesRepository.C ; mpiFCCpx -DS64FX -DWM_DP -O3 -Xg -w -D__INTEL_COMPILER -DNoRepository -IMake/S64FXFccDPOpt -I/usr/local/OpenFOAM/2.1.1/OpenFOAM-2.1.1/src/finiteVolume/lnInclude -I/usr/local/OpenFOAM/2.1.1/OpenFOAM-2.1.1/src/sampling/lnInclude -I/usr/local/OpenFOAM/2.1.1/OpenFOAM-2.1.1/src/triSurface/lnInclude -I/usr/local/OpenFOAM/2.1.1/OpenFOAM-2.1.1/src/lagrangian/basic/lnInclude -I/usr/local/OpenFOAM/2.1.1/OpenFOAM-2.1.1/src/meshTools/lnInclude -IlnInclude -I. -I/usr/local/OpenFOAM/2.1.1/OpenFOAM-2.1.1/src/OpenFOAM/lnInclude -I/usr/local/OpenFOAM/2.1.1/OpenFOAM-2.1.1/src/OSspecific/POSIX/lnInclude -KPIC -c $SOURCE -o Make/S64FXFccDPOpt/GlobalVariablesRepository.o
"/usr/local/OpenFOAM/2.1.1/OpenFOAM-2.1.1/src/OpenFOAM/lnInclude/pTraits.H", line 53: error: not a class or struct name
public PrimitiveType
^
detected during instantiation of class "Foam::pTraits<PrimitiveType> [with PrimitiveType=char [48]]" at line 63 of "repositories/GlobalVariablesRepository.C"

"/usr/local/OpenFOAM/2.1.1/OpenFOAM-2.1.1/src/OpenFOAM/lnInclude/pTraits.H", line 53: error: not a class or struct name
public PrimitiveType
^
detected during instantiation of class "Foam::pTraits<PrimitiveType> [with PrimitiveType=Foam::Ostream &(Foam::Ostream &)]" at line 63 of "repositories/GlobalVariablesRepository.C"

---------------------------------------


I have multiple errors of this type all relating to the file pTraits.H. Further they all seem to be
related with the output stream in some way, since they arise in locations where "Pout" or "endl" are
specified in the code.

Can anybody help me or give me a hint?

Thanks in advance,
Tsuyoshi Koyama

Without access to the compiler it is hard to say what to do. The "good" news is that it happens in a standard OF-header: by that I mean: it has already been compiled so it should be possible to compile it here to. The "problem" with the C-file that you show is that it tries to be as minimalistic as possible in what it includes from OF and that might be the problem. Or that the compiler is sensitive to the order of the way things are included. Ty the following: copy paste the include-lines from a C-file that works BEFORE the original includes and see if that compiles. If it does throw includes away until it stops working.
Sorry that this sounds like snake oil. It is. But without the compiler this is the best that comes to mind

Dear Mr Gschaider

Thank you very much for your reply.
I think I have almost been able to figure out my problem.
The problem seems to be related with the file "ExpressionResult.H".
In this file there is a templated constructor,

template<class Type>
ExpressionResult(
const Type &f,
typename enable_if_rank0<pTraits<Type>::rank>::type* dummy=0
);

Whenever there is a line of code such as,

Pout << "PRINT SOMETHING";

the character array is implicity cast into a ExpressionResult object,
and then since the character array is not a class, the pTraits complains
and gives an error. Additionally I have also found a problem where
casting to the base class has problems. For instance in the code
"StoredExpression.C", there is constructor,

StoredExpressionResult::StoredExpressionResult(
const StoredExpressionResult &rhs
)
:
ExpressionResult(rhs),
name_(rhs.name_),
initialValueExpression_(rhs.initialValueExpression _)
{
}

This code somehow uses the constructor

template<class Type>
ExpressionResult(
const Type &f,
typename enable_if_rank0<pTraits<Type>::rank>::type* dummy=0
);

with Type=StoredExpressionResult

instead of the constructor,

//- Construct as copy
ExpressionResult(const ExpressionResult&);

To get rid of the compiling error I modified the file
"ExpressionResult.H" by removing the "=0" in the constructor.

template<class Type>
ExpressionResult(
const Type &f,
typename enable_if_rank0<pTraits<Type>::rank>::type* dummy
// typename enable_if_rank0<pTraits<Type>::rank>::type* dummy=0
);

With this modification I am able to compile the code. Could you tell me
what the consequences of such a change would be.

Sincerely,
-Tsuyoshi Koyama

The purpose of this construct (if I remember it correctly) was to make sure that only types with a rank 0 match this constructor. The default value was to make sure that this was transparent to the user. Must have a look whether this constructor is still necessary (maybe the use-case this was done for was rendered obsolete by some other constructor). As far as I can tell your change is as good as commenting out the constructor completely

Could you try something? In ExpressionResult.C there are 5 pTraits-specializations (just below a comment "I have NO idea why this is necessary"). Could you move them to the .H-file (inside of the "namespace Foam"), reinstate the default =0 and see if that compiles?

Dear Mr. Gschaider,

Thank you very much for the additional hint. I have been able to
get the sprinklingInlet to work with the first modification (remove default =0).
The modification that you have suggested(move the 5 template specializations and keep the =0)
also compiles. Since I don't have an example of using libswak4FoamParsers.so, I am
not completely sure if the library will work though. During the compilation I noticed one
problem where files like "FieldValueExpressionParser.yy", which are processed first
by bison and then compiled, take an extremely long time (more than 2 hours). This
of course doesn't happen with my laptop running Fedora.

Sincerely,
-Tsuyoshi Koyama

OK. Then I'll move it up and hope that this also fixes the problems with the Intel-compiler

swak4foamParsers is used almost everywhere: if groovyBC, funkySetFields or (as you used that) the sprinklingInlet works then it is OK

The problem is that the generated C-file is rather large and if the compiler tries to optimize it aggressively then it takes very long (even longer if it runs out of "real" memory and the machine starts swapping). In theory O1 (or even O0) is sufficient for that file. So one option would be to stop compilation when it gets to the parsers, copy/paste the command and replace -Ox with a smaller number. Not sure whether there is a way to automize this

I tried installing swak4Foam_2.x on OpenFOAM2.1.x. At the beginning, it seems a lot of files can't be found as

../solvers/swak4Foam_2.x$ wmake all
No 'swakConfiguration'. Python etc won't work
Checking swak4Foam-version and generating file
abort: no repository found in '/home/parallels/OpenFOAM/OpenFOAM-2.1.x/applications/solvers/swak4Foam_2.x' (.hg not found)!
Swak version is 0.2.4
Bison is version 2.5
Flex is version 2.5.35 (Minor version: 35)
OpenFOAM-version: Major 2 Minor 1 Patch -1 (-1 == x)
No swak4FoamParsers/foamVersion4swak.H. Generated
wmakeLnInclude: linking include files to ./lnInclude
Making dependency list for source file helpers/printSwakVersion.C
Making dependency list for source file repositories/SurfacesRepository.C
Making dependency list for source file repositories/MeshesRepository.C
Making dependency list for source file repositories/SetsRepository.C
Making dependency list for source file repositories/GlobalVariablesRepository.C
Making dependency list for source file namedEnums/MeshInterpolationOrder.C
Making dependency list for source file namedEnums/LogicalAccumulationNamedEnum.C
Making dependency list for source file namedEnums/NumericAccumulationNamedEnum.C
Making dependency list for source file ExpressionDriverWriter.C
Making dependency list for source file ExpressionResult/ExpressionResult.C
Making dependency list for source file ExpressionResult/StoredExpressionResult.C
Making dependency list for source file ExpressionResult/DelayedExpressionResult.C
Making dependency list for source file ExpressionResult/StackExpressionResult.C
Making dependency list for source file ExpressionResult/StoredStackExpressionResult.C
Making dependency list for source file setsAndSurfaces/swakRegistryProxySurface.C
Making dependency list for source file setsAndSurfaces/swakRegistryProxySet.C
Making dependency list for source file makeSwakDataEntry.C
Making dependency list for source file FieldValueExpressionParser.yy
could not open file FieldValueExpressionParser.tab.hh for source file FieldValueExpressionParser.yy
could not open file directMappedFvPatch.H for source file FieldValueExpressionParser.yy
could not open file directMappedWallFvPatch.H for source file FieldValueExpressionParser.yy
could not open file directMappedPointPatch.H for source file FieldValueExpressionParser.yy
could not open file FixedValuePointPatchField.H for source file FieldValueExpressionParser.yy
could not open file ZeroGradientPointPatchField.H for source file FieldValueExpressionParser.yy
could not open file CalculatedPointPatchField.H for source file FieldValueExpressionParser.yy
Making dependency list for source file PatchValueExpressionParser.yy

At the end, it stopped at

If compilation of the grammers takes prohibitivly long set SWAK_COMPILE_GRAMMAR_OPTION to something like -O1

FieldValueExpressionParser.tab.cc: In member function ‘parserField::FieldValueExpressionParser::token_nu mber_type parserField::FieldValueExpressionParser::yytransla te_(int)’:
FieldValueExpressionParser.tab.cc:17527:24: warning: use of old-style cast [-Wold-style-cast]
^Cmake: *** wait: No child processes. Stop.
make: *** Waiting for unfinished jobs....
make: *** wait: No child processes. Stop.
Parser library did not compile OK. No sense continuing as everything else depends on it


How to solve it?

With "stopped at" at you mean "I saw this output and nothing seemed to happen so I stopped it with Ctrl-C", right? That is EXACTLY the situation "If compilation of the grammers ..." is talking about: bison generates from the grammar file a C++-code that is thousands of lines long. The compiler will try to optimize this and this may take very long on some machines/compilers. And sometimes the compiler may run out of memory. As the real compuations are taking place elsewhere for these files it is sufficient if they are compiled only with the most basic optimizations. The compile script allows to override this with
<rant>I really sometimes wonder why I try to make the compile-scripts stable if people don't bother to read the output anyway. And no: putting the whole explanation into the script output will probably make situations worse because the young people nowadays don't read documentations/error messages that are more than two lines long and don't have pictures. In the good old days ..... </rant>