CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Installation (http://www.cfd-online.com/Forums/openfoam-installation/)
-   -   swak4Foam installation on 2.0 (http://www.cfd-online.com/Forums/openfoam-installation/93098-swak4foam-installation-2-0-a.html)

fisch October 5, 2011 02:18

swak4Foam installation on 2.0
 
Hi.
I have problems installing swak4Foam on my kubuntu machine.

The error occurs during compiling/building the stuff in the Utilities folder and leads to the following error message:

/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/pTraits.H(53): error: not a class or struct name
public PrimitiveType
^
detected during instantiation of class "Foam:: pTraits<PrimitiveType> [with PrimitiveType=char [68]]" at line 71 of "funkySetBoundaryField.C"


This occurs a lot of times in each of the contents of the utilities folder.
Can anybody help me or give me a hint?

Thanks,
rupert

gschaider October 5, 2011 04:36

Quote:

Originally Posted by fisch (Post 326723)
Hi.
I have problems installing swak4Foam on my kubuntu machine.

The error occurs during compiling/building the stuff in the Utilities folder and leads to the following error message:

/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/pTraits.H(53): error: not a class or struct name
public PrimitiveType
^
detected during instantiation of class "Foam:: pTraits<PrimitiveType> [with PrimitiveType=char [68]]" at line 71 of "funkySetBoundaryField.C"


This occurs a lot of times in each of the contents of the utilities folder.
Can anybody help me or give me a hint?

Thanks,
rupert

That is strange. The line you're refering to is the middle of a "WarningIn"-stream.

Questions:
- versions? g++, OF (which commit are you on as it is a git-version), swak4Foam (same here: hg or svn)
- have you ever compiled another 3rd-party thing under this OF version?
- is there some other error message further up north (especially on about "missing headers"

fisch October 5, 2011 06:54

Hi

I'm using OpenFoam2.0.x (3 months old) and the corresponding (1 day old) swak svn version.
I'm using a Icc compiler.


Here is the begin compiler output:

~/software/OpenFOAM/own-2.0.x/swak4Foam$ ./Allwmake
Reading variables from 'swakConfiguration'
'/home/rupert/software/OpenFOAM/own-2.0.x/platforms/linux64IccDPOpt/lib/libswak4FoamParsers.so' is up to date.
'/home/rupert/software/OpenFOAM/own-2.0.x/platforms/linux64IccDPOpt/lib/libgroovyBC.so' is up to date.
'/home/rupert/software/OpenFOAM/own-2.0.x/platforms/linux64IccDPOpt/lib/libswakFunctionObjects.so' is up to date.
'/home/rupert/software/OpenFOAM/own-2.0.x/platforms/linux64IccDPOpt/lib/libsimpleFunctionObjects.so' is up to date.
'/home/rupert/software/OpenFOAM/own-2.0.x/platforms/linux64IccDPOpt/lib/libsimpleSwakFunctionObjects.so' is up to date.
'/home/rupert/software/OpenFOAM/own-2.0.x/platforms/linux64IccDPOpt/lib/libswakTopoSources.so' is up to date.
'/home/rupert/software/OpenFOAM/own-2.0.x/platforms/linux64IccDPOpt/lib/libswakSourceFields.so' is up to date.
'/home/rupert/software/OpenFOAM/own-2.0.x/platforms/linux64IccDPOpt/lib/libgroovyStandardBCs.so' is up to date.
'/home/rupert/software/OpenFOAM/own-2.0.x/platforms/linux64IccDPOpt/lib/libpythonIntegration.so' is up to date.
SOURCE=funkySetFields.C ; icpc -std=c++0x -Dlinux64 -DWM_DP -wd327,654,819,1125,1476,1505,1572 -xHost -O3 -no-prec-div -DNoRepository -IMake/linux64IccDPOpt -I/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/finiteVolume/lnInclude -I/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/meshTools/lnInclude -I../../Libraries/swak4FoamParsers/lnInclude/ -IlnInclude -I. -I/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude -I/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linux64IccDPOpt/funkySetFields.o
/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/pTraits.H(53): error: not a class or struct name
public PrimitiveType
^
detected during instantiation of class "Foam::pTraits<PrimitiveType> [with PrimitiveType=char [19]]" at line 151 of "funkySetFields.C"

/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/pTraits.H(53): error: not a class or struct name
public PrimitiveType
^
detected during instantiation of class "Foam::pTraits<PrimitiveType> [with PrimitiveType=char [11]]" at line 152 of "funkySetFields.C"


... and so on.

thanks for your help

gschaider October 5, 2011 17:00

Quote:

Originally Posted by fisch (Post 326761)
Hi

I'm using OpenFoam2.0.x (3 months old) and the corresponding (1 day old) swak svn version.
I'm using a Icc compiler.


Here is the begin compiler output:

~/software/OpenFOAM/own-2.0.x/swak4Foam$ ./Allwmake

SOURCE=funkySetFields.C ; icpc -std=c++0x -Dlinux64 -DWM_DP -wd327,654,819,1125,1476,1505,1572 -xHost -O3 -no-prec-div -DNoRepository -IMake/linux64IccDPOpt -I/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/finiteVolume/lnInclude -I/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/meshTools/lnInclude -I../../Libraries/swak4FoamParsers/lnInclude/ -IlnInclude -I. -I/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude -I/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linux64IccDPOpt/funkySetFields.o
/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/pTraits.H(53): error: not a class or struct name
public PrimitiveType
^
detected during instantiation of class "Foam::pTraits<PrimitiveType> [with PrimitiveType=char [19]]" at line 151 of "funkySetFields.C"

/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/pTraits.H(53): error: not a class or struct name
public PrimitiveType
^
detected during instantiation of class "Foam::pTraits<PrimitiveType> [with PrimitiveType=char [11]]" at line 152 of "funkySetFields.C"


... and so on.

thanks for your help

No idea. All the error messages you've shown so far seem to refer to the string-constants in WarningIn or FatalErrorIn-streams.

I think that the Intel-compiler is to blame. Strange thing is that you were obviously able to compile the OF-distro with it .... and ... even stranger .... that the swak-libraries were successfully compiled with it ... and they also have WarningIn/FatalErrorIn-streams.

Sorry. There is not much I can do here without an Intel-compiler. Maybe someone else has one and has already solved the problem

fisch November 2, 2011 06:51

hi Bernhard,

i tested a few things and i found out the following:

if i replace the Info expression by cout the problem is solved on this place.
So it seems that something with this Info stuff doesn't work nicely.

If the compiler error were only in the swak files this could solve the problem.
But there are the same errors from files within the OF/src which i don't want to touch...

Is there maybe some include missing or something else???
The errors come again during compilation of funkySetBoundaryField.C and so on...


Thanks a lot,
rupert



Compilation error:
Making dependency list for source file funkySetFields.C
SOURCE=funkySetFields.C ; icpc -std=c++0x -Dlinux64 -DWM_DP -wd327,654,819,1125,1476,1505,1572 -xHost -O3 -no-prec-div -DNoRepository -IMake/linux64IccDPOpt -I/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/finiteVolume/lnInclude -I/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/meshTools/lnInclude -I../../Libraries/swak4FoamParsers/lnInclude/ -IlnInclude -I. -I/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude -I/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linux64IccDPOpt/funkySetFields.o
/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/pTraits.H(53): error: not a class or struct name
public PrimitiveType
^
detected during instantiation of class "Foam::pTraits<PrimitiveType> [with PrimitiveType=char [13]]" at line 5 of "/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/createTime.H"

/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/pTraits.H(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 5 of "/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/createTime.H"

/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/pTraits.H(53): error: not a class or struct name
public PrimitiveType
^
detected during instantiation of class "Foam::pTraits<PrimitiveType> [with PrimitiveType=char]" at line 11 of "/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/createNamedMesh.H"

/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/pTraits.H(53): error: not a class or struct name
public PrimitiveType
^
detected during instantiation of class "Foam::pTraits<PrimitiveType> [with PrimitiveType=char [24]]" at line 18 of "/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/createNamedMesh.H"

gschaider November 3, 2011 05:07

Quote:

Originally Posted by fisch (Post 330423)
hi Bernhard,

i tested a few things and i found out the following:

if i replace the Info expression by cout the problem is solved on this place.
So it seems that something with this Info stuff doesn't work nicely.

This only "solves" the problem for serial runs. For parallel runs you'll get the the output on every processor

Quote:

Originally Posted by fisch (Post 330423)
If the compiler error were only in the swak files this could solve the problem.
But there are the same errors from files within the OF/src which i don't want to touch...

Wait a minute. Until now I was under the impression that you successfully compiled OF using the Intel compiler.

Or do you mean "during the compilation of Swak this occurs in some OF/src-files"

Quote:

Originally Posted by fisch (Post 330423)
Is there maybe some include missing or something else???
The errors come again during compilation of funkySetBoundaryField.C and so on...

The fvCFD.H is there and there are some utilities that only have that so it should be sufficient.

Quote:

Originally Posted by fisch (Post 330423)
Thanks a lot,
rupert



Compilation error:
Making dependency list for source file funkySetFields.C
SOURCE=funkySetFields.C ; icpc -std=c++0x -Dlinux64 -DWM_DP -wd327,654,819,1125,1476,1505,1572 -xHost -O3 -no-prec-div -DNoRepository -IMake/linux64IccDPOpt -I/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/finiteVolume/lnInclude -I/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/meshTools/lnInclude -I../../Libraries/swak4FoamParsers/lnInclude/ -IlnInclude -I. -I/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude -I/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OSspecific/POSIX/lnInclude -fPIC -c $SOURCE -o Make/linux64IccDPOpt/funkySetFields.o
/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/pTraits.H(53): error: not a class or struct name
public PrimitiveType
^
detected during instantiation of class "Foam::pTraits<PrimitiveType> [with PrimitiveType=char [13]]" at line 5 of "/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/createTime.H"

/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/pTraits.H(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 5 of "/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/createTime.H"

/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/pTraits.H(53): error: not a class or struct name
public PrimitiveType
^
detected during instantiation of class "Foam::pTraits<PrimitiveType> [with PrimitiveType=char]" at line 11 of "/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/createNamedMesh.H"

/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/pTraits.H(53): error: not a class or struct name
public PrimitiveType
^
detected during instantiation of class "Foam::pTraits<PrimitiveType> [with PrimitiveType=char [24]]" at line 18 of "/home/rupert/software/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude/createNamedMesh.H"

Looks like a problem with the template instantiation. The constant strings are used as a separate type (instead of "char *" with which i guess - havn't checked- pTraits could cope).

I really have no way to investigate this with an Intel compiler.

I'm not quite sure whether all the Foam::-namespace specifications in the funkySetFields.C are still necessary. Maybe that throws him off the track .... but that is a wild guess

Bernhard

fisch November 3, 2011 06:15

[QUOTE=gschaider;330561
Wait a minute. Until now I was under the impression that you successfully compiled OF using the Intel compiler.

Or do you mean "during the compilation of Swak this occurs in some OF/src-files"



The fvCFD.H is there and there are some utilities that only have that so it should be sufficient.



Looks like a problem with the template instantiation. The constant strings are used as a separate type (instead of "char *" with which i guess - havn't checked- pTraits could cope).
[/QUOTE]


OF compiles without any problem.

The Info function are producing compiler errors all over the swak files, but nowhere in OF else...

maruthamuthu_venkatraman November 3, 2011 06:23

Swak4Foam installation on OpenFOAM2.0.x in Ubuntu 10.04
 
Hello,
If anyone of you have a look at the log file and tell me whats the cause of this error. please note I successfully compiled OpenFOAM2.0.x without any flaws. Is there any additional package that i needed to compile Swak4Foam ?

Thanks and Regards
Muthu

maruthamuthu_venkatraman November 3, 2011 06:26

OpenF
 
1 Attachment(s)
Logfile is attached herewith

gschaider November 3, 2011 07:34

Quote:

Originally Posted by fisch (Post 330575)
OF compiles without any problem.

OK. Just checking.
Quote:

Originally Posted by fisch (Post 330575)
The Info function are producing compiler errors all over the swak files, but nowhere in OF else...

"all over". I was under the impression (from your initial posting) that the Library compiles OK but you only had problems with the utilities. Or did I misunderstand you.

As I said before (several times) I don't have an Intel-compiler so I'll have to ask you to try/check some stuff:

- does the icc have a "gcc-compatibility"-mode? If yes: could you try that on Swak
- remove all the Foam:: from funkySetFields.C, it should still compile. I don't think this is the problem but its worth the try
- Am I right that the error always is for some instantiation of pTraits for a "char[N]"-variable?
- Does this error happen for ALL instances of code like
Info << "some text"
in the sources or only in some (templates for instance)
- Throw out (or comment out) EVERYTHING in funkySetFields.C except for the #includes and in the main only add a line
Info << "I'm outta here" << endl;
and see if it compiles. If it fails comment out the Driver-include and see if that compiles (then the problem must be somewhere in the swak-headers)

Bernhard

gschaider November 3, 2011 12:17

Quote:

Originally Posted by maruthamuthu_venkatraman (Post 330578)
Hello,
If anyone of you have a look at the log file and tell me whats the cause of this error. please note I successfully compiled OpenFOAM2.0.x without any flaws. Is there any additional package that i needed to compile Swak4Foam ?

Please post the first error message instead of attaching log-files. It makes answering easier. In your case that would be

Code:

SOURCE=FieldValueExpressionParser.yy ; rm -f Make/linux64GccDPOpt/FieldValueExpressionParser.C Make/linux64GccDPOpt/FieldValueExpressionParser.tab.hh; bison -ra -v  -d $SOURCE ;  mv *.tab.cc Make/linux64GccDPOpt/FieldValueExpressionParser.C ; sed -i.bak "s/position.hh/FieldValueExpressionParser_position.hh/" location.hh ; mv location.hh lnInclude/FieldValueExpressionParser_location.hh ; mv stack.hh lnInclude/FieldValueExpressionParser_stack.hh ; mv position.hh lnInclude/FieldValueExpressionParser_position.hh ; sed -i.bak "s/stack.hh/FieldValueExpressionParser_stack.hh/;s/location.hh/FieldValueExpressionParser_location.hh/" FieldValueExpressionParser.tab.hh ;mv *.hh lnInclude ; touch -r $SOURCE lnInclude/FieldValueExpressionParser*.hh ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -IMake/linux64GccDPOpt -I/home/mmv/OpenFOAM/OpenFOAM-2.0.x/src/finiteVolume/lnInclude -I/home/mmv/OpenFOAM/OpenFOAM-2.0.x/src/sampling/lnInclude -I/home/mmv/OpenFOAM/OpenFOAM-2.0.x/src/triSurface/lnInclude -I/home/mmv/OpenFOAM/OpenFOAM-2.0.x/src/lagrangian/basic/lnInclude -I/home/mmv/OpenFOAM/OpenFOAM-2.0.x/src/meshTools/lnInclude -IlnInclude -I. -I/home/mmv/OpenFOAM/OpenFOAM-2.0.x/src/OpenFOAM/lnInclude -I/home/mmv/OpenFOAM/OpenFOAM-2.0.x/src/OSspecific/POSIX/lnInclude  -fPIC -c  Make/linux64GccDPOpt/FieldValueExpressionParser.C -o Make/linux64GccDPOpt/FieldValueExpressionParser.o
bison: invalid option -- 'r'
Usage: bison [-dltvyVu] [-b file-prefix] [-p name-prefix]
      [-o outfile] [-h headerfile]
      [-S skeleton] [-H header-skeleton]
      [--debug] [--defines] [--fixed-output-files] [--no-lines]
      [--verbose] [--version] [--yacc] [--usage] [--help]
      [--file-prefix=prefix] [--name-prefix=prefix]
      [--skeleton=skeletonfile] [--headerskeleton=headerskeletonfile]
      [--output=outfile] [--header-name=header] grammar-file

What version of bison are you using (check with 'bison -V')? Yours doesn't seem to know the -r (report) option which probably means that it is quite old (you can try removing the -r from the mybison-file but my goes is that it won't interpret the grammar correctly due to its age

maruthamuthu_venkatraman November 3, 2011 13:28

Hello Bernard,
Thanks for your reply. Hereafter I will post the error part instead of sending the log files. Here is the bison version.

bison++ Version 1.21.9-1, adapted from GNU bison by coetmeur@icdc.fr
Maintained by Magnus Ekdahl <magnus@debian.org>

maruthamuthu_venkatraman November 3, 2011 14:01

Hello Bernard,
You are right, the bison version is old. After updating the new version i can able to compile without any flaws. Thanks for your hint.

New Version:

bison (GNU Bison) 2.4.1
Written by Robert Corbett and Richard Stallman.

Copyright (C) 2008 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.

Also some examples from groovyBC was tested.

Thanks for your contribution by maintaining this swak4Foam for various OF versions.

Muthu

gschaider November 4, 2011 04:39

Quote:

Originally Posted by maruthamuthu_venkatraman (Post 330642)
Hello Bernard,
You are right, the bison version is old. After updating the new version i can able to compile without any flaws. Thanks for your hint.

New Version:

bison (GNU Bison) 2.4.1
Written by Robert Corbett and Richard Stallman.

Copyright (C) 2008 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.

Also some examples from groovyBC was tested.

Great that it works. So I'm asking what I ask of everyone that I assist here: could you add the information that would have helped you avoid this problem to the Wiki-page of swak (you don't have to go overboard. Something about "fairly recent version of bison" "2.4.1 has been known to work" in the requirements would be sufficient.

Thanks

wyldckat November 5, 2011 06:35

Greetings to all! Bernhard and Rupert, this post is for you two:

Bernhard, I think I've found the problem with Icc: the class "CommonValueExpressionDriver" is a hybrid class, with normal methods and template methods, which is something that Icc finds it too freakish to be proper code :p

From Icc's point of view, if the class is meant to have template characteristics at some point, then that same class should be a template itself. This is why OpenFOAM's code follows such a strict regiment of coding (at least most of the time): template classes start with Upper case and real classes start with lower case.

To isolate the problem, I commented out all of the code pertinent to "CommonValueExpressionDriver" in "funkyDoCalc". It then compiled without a problem with Icc.
When I uncomment the mere include of the respective header file, Icc goes bananas and starts pointing fingers in the wrong direction.

By the way, the Icc version I'm using is 12.1.0 "non-commercial" edition for Linux and Ubuntu 11.10 x86_64 with Gcc 4.6.1.


I started out in trying to provide a proper fix for this, but ended up over my head, because currently I can't invest time improving my know-how of the complex world of C++ templates :(
But fortunately, where there is a will, there's a sub-optimal way :D

Rupert, the hack I've used with success it to do first pass with Icc on swak4foam, and then do a second pass with the following commands:
Code:

( export WM_COMPILER=Gcc; cd Utilities; wclean all; wmake all )
For a direct hack, the (git) diff is this:
Code:

diff --git a/Allwmake b/Allwmake
index ab27fb2..981d931 100755
--- a/Allwmake
+++ b/Allwmake
@@ -28,7 +28,12 @@ done
 
 (cd Libraries; wmake all )
 
-(cd Utilities; wmake all )
+(
+  #revert back to the default Gcc compiler, due to some problems that Icc has
+  #with overly complex classes
+  [ "$WM_COMPILER" = "Icc" ] && export WM_COMPILER=Gcc
+  cd Utilities; wmake all
+)
 
 # (cd Examples/tests/fluIntegration/libRegistered; wmake)

Best regards,
Bruno

gschaider November 6, 2011 18:15

Quote:

Originally Posted by wyldckat (Post 330816)
Greetings to all! Bernhard and Rupert, this post is for you two:

Bernhard, I think I've found the problem with Icc: the class "CommonValueExpressionDriver" is a hybrid class, with normal methods and template methods, which is something that Icc finds it too freakish to be proper code :p

Maybe they say it in another way "The main purpose of our compiler is making our CPUs good. If a language feature is not needed for the programs in the SPEC-suite we don't necessarily have to implement it"

Quote:

Originally Posted by wyldckat (Post 330816)
From Icc's point of view, if the class is meant to have template characteristics at some point, then that same class should be a template itself. This is why OpenFOAM's code follows such a strict regiment of coding (at least most of the time): template classes start with Upper case and real classes start with lower case.

I'll have a look whether this behaviour is in any way supported by Stroustrup or whether it means that the Intel-compiler is not a C++-compiler but a compiler for a simplified C++-like language.

Quote:

Originally Posted by wyldckat (Post 330816)
To isolate the problem, I commented out all of the code pertinent to "CommonValueExpressionDriver" in "funkyDoCalc". It then compiled without a problem with Icc.
When I uncomment the mere include of the respective header file, Icc goes bananas and starts pointing fingers in the wrong direction.

And this only happens for funkySetFields? Because that header is included by a number of different C-files in the Libraries. So I don't understand why they don't fail

Quote:

Originally Posted by wyldckat (Post 330816)
By the way, the Icc version I'm using is 12.1.0 "non-commercial" edition for Linux and Ubuntu 11.10 x86_64 with Gcc 4.6.1.

Doesn't help me. Our Linux-machines (and their usage) hardly qualify as "non-commercial" and last time I looked there was no such offers for the mighty Mac (and even then I would doubt whether my MacBook qualifies as non-commercial)

Quote:

Originally Posted by wyldckat (Post 330816)
I started out in trying to provide a proper fix for this, but ended up over my head, because currently I can't invest time improving my know-how of the complex world of C++ templates :(
But fortunately, where there is a will, there's a sub-optimal way :D

Rupert, the hack I've used with success it to do first pass with Icc on swak4foam, and then do a second pass with the following commands:
Code:

( export WM_COMPILER=Gcc; cd Utilities; wclean all; wmake all )
For a direct hack, the (git) diff is this:
Code:

diff --git a/Allwmake b/Allwmake
index ab27fb2..981d931 100755
--- a/Allwmake
+++ b/Allwmake
@@ -28,7 +28,12 @@ done
 
 (cd Libraries; wmake all )
 
-(cd Utilities; wmake all )
+(
+  #revert back to the default Gcc compiler, due to some problems that Icc has
+  #with overly complex classes
+  [ "$WM_COMPILER" = "Icc" ] && export WM_COMPILER=Gcc
+  cd Utilities; wmake all
+)
 
 # (cd Examples/tests/fluIntegration/libRegistered; wmake)

Best regards,
Bruno

I'll have a look at the patch (and others you posted at http://sourceforge.net/apps/mantisbt...iew.php?id=105)

Bernhard

wyldckat November 6, 2011 19:11

Hi Bernhard,

Quote:

Originally Posted by gschaider (Post 330965)
Maybe they say it in another way "The main purpose of our compiler is making our CPUs good. If a language feature is not needed for the programs in the SPEC-suite we don't necessarily have to implement it"
[...]
I'll have a look whether this behaviour is in any way supported by Stroustrup or whether it means that the Intel-compiler is not a C++-compiler but a compiler for a simplified C++-like language.

Making a very small quote from someone on Intel's Icc team (or so I think):
Quote:

It is very hard to keep ahead or even stay even with the latest GNU versions.
Source: http://software.intel.com/en-us/foru...t.php?p=161920 - from the thread on Intel's forum: icpc 12.1.0, Ubuntu 11.10 (oneiric) and g++
By the way, Icc 12.1 is compatible with gcc 4.5.0, so that's pretty much why things seem to work if only the utilities are built with Gcc.

Quote:

Originally Posted by gschaider (Post 330965)
And this only happens for funkySetFields? Because that header is included by a number of different C-files in the Libraries. So I don't understand why they don't fail

I don't understand it very well either. But here is an example of how limited Icc is: http://www.cfd-online.com/Forums/ope...using-icc.html

As for the utilities that don't build with Icc... indeed, only the 3 "funky*" utilities that build with the vanilla version of OpenFOAM have issues with Icc; haven't tested with -Extend, but it'll probably do the same with "funkySetAreaFields".
"replayTransientBC" doesn't use that particular header, so Icc doesn't complain with it.

Quote:

Originally Posted by gschaider (Post 330965)
Doesn't help me. Our Linux-machines (and their usage) hardly qualify as "non-commercial" and last time I looked there was no such offers for the mighty Mac (and even then I would doubt whether my MacBook qualifies as non-commercial)

Mmmm... I thought the "non-commercial" policy only applied to what is done with the compiler and the build binaries... i.e., if there is any profit from it. Let's see... quoting from here:
Code:

This offering is provided to developers who are developing software on their own time without compensation.
OK, I suppose that your work developing swak4foam is treading a very fine line here between "with|without compensation".

And yes, only Linux applies for the "non-commercial" edition. But paid versions exist for: Intel® C++ Composer XE for Windows, Linux, and Mac OS* X
But since nowadays Gcc has similar or better performance than Icc, so it's not as enticing to actually buy Intel's stuff :rolleyes:

Best regards,
Bruno

orca.blu January 28, 2012 13:28

Help with installation of swak4foam on OF 2.1
 
Hi, I have problem with installation of swak4foam on OF 2.1
after Allwmake in swak4Foam/ everything seems good...

then in swak4Foam/Examples/InterFoamWithSources/interFoamWithSources/
after wmake:

interFoamWithSources.C:49:30: fatal error: expressionSource.H: No such file or directory

probably i am missing something

thank you!

gschaider January 29, 2012 18:41

Quote:

Originally Posted by orca.blu (Post 341658)
Hi, I have problem with installation of swak4foam on OF 2.1
after Allwmake in swak4Foam/ everything seems good...

then in swak4Foam/Examples/InterFoamWithSources/interFoamWithSources/
after wmake:

interFoamWithSources.C:49:30: fatal error: expressionSource.H: No such file or directory

probably i am missing something

thank you!

You didn't move the solver anywhere else, did you? It assumes that there are the sources of a correctly compiled swakExpressionFields-library at the relative path ../../../Libraries/swakSourceFields/lnInclude/ (see Make/options) check with ls in the directory interFoamWithSources whether this directory is there and whether the expressionSource.H-header is there

orca.blu January 29, 2012 20:48

Thank you for the reply and for swak4foam!

well... I have a problem: I compiled again (swak4foam/Allwmake) and i checked the log... I got many errors such as



In file included from GlobalVariablesRepository.H:45:0,
from GlobalVariablesRepository.C:34:
ExpressionResult.H:47:30: fatal error: foamVersion4swak.H: No such file or directory
compilation terminated.
make: *** [Make/linux64GccDPOpt/GlobalVariablesRepository.o] Error 1


In file included from ../swak4FoamParsers/lnInclude/PatchValueExpressionDriver.H:50:0,
from groovyTotalPressureFvPatchScalarField.H:47,
from groovyTotalPressureFvPatchScalarField.C:33:
../swak4FoamParsers/lnInclude/ExpressionResult.H:47:30: fatal error: foamVersion4swak.H: No such file or directory
compilation terminated.
make: *** [Make/linux64GccDPOpt/groovyTotalPressureFvPatchScalarField.o] Error 1

etc...

probably i did something wrong!

My steps:

- svn checkout https://openfoam-extend.svn...
in /opt/openfoam210/swak4foam

- /opt/openfoam210/swak4foam/Allwamke

i didn't move anythings

thank you!

Anyway, are there .deb for .dumb?


All times are GMT -4. The time now is 19:03.