CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM

GroovyBC the dynamic cousin of funkySetFields that lives on the suburb of the mesh

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree6Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   March 3, 2010, 16:37
Default
  #101
Senior Member
 
Philippose Rajan
Join Date: Mar 2009
Location: Germany
Posts: 531
Rep Power: 17
philippose will become famous soon enough
Quote:
Originally Posted by gschaider View Post
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
philippose is offline   Reply With Quote

Old   March 3, 2010, 17:06
Default Making sure I'm using this correctly
  #102
Senior Member
 
Michael Jaworski
Join Date: Mar 2009
Location: Champaign, IL, USA
Posts: 126
Rep Power: 9
mike_jaworski is on a distinguished road
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:

Code:
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
mike_jaworski is offline   Reply With Quote

Old   March 4, 2010, 09:25
Default
  #103
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,934
Rep Power: 41
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by bastil View Post
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:

Code:
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 is offline   Reply With Quote

Old   March 4, 2010, 09:30
Default
  #104
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,934
Rep Power: 41
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by philippose View Post
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 is offline   Reply With Quote

Old   March 4, 2010, 10:54
Default
  #105
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,934
Rep Power: 41
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by mike_jaworski View Post
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 &quot;massFlux&quot; which is a calculation based on the equilibrium vapor pressure, there is also a field called &quot;k&quot; for thermal conductivity.

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

Code:
variables &quot;epsilon=1;Aeff=1;sigma=5.67e-8;T0=273;h_fg=19.5e6;&quot;;

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?
gschaider is offline   Reply With Quote

Old   March 4, 2010, 11:12
Default
  #106
Senior Member
 
Michael Jaworski
Join Date: Mar 2009
Location: Champaign, IL, USA
Posts: 126
Rep Power: 9
mike_jaworski is on a distinguished road
Bernard, thank you. Yes. That's what I expected it to do, but I'm newbie enough to wonder.

-Mike
mike_jaworski is offline   Reply With Quote

Old   March 11, 2010, 02:36
Default No success implementing boundary layer inlet profile yet
  #107
bjr
Member
 
Ben Racine
Join Date: Mar 2009
Location: Seattle, WA, USA
Posts: 62
Rep Power: 9
bjr is on a distinguished road
Send a message via AIM to bjr Send a message via Skype™ to 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"
}


// ************************************************** *********************** //
bjr is offline   Reply With Quote

Old   March 12, 2010, 06:57
Default installation problems o
  #108
New Member
 
Join Date: May 2009
Posts: 21
Rep Power: 9
thomasduerr is on a distinguished road
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
thomasduerr is offline   Reply With Quote

Old   March 15, 2010, 06:27
Default
  #109
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,934
Rep Power: 41
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by thomasduerr View Post
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 is offline   Reply With Quote

Old   March 15, 2010, 06:38
Default
  #110
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,934
Rep Power: 41
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by bjr View Post
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
gschaider is offline   Reply With Quote

Old   March 15, 2010, 17:02
Default
  #111
bjr
Member
 
Ben Racine
Join Date: Mar 2009
Location: Seattle, WA, USA
Posts: 62
Rep Power: 9
bjr is on a distinguished road
Send a message via AIM to bjr Send a message via Skype™ to 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 .

Last edited by bjr; March 15, 2010 at 20:41.
bjr is offline   Reply With Quote

Old   March 16, 2010, 06:44
Default
  #112
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,934
Rep Power: 41
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by bjr View Post
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
gschaider is offline   Reply With Quote

Old   March 16, 2010, 13:51
Default This version works... negative sign to counteract outward normals on inlet?
  #113
bjr
Member
 
Ben Racine
Join Date: Mar 2009
Location: Seattle, WA, USA
Posts: 62
Rep Power: 9
bjr is on a distinguished road
Send a message via AIM to bjr Send a message via Skype™ to 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 is offline   Reply With Quote

Old   March 24, 2010, 17:34
Default Failed wmake libso attempt...
  #114
bjr
Member
 
Ben Racine
Join Date: Mar 2009
Location: Seattle, WA, USA
Posts: 62
Rep Power: 9
bjr is on a distinguished road
Send a message via AIM to bjr Send a message via Skype™ to 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
bjr is offline   Reply With Quote

Old   March 24, 2010, 18:02
Default
  #115
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,934
Rep Power: 41
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by bjr View Post
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
gschaider is offline   Reply With Quote

Old   March 24, 2010, 18:20
Default
  #116
bjr
Member
 
Ben Racine
Join Date: Mar 2009
Location: Seattle, WA, USA
Posts: 62
Rep Power: 9
bjr is on a distinguished road
Send a message via AIM to bjr Send a message via Skype™ to bjr
I have on my local machine, but not here on the cluster.
bjr is offline   Reply With Quote

Old   March 24, 2010, 18:20
Default
  #117
bjr
Member
 
Ben Racine
Join Date: Mar 2009
Location: Seattle, WA, USA
Posts: 62
Rep Power: 9
bjr is on a distinguished road
Send a message via AIM to bjr Send a message via Skype™ to 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)
bjr is offline   Reply With Quote

Old   March 25, 2010, 03:22
Default
  #118
New Member
 
Join Date: May 2009
Posts: 21
Rep Power: 9
thomasduerr is on a distinguished road
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
thomasduerr is offline   Reply With Quote

Old   March 25, 2010, 05:10
Default
  #119
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,934
Rep Power: 41
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by bjr View Post
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 is offline   Reply With Quote

Old   March 25, 2010, 05:12
Default
  #120
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,934
Rep Power: 41
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by thomasduerr View Post
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.
gschaider is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
FunkySetFields for OF 141 mer OpenFOAM Pre-Processing 71 June 11, 2014 11:34
Running funkySetFields sara OpenFOAM Running, Solving & CFD 10 October 3, 2012 10:08
FunkySetFields dictionary gschaider OpenFOAM Running, Solving & CFD 14 December 3, 2008 22:13
FunkySetFields for cyclic bc zakifoam OpenFOAM Pre-Processing 1 December 18, 2007 08:24


All times are GMT -4. The time now is 22:13.