[philippose]

Originally Posted by gschaider

The ideal solution would be: you promise to behave, tell me your Sourceforge-account-name and I'll set you up for write access. Write access is not meant to be an ultra-exclusive club (the more the merrier), it's just that we want to be sure that people know what they're doing (which I assume, you do)
Bernhard

Hello Bernhard,

A Good Evening to you....!

I apologise for my silence and delay in replying to your post.... the last few days have been quite hectic at work, and on the Netgen Mesher front.

So... regarding the SVN access..... I think I should be able to manage the responsibility of write access to the repository :-)! As long as I can revert any accidental changes I might probably make, it should be fine....

I am currently a part of the Netgen Mesher project on Sourceforge, and since we use SVN there too, I am not new to SVN.

Wishing you a nice day ahead!

Philippose

[mike_jaworski]

Hello groovy Foamers:

I have a quick question on the groovyBC because I want to make sure I'm using it correctly. groovyBC is really awesome, by the way.

Namely, I am implementing a heat flux boundary with it that includes radiation and evaporative power loss. In my solver, I have a field called "massFlux" which is a calculation based on the equilibrium vapor pressure, there is also a field called "k" for thermal conductivity.

So my groovyBC expression for the temperature field looks like this:

variables "epsilon=1;Aeff=1;sigma=5.67e-8;T0=273;h_fg=19.5e6;";

gradientExpression "<q_input_expression_not_important>-epsilon*Aeff*sigma*(pow((T+273),4)-pow(T0,4) ) - massFlux*h_fg*Aeff)/(internalField(k))";

valueExpression "300";
fractionExpression "0";

By the way, I found that by just defining gradientExpression, but not value and fraction, the BC would fail. Also, I had to add the libOpenFoam.so *before* having the groovyBC lib in the controlDict. I don't know why the order would matter, but it does for me.

So, my question is this: does this look about right? The units for the radiative and evaporation all work out to W/m2, which is the correct thing to use since the massFlux field is kg/(m2s).

[EDIT] More specifically, does the OpenFOAM and groovyBC framework apply the necessary mathematics to take the field values of massFlux, apply them to the boundary patch such that the equation above, massFlux*enthalpy of vaporization* area parameter come up correctly for a power flux?[/EDIT]

Input greatly appreciated.

Regards,
Mike Jaworski

[gschaider]

Originally Posted by bastil

That seems to be an issue of the non-system bison 2.4.1 which does not work with the system m4. I tried the system bison 2.1 and now I get:

wmake
Making dependency list for source file ValueExpressionParser.yy
could not open file ValueExpressionParser.tab.hh for source file ValueExpressionParser.yy
Making dependency list for source file ValueExpressionLexer.ll
could not open file ValueExpressionParser.tab.hh for source file ValueExpressionLexer.ll
Making dependency list for source file ValueExpressionDriver.C
could not open file ValueExpressionParser.tab.hh for source file ValueExpressionDriver.C
Making dependency list for source file funkySetFields.C
could not open file ValueExpressionParser.tab.hh for source file funkySetFields.C
SOURCE=ValueExpressionParser.yy ; rm -f Make/linux64GccDPOpt/ValueExpressionParser.C Make/linux64GccDPOpt/ValueExpressionParser.tab.hh; bison -ra -v  -d $SOURCE ;  mv *.tab.cc Make/linux64GccDPOpt/ValueExpressionParser.C ; mv *.tab.hh Make/linux64GccDPOpt/ValueExpressionParser.tab.hh ; mv *.hh Make/linux64GccDPOpt ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-40 -IMake/linux64GccDPOpt -I/opt/OpenFOAM/OpenFOAM-1.6/src/finiteVolume/lnInclude -I/opt/OpenFOAM/OpenFOAM-1.6/src/meshTools/lnInclude -IlnInclude -I. -I/opt/OpenFOAM/OpenFOAM-1.6/src/OpenFOAM/lnInclude -I/opt/OpenFOAM/OpenFOAM-1.6/src/OSspecific/POSIX/lnInclude   -fPIC -c  Make/linux64GccDPOpt/ValueExpressionParser.C -o Make/linux64GccDPOpt/ValueExpressionParser.o
In file included from ValueExpressionParser.yy:62,
                 from Make/linux64GccDPOpt/ValueExpressionParser.C:24:
./ValueExpressionDriver.H:23: error: incomplete type ‘ve::ValueExpressionParser’ used in nested name specifier

I'm not sure whether bison 2.1 is still sufficient (like it is stated on the Wiki). The problem is that some version changes in bison modify its C++ support in very subtle ways (I think I saw this problem once. Something with a namespace but I can't reproduce it as my "oldest" bison is 2.3)
Bernhard

[gschaider]

Originally Posted by philippose

Hello Bernhard,

A Good Evening to you....!

I apologise for my silence and delay in replying to your post.... the last few days have been quite hectic at work, and on the Netgen Mesher front.

So... regarding the SVN access..... I think I should be able to manage the responsibility of write access to the repository :-)! As long as I can revert any accidental changes I might probably make, it should be fine....

I am currently a part of the Netgen Mesher project on Sourceforge, and since we use SVN there too, I am not new to SVN.

Wishing you a nice day ahead!

Philippose

Perfect. You're set up for svn write-access. Welcome aboard
Bernhard

[gschaider]

Originally Posted by mike_jaworski

Hello groovy Foamers:

I have a quick question on the groovyBC because I want to make sure I'm using it correctly. groovyBC is really awesome, by the way.

Namely, I am implementing a heat flux boundary with it that includes radiation and evaporative power loss. In my solver, I have a field called "massFlux" which is a calculation based on the equilibrium vapor pressure, there is also a field called "k" for thermal conductivity.

So my groovyBC expression for the temperature field looks like this:

variables "epsilon=1;Aeff=1;sigma=5.67e-8;T0=273;h_fg=19.5e6;";

gradientExpression &quot;<q_input_expression_not_important>-epsilon*Aeff*sigma*(pow((T+273),4)-pow(T0,4) ) - massFlux*h_fg*Aeff)/(internalField(k))&quot;;

valueExpression &quot;300&quot;;
fractionExpression &quot;0&quot;;

By the way, I found that by just defining gradientExpression, but not value and fraction, the BC would fail. Also, I had to add the libOpenFoam.so *before* having the groovyBC lib in the controlDict. I don't know why the order would matter, but it does for me.

So, my question is this: does this look about right? The units for the radiative and evaporation all work out to W/m2, which is the correct thing to use since the massFlux field is kg/(m2s).

[EDIT] More specifically, does the OpenFOAM and groovyBC framework apply the necessary mathematics to take the field values of massFlux, apply them to the boundary patch such that the equation above, massFlux*enthalpy of vaporization* area parameter come up correctly for a power flux?[/EDIT]

Input greatly appreciated.

Regards,
Mike Jaworski

What groovy does is - get the current (it does not trigger any kind of calculation there) values from the other patches (in your case massFlux)
- manipulates them on a per-face basis (so in your case it does "massFlux[faceI]*enthalpy of vaporization[faceI]* area[faceI]" for all faceI
- the variables are expanded to fields the size of the patch and the above applies
Does this answer your question?

[mike_jaworski]

Bernard, thank you. Yes. That's what I expected it to do, but I'm newbie enough to wonder.

-Mike

[bjr]

You can download a run that is known to "work" simply by issuing "simpleFoam" with OpenFOAM 1.6 and groovyBC at...

http://files.me.com/ben.racine/90cb5q

It appears to be working as far as compilation is concerned, but if you run it and check out the results you might see the odd pressure field and the reverse flow coming from the outlet towards the inlet.

This was my attempt to implement a velocity profile inlet condition in the spirit of the pulsedPitzDaily tutorial per: http://openfoamwiki.net/index.php/Co...ulsedPitzDaily

Any ideas and comments graciously welcomed,
Ben Racine

One can recover a somewhat physically reasonable run (no validation) by changing 0/U back to the original configuration as explicitly shown below...


/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 1.6 |
| \\ / A nd | Web: http://www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class volVectorField;
location "0";
object U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

#include "initialConditions"

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

internalField uniform $flowVelocity;

boundaryField
{
//#include "fixedInlet"

inlet
{
type fixedValue;
value $internalField;
type inletOutlet;
inletValue uniform (10 0 0);
}

outlet
{
type inletOutlet;
inletValue uniform (0 0 0);
value $internalField;
}

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

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

#include "frontBackUpperPatches"
}


// ************************************************** *********************** //

[thomasduerr]

Hi everybody,

it seems like I have similar problems as some of you with the installation of groovyBC. My error messages go:

Making dependency list for source file PatchResult.C
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 PatchValueExpressionLexer.ll
could not open file PatchValueExpressionParser.tab.hh for source file PatchValueExpressionLexer.ll
Making dependency list for source file PatchValueExpressionDriver.C
could not open file PatchValueExpressionParser.tab.hh for source file PatchValueExpressionDriver.C
Making dependency list for source file groovyBCFvPatchFields.C
could not open file PatchValueExpressionParser.tab.hh for source file groovyBCFvPatchFields.C
SOURCE=PatchResult.C ; g++ -m64 -Dlinux64 -DWM_DP -Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3 -DNoRepository -ftemplate-depth-40 -IMake/linux64GccDPOpt -I/export/opt/AS/OF/OpenFOAM-1.6.x/src/finiteVolume/lnInclude -IlnInclude -I. -I/export/opt/AS/OF/OpenFOAM-1.6.x/src/OpenFOAM/lnInclude -I/export/opt/AS/OF/OpenFOAM-1.6.x/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linux64GccDPOpt/PatchResult.o
PatchResult.C: In member function ‘void Foam::PatchResult::uglyDelete()’:
PatchResult.C:97: warning: deleting ‘void*’ is undefined
SOURCE=PatchValueExpressionParser.yy ; rm -f Make/linux64GccDPOpt/PatchValueExpressionParser.C Make/linux64GccDPOpt/PatchValueExpressionParser.tab.hh; bison -v -d $SOURCE ; mv *.tab.cc Make/linux64GccDPOpt/PatchValueExpressionParser.C ; mv *.tab.hh Make/linux64GccDPOpt/PatchValueExpressionParser.tab.hh ; mv *.hh Make/linux64GccDPOpt ; g++ -m64 -Dlinux64 -DWM_DP -Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3 -DNoRepository -ftemplate-depth-40 -IMake/linux64GccDPOpt -I/export/opt/AS/OF/OpenFOAM-1.6.x/src/finiteVolume/lnInclude -IlnInclude -I. -I/export/opt/AS/OF/OpenFOAM-1.6.x/src/OpenFOAM/lnInclude -I/export/opt/AS/OF/OpenFOAM-1.6.x/src/OSspecific/POSIX/lnInclude -fPIC -c Make/linux64GccDPOpt/PatchValueExpressionParser.C -o Make/linux64GccDPOpt/PatchValueExpressionParser.o
In file included from PatchValueExpressionParser.yy:52,
from Make/linux64GccDPOpt/PatchValueExpressionParser.C:24:
lnInclude/PatchValueExpressionDriver.H:68: error: incomplete type ‘pve::PatchValueExpressionParser’ used in nested name specifier
lnInclude/PatchValueExpressionDriver.H:68: error: ‘yylval’ was not declared in this scope
lnInclude/PatchValueExpressionDriver.H:68: error: expected primary-expression before ‘*’ token
lnInclude/PatchValueExpressionDriver.H:68: error: ‘yylloc’ was not declared in this scope
lnInclude/PatchValueExpressionDriver.H:68: error: expected primary-expression before ‘&’ token
lnInclude/PatchValueExpressionDriver.H:68: error: ‘driver’ was not declared in this scope
lnInclude/PatchValueExpressionDriver.H:68: error: initializer expression list treated as compound expression
PatchValueExpressionParser.tab.cc: In member function ‘virtual int yy::PatchValueExpressionParser:arse()’:
PatchValueExpressionParser.tab.cc:504: error: ‘pvelex’ cannot be used as a function
PatchValueExpressionParser.tab.cc: In member function ‘unsigned char yy::PatchValueExpressionParser::yytranslate_(int)’ :
PatchValueExpressionParser.tab.cc:3981: warning: use of old-style cast
PatchValueExpressionParser.yy: At global scope:
PatchValueExpressionParser.yy:695: error: expected unqualified-id before ‘&’ token
PatchValueExpressionParser.yy:695: error: expected ‘,’ or ‘...’ before ‘&’ token
PatchValueExpressionParser.yy:695: error: invalid use of incomplete type ‘struct pve::PatchValueExpressionParser’
lnInclude/PatchValueExpressionDriver.H:63: error: forward declaration of ‘struct pve::PatchValueExpressionParser’
make: *** [Make/linux64GccDPOpt/PatchValueExpressionParser.o] Error 1


Like some of you wrote in the forum, I have tried commenting out the Make/files groovyBCPointPatchFields.C but no progress. I have Bison 2.1 is that the main problem?

Thanks for your help!
Thomas

[gschaider]

Originally Posted by thomasduerr

Like some of you wrote in the forum, I have tried commenting out the Make/files groovyBCPointPatchFields.C but no progress. I have Bison 2.1 is that the main problem?

Probably. The "oldest" bison I have available is 2.3 so I can't really test it. Anybody got experience with groovy and older bisons?

[gschaider]

Originally Posted by bjr

You can download a run that is known to "work" simply by issuing "simpleFoam" with OpenFOAM 1.6 and groovyBC at...

http://files.me.com/ben.racine/90cb5q

It appears to be working as far as compilation is concerned, but if you run it and check out the results you might see the odd pressure field and the reverse flow coming from the outlet towards the inlet.

This was my attempt to implement a velocity profile inlet condition in the spirit of the pulsedPitzDaily tutorial per: http://openfoamwiki.net/index.php/Co...ulsedPitzDaily

Any ideas and comments graciously welcomed,
Ben Racine

One can recover a somewhat physically reasonable run (no validation) by changing 0/U back to the original configuration as explicitly shown below...

What would be more interesting would be the actual expressions you're using (don't feel like looking at the complete case)

Bernhard

[bjr]

In 0/U, the inlet condition that gives physical results...

inlet
{
type fixedValue;
value $internalField;
}

And a groovy BC attempt to do the same thing that results in very odd flow-field... although the inlet is specified correctly.

inlet
{
type groovyBC;
variables "zp=pts().z;minZ=min(zp);maxZ=max(zp);power=1.0*no rmal();";
valueExpression "90*power";
value $internalField;
}

Where...

internalField uniform (90 0 0);

A cleaned up version (still run with just simpleFoam) with new geometry lives here if anybody cares to download it http://files.me.com/ben.racine/225fzi .

[gschaider]

Originally Posted by bjr

In 0/U, the inlet condition that gives physical results...

inlet
{
type fixedValue;
value $internalField;
}

And a groovy BC attempt to do the same thing that results in very odd flow-field... although the inlet is specified correctly.

inlet
{
type groovyBC;
variables "zp=pts().z;minZ=min(zp);maxZ=max(zp);power=1.0*no rmal();";
valueExpression "90*power";
value $internalField;
}

Where...

internalField uniform (90 0 0);

A cleaned up version (still run with just simpleFoam) with new geometry lives here if anybody cares to download it http://files.me.com/ben.racine/225fzi .

Just some comments:
- Why do you calclulate maxZ and minZ if you don't use them?
- Your formulation assumes that z is >=0?
- Have you had a look at the values on the patch on its own? Either by looking at the file (first written timestep) or by looking at paraview (deselect the internal mesh, select the patch)?
- If you post excerpts from a dictionary please enclose them in CODE-tags: I can't see the actual expression because the board interprets the curly brackets. The mail that it sends out doesn't show the text (so I had to piece together your posting from two sources)

Bernhard

[bjr]

/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 1.6 |
| \\ / A nd | Web: http://www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class volVectorField;
location "0";
object U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

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

internalField uniform (90 0 0);

boundaryField
{

inlet
{
type groovyBC;

variables "zp=pts().z;minZ=min(zp);maxZ=max(zp);para=-pow(pos().z/0.390667,0.13)*normal();";
valueExpression "90*(1+0.00005*sin(500*time()))*para";
value uniform (90 0 0);
}

outlet
{
type inletOutlet;
inletValue uniform (0 0 0);
value uniform (90 0 0);
}

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

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

#include "frontBackUpperPatches"
}


// ************************************************** *********************** //

[bjr]

I'm trying to install groovyBC on my cluster and get...

host2:~/OpenFOAM/openfoam-extend/trunk/Breeder_1.6/libraries/groovyBC # wmake libso
/usr/lib64/gcc/x86_64-suse-linux/4.4/cc1: /root/OpenFOAM/ThirdParty-1.6/gcc-4.3.3/platforms/linux64/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/lib64/libppl_c.so.2)
/usr/lib64/gcc/x86_64-suse-linux/4.4/cc1: /root/OpenFOAM/ThirdParty-1.6/gcc-4.3.3/platforms/linux64/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/lib64/libppl.so.7)
/usr/lib64/gcc/x86_64-suse-linux/4.4/cc1: /root/OpenFOAM/ThirdParty-1.6/gcc-4.3.3/platforms/linux64/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/lib64/libgmpxx.so.4)
make: *** [linux64GccDPOpt/options] Error 1
/usr/lib64/gcc/x86_64-suse-linux/4.4/cc1: /root/OpenFOAM/ThirdParty-1.6/gcc-4.3.3/platforms/linux64/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/lib64/libppl_c.so.2)
/usr/lib64/gcc/x86_64-suse-linux/4.4/cc1: /root/OpenFOAM/ThirdParty-1.6/gcc-4.3.3/platforms/linux64/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/lib64/libppl.so.7)
/usr/lib64/gcc/x86_64-suse-linux/4.4/cc1: /root/OpenFOAM/ThirdParty-1.6/gcc-4.3.3/platforms/linux64/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/lib64/libgmpxx.so.4)
make: *** [linux64GccDPOpt/files] Error 1
wmake error: file 'Make/linux64GccDPOpt/objectFiles' could not be created

host2:~/OpenFOAM/openfoam-extend/trunk/Breeder_1.6/libraries/groovyBC # bison -V
bison (GNU Bison) 2.3
Written by Robert Corbett and Richard Stallman.

Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

host2:~/OpenFOAM/openfoam-extend/trunk/Breeder_1.6/libraries/groovyBC # flex -V
flex 2.5.35

[gschaider]

Originally Posted by bjr

I'm trying to install groovyBC on my cluster and get...

host2:~/OpenFOAM/openfoam-extend/trunk/Breeder_1.6/libraries/groovyBC # wmake libso
/usr/lib64/gcc/x86_64-suse-linux/4.4/cc1: /root/OpenFOAM/ThirdParty-1.6/gcc-4.3.3/platforms/linux64/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/lib64/libppl_c.so.2)

This is not a problem wit groovyBC, but a problem with the libaries from your system (libppl_c.so.2) not fitting the standard-libraries that come with OpenFOAM (libstdc++.so.6). BTW: It looks like your using the system-compiler and not the OF-compiler. Is this intended?

Have you successfully compiled any other OF-Software on your Cluster?

Bernhard

[bjr]

I have on my local machine, but not here on the cluster.

[bjr]

host1:~/OpenFOAM/openfoam-extend/trunk/Breeder_1.6/libraries/groovyBC # which gcc
/root/OpenFOAM/ThirdParty-1.6/gcc-4.3.3/platforms/linux64/bin/gcc
host1:~/OpenFOAM/openfoam-extend/trunk/Breeder_1.6/libraries/groovyBC # gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --with-pkgversion=OpenFOAM --enable-__cxa_atexit --enable-libstdcxx-allocator=new --with-system-zlib --prefix=/home/dm2/henry/OpenFOAM/ThirdParty/gcc-4.3.3/platforms/linux64 --with-mpfr=/home/dm2/henry/OpenFOAM/ThirdParty/mpfr-2.4.1/platforms/linux64 --with-gmp=/home/dm2/henry/OpenFOAM/ThirdParty/gmp-4.2.4/platforms/linux64
Thread model: posix
gcc version 4.3.3 (OpenFOAM)

[thomasduerr]

hi everybody,

the newest Bison I could get on our systems is Bison 2.3.

I still get the same errors when compiling:
wmake libso
Making dependency list for source file PatchResult.C
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 PatchValueExpressionLexer.ll
could not open file PatchValueExpressionParser.tab.hh for source file PatchValueExpressionLexer.ll
Making dependency list for source file PatchValueExpressionDriver.C
could not open file PatchValueExpressionParser.tab.hh for source file PatchValueExpressionDriver.C
Making dependency list for source file groovyBCFvPatchFields.C
could not open file PatchValueExpressionParser.tab.hh for source file groovyBCFvPatchFields.C
SOURCE=PatchResult.C ; g++ -m64 -Dlinux64 -DWM_DP -Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3 -DNoRepository -ftemplate-depth-40 -IMake/linux64GccDPOpt -I/home/acrobat/webe_ol/OpenFOAM/OpenFOAM-1.6/src/finiteVolume/lnInclude -IlnInclude -I. -I/home/acrobat/webe_ol/OpenFOAM/OpenFOAM-1.6/src/OpenFOAM/lnInclude -I/home/acrobat/webe_ol/OpenFOAM/OpenFOAM-1.6/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linux64GccDPOpt/PatchResult.o
PatchResult.C: In member function ‘void Foam::PatchResult::uglyDelete()’:
PatchResult.C:97: warning: deleting ‘void*’ is undefined
SOURCE=PatchValueExpressionParser.yy ; rm -f Make/linux64GccDPOpt/PatchValueExpressionParser.C Make/linux64GccDPOpt/PatchValueExpressionParser.tab.hh; bison -v -d $SOURCE ; mv *.tab.cc Make/linux64GccDPOpt/PatchValueExpressionParser.C ; mv *.tab.hh Make/linux64GccDPOpt/PatchValueExpressionParser.tab.hh ; mv *.hh Make/linux64GccDPOpt ; g++ -m64 -Dlinux64 -DWM_DP -Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3 -DNoRepository -ftemplate-depth-40 -IMake/linux64GccDPOpt -I/home/acrobat/webe_ol/OpenFOAM/OpenFOAM-1.6/src/finiteVolume/lnInclude -IlnInclude -I. -I/home/acrobat/webe_ol/OpenFOAM/OpenFOAM-1.6/src/OpenFOAM/lnInclude -I/home/acrobat/webe_ol/OpenFOAM/OpenFOAM-1.6/src/OSspecific/POSIX/lnInclude -fPIC -c Make/linux64GccDPOpt/PatchValueExpressionParser.C -o Make/linux64GccDPOpt/PatchValueExpressionParser.o
PatchValueExpressionParser.tab.cc: In member function ‘unsigned char pve::PatchValueExpressionParser::yytranslate_(int) ’:
PatchValueExpressionParser.tab.cc:4030: warning: use of old-style cast
SOURCE=PatchValueExpressionLexer.ll ; rm Make/linux64GccDPOpt/PatchValueExpressionLexer.C ; flex -f $SOURCE ; mv *.c Make/linux64GccDPOpt/PatchValueExpressionLexer.C ; g++ -m64 -Dlinux64 -DWM_DP -Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3 -DNoRepository -ftemplate-depth-40 -IMake/linux64GccDPOpt -I/home/acrobat/webe_ol/OpenFOAM/OpenFOAM-1.6/src/finiteVolume/lnInclude -IlnInclude -I. -I/home/acrobat/webe_ol/OpenFOAM/OpenFOAM-1.6/src/OpenFOAM/lnInclude -I/home/acrobat/webe_ol/OpenFOAM/OpenFOAM-1.6/src/OSspecific/POSIX/lnInclude -fPIC -c Make/linux64GccDPOpt/PatchValueExpressionLexer.C -o Make/linux64GccDPOpt/PatchValueExpressionLexer.o
rm: cannot remove `Make/linux64GccDPOpt/PatchValueExpressionLexer.C': No such file or directory
/bin/sh: flex: command not found
mv: cannot stat `*.c': No such file or directory
g++: Make/linux64GccDPOpt/PatchValueExpressionLexer.C: No such file or directory
g++: no input files
make: *** [Make/linux64GccDPOpt/PatchValueExpressionLexer.o] Error 1


Anybody got some ideas? It still looks like a bison problem, doesn't it?

Thanks
Thomas

[gschaider]

Originally Posted by bjr

host1:~/OpenFOAM/openfoam-extend/trunk/Breeder_1.6/libraries/groovyBC # which gcc
/root/OpenFOAM/ThirdParty-1.6/gcc-4.3.3/platforms/linux64/bin/gcc
host1:~/OpenFOAM/openfoam-extend/trunk/Breeder_1.6/libraries/groovyBC # gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --with-pkgversion=OpenFOAM --enable-__cxa_atexit --enable-libstdcxx-allocator=new --with-system-zlib --prefix=/home/dm2/henry/OpenFOAM/ThirdParty/gcc-4.3.3/platforms/linux64 --with-mpfr=/home/dm2/henry/OpenFOAM/ThirdParty/mpfr-2.4.1/platforms/linux64 --with-gmp=/home/dm2/henry/OpenFOAM/ThirdParty/gmp-4.2.4/platforms/linux64
Thread model: posix
gcc version 4.3.3 (OpenFOAM)

Yeah. But in your original posting a cc1 (not sure what that is, I guess a compiler stage) from your systems installation (Susi, gcc 4.4) was complaining

[gschaider]

Originally Posted by thomasduerr

hi everybody,

the newest Bison I could get on our systems is Bison 2.3.

I still get the same errors when compiling:
wmake libso
Making dependency list for source file PatchResult.C
Making dependency list for source file PatchValueExpressionParser.yy

<snip>

/bin/sh: flex: command not found
mv: cannot stat `*.c': No such file or directory
g++: Make/linux64GccDPOpt/PatchValueExpressionLexer.C: No such file or directory
g++: no input files
make: *** [Make/linux64GccDPOpt/PatchValueExpressionLexer.o] Error 1


Anybody got some ideas? It still looks like a bison problem, doesn't it?

No. It's a missing-flex-problem. The "command not found" is a strong indication.