CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Installation (http://www.cfd-online.com/Forums/openfoam-installation/)
-   -   Compiling with Intel compiler icc90 (http://www.cfd-online.com/Forums/openfoam-installation/57477-compiling-intel-compiler-icc90.html)

hjasak August 24, 2005 20:31

Dear All, I have just succe
 
Dear All,

I have just successfully compiled and run FOAM-1.2 with the latest Intel compiler, version 9.0. There is a few minor porting fixes which will be provided, but if somebody wants to have a go, please let me know.

Some performance tests will follow, but I'm not too interested - this was mainly to see what the new compiler has to say about the code, including porting issues and adherance to standard. I think we pass with flying colours.

Hrv

henry August 25, 2005 03:28

The reason you did not experie
 
The reason you did not experience much difficult porting OpenCFD's latest release of OpenFOAM with the latest Intel compiler is because I had already done it. I have also run speed tests and found little benefit from using the Intel compiler, in fact for some codes and cases the gcc compiled version runs faster but the difference is not large.

hjasak August 25, 2005 06:28

Not quite - there were still s
 
Not quite - there were still some errors in template handling for fvm discretisation so the released code could not have compiled with Intel 9.0.

henry August 25, 2005 06:38

I didn't compile just before r
 
I didn't compile just before release, it was about a couple of weeks ago and I have made quite a few developments in that period. However because the Intel compiler did not show any significant advantages over gcc and has some disadvantages I didn't consider it a good use of my time on OpenFOM to ensure the release version compiles with this compiler. I will check the next release as well but that won't be for a while so you will have to make any changes you need for this compiler yourself if it is important for you.

hjasak August 25, 2005 06:47

Thanks - actually, the latest
 
Thanks - actually, the latest Intel compiler has only become available on 15/Aug.

With your permission, and in the community spirit, I would like to pass the porting changes, as well as a number of other bug fixes and extensive new developments in topological mesh handling and finite area method to OpenCFD for inclusion in the next release as we have done in the past - that way everybody can do a part of the work and we all benefit from it.

Hrv

henry August 25, 2005 06:54

We are currently not in a posi
 
We are currently not in a position to support and maintain developments of OpenFOAM made by people outside OpenCFD, except those which are part of support or consultancy contracts, due to lack of finance.

michele August 25, 2005 09:38

Trying to build OpenFOAM 1.2 w
 
Trying to build OpenFOAM 1.2 with pathscale I encountered similar compiler errors in the fvm discretisation part of the code. I would also be interested in getting these fixes.

hjasak August 25, 2005 10:07

E-mailed. The errors are to d
 
E-mailed. The errors are to do with the fact that the fvc namespace has got a static function called flux, so flux<type>::type is mis-interpreted. Doing Foam::flux to pick up the flux class from vector.H (the right one) fixes the issue.

Hrv

hjasak August 26, 2005 08:19

Hello Michelle, It looks to
 
Hello Michelle,

It looks to me the cause of the problem is the:

interpolations/surfaceInterpolation/schemes/downwind/downwind.H:99:
error: parse
error before `;' token

I have just checked my version of downwind.H and there is no semicolon on line 99. All the other problems seem to follow from this.

Would you be so kind as to E-mail me your copy of the following file:

interpolations/surfaceInterpolation/schemes/downwind/downwind.H

just to make sure it's not something obvious; otherwise, it seems to me that the parser in the compiler you are using may be broken (not sure).

Hrv

hjasak August 28, 2005 23:50

Just a short update on Intel 9
 
Just a short update on Intel 9.0. After the compiler pass (with optimization flags on), there is a second pass at link-time in which single-file and multi-file optimization is done. This is taking forever (about 2 hours to link the main FOAM library) and the compiler issues a bunch of interesting vectorisation messages.

Some vectorisation happens in the solvers as well and I am consistently getting 20-25% speedup over gcc-4.0.1. However, there seems to be an issue with the gzip library - looks like the compiler has optimized it a bit too agressively.

Overall, 25% is pretty good for speed-up but the link stage is so criminally slow that I cannot use it in everyday development. :-(

Hrv

rbw September 16, 2005 14:40

An update to Michele's post ab
 
An update to Michele's post above.
I was also getting the same compilation error, it seems that the problem is with gcc versions earlier than 4.
I had the same error with gcc-3.3.6 on gentoo linux and gcc-3.4.3 on caos linux.
If it hurts when you do something, don't do it...
So, only compile the source code with gcc >= 4. I don't know if this is explicitly said anywhere else, so I think it bears registering here.

jkr September 27, 2005 13:07

Too bad the error in downwind.
 
Too bad the error in downwind.C still appears with Etch's gcc-4.0 (Debian testing)...
$ gcc -v
gcc version 4.0.1 (Debian 4.0.1-2)

Is there a workaround, or is the error harmless (even if downwind does not build)?

jkr September 27, 2005 13:45

Ok I've been mistaken in my pr
 
Ok I've been mistaken in my previous post: manually compiling downwind.C does not lead any error now, my apologies.

I've several versions of gcc on the machine (mix stable and testing) and the compiling scripts seem to have little trouble in using gcc-4.0. I'll check the scripts for that.

jasonb December 1, 2005 10:25

Hi, I'm trying to use the p
 
Hi,

I'm trying to use the pathscale-2.3 compilers to build OpenFOAM on an Opteron platform, but am having the same problems as listed previously in this discussion some time ago, namely with downwind.H line 99 and a phantom semicolon. Was anybody ever able to figure out if this was a problem with the parser of the compiler, or something else entirely? I didn't have this trouble using gcc-4.0.1.

Thanks

Jason

hjasak December 1, 2005 10:31

I am pretty certain pathscale
 
I am pretty certain pathscale is broken. The failure is in the front end by the looks of things and it is not trivial to get it to work...

I have provided a fix for the particular problem in downwind (somewhere at the forum, it needs scoping on names) but that's not the end of the matter.

Sorry,

Hrv

michele December 1, 2005 10:50

Just for confirmation, I repor
 
Just for confirmation, I reported the bug (dtd. 31 aug 2005) to the pathscale developers. Here's their reply:

---
"Hi Michele,

Thanks for reporting the compilation issue.

This is to inform you that we could reproduce the problem in house.
A bug report (#8102) has been opened. We will notify you of any action
taken.

Note that you are correct the Pathscale compiler uses gcc 3.3 front-end
and it is on our roadmap to switch to a more recent version of gcc
(probably gcc 4).

Regards,
Didier."
---

Regards
Michele

jens_klostermann March 23, 2006 09:08

Hi Hrv, I also try to compi
 
Hi Hrv,

I also try to compile and run FOAM-1.2 with the latest Intel compiler, version 9.0. I experience the same problems as you did. However I don't know how to handle the fix you sugested on Thursday, August 25, 2005 - 08:07 am in this thread: Doing Foam::flux to pick up the flux class from vector.H (the right one) fixes the issue. Can you please illustrate that a bit more?

Thank you!

hjasak March 23, 2006 11:02

I cannot remeber exactly (it's
 
I cannot remeber exactly (it's been a while), but from the records it seems that the failure is in fvcDdt.[HC]. My fixes looked something line this - look for the Foam::flux<type>::type bit and do the same where required:


template<class>
tmp<GeometricField
<typename>::type, fvPatchField, surfaceMesh> >
ddtPhiCorr
(
const volScalarField& rA,
const volScalarField& rho,
const GeometricField<type,>& U,
const GeometricField
<
typename Foam::flux<type>::type,
fvPatchField,
surfaceMesh
>& phi
)

... blah blah

Hope this helps - if you get stuck, I can give you a copy of my development version for comparison.

Hrv

jens_klostermann March 24, 2006 02:46

Problem solved. Thank you Hrv.
 
Problem solved. Thank you Hrv.

The error was in fvcDdt.[HC]. In these files flux<type>::type has to be replaced by Foam::flux<type>::type.
Be careful it is ...Type>::type instead of ...type>::type!

nishant_hull October 27, 2007 11:35

I am also not been able to rec
 
I am also not been able to recompile the foam to run it in debug mode. I do not know what exactly is the problem. can any body tell me, is this because of gcc compiler or what?? i have two gcc compiler on my linux system. one default and one with the package. precompiled programs on my ststem is running quite ok. But so far I could not be able to run any own programm.

The error after recompiling using ./Allawake is :-

/home/343880/OpenFOAM/linux/paraview-2.4.4/include/vtkDataObject.h: In member function 'virtual void vtkDataObject::ReleaseDataFlagOn()':
/home/343880/OpenFOAM/linux/paraview-2.4.4/include/vtkDataObject.h:116: warning: use of old-style cast
/home/343880/OpenFOAM/linux/paraview-2.4.4/include/vtkDataObject.h: In member function 'virtual void vtkDataObject::ReleaseDataFlagOff()':
/home/343880/OpenFOAM/linux/paraview-2.4.4/include/vtkDataObject.h:116: warning: use of old-style cast
/home/343880/OpenFOAM/linux/paraview-2.4.4/include/vtkDataObject.h: In member function 'virtual void vtkDataObject::RequestExactExtentOn()':
/home/343880/OpenFOAM/linux/paraview-2.4.4/include/vtkDataObject.h:273: warning: use of old-style cast
/home/343880/OpenFOAM/linux/paraview-2.4.4/include/vtkDataObject.h: In member function 'virtual void vtkDataObject::RequestExactExtentOff()':
/home/343880/OpenFOAM/linux/paraview-2.4.4/include/vtkDataObject.h:273: warning: use of old-style cast
`/home/343880/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPDebug/libvtkFoam.so' is up to date.
make[3]: Leaving directory `/home/343880/OpenFOAM/OpenFOAM-1.4.1/applications/utilities/postProcessing/grap hics/PVFoamReader/vtkFoam'
+ cd PVFoamReader
+ mkdir -p Make/linuxGccDPDebug
+ cd Make/linuxGccDPDebug
+ cmake ../..
./Allwmake: line 6: cmake: command not found
+ make
make[3]: Entering directory `/home/343880/OpenFOAM/OpenFOAM-1.4.1/applications/utilities/postProcessing/grap hics/PVFoamReader/PVFoamReader/Make/linuxGccDPDebug'
make[3]: *** No targets specified and no makefile found. Stop.
make[3]: Leaving directory `/home/343880/OpenFOAM/OpenFOAM-1.4.1/applications/utilities/postProcessing/grap hics/PVFoamReader/PVFoamReader/Make/linuxGccDPDebug'
make[2]: *** [PVFoamReader] Error 2
make[2]: Leaving directory `/home/343880/OpenFOAM/OpenFOAM-1.4.1/applications/utilities/postProcessing/grap hics'
make[1]: *** [graphics] Error 2
make[1]: Leaving directory `/home/343880/OpenFOAM/OpenFOAM-1.4.1/applications/utilities/postProcessing'
make: *** [postProcessing] Error 2
+ '[' 0 = 1 -a '' = doc ']'


All times are GMT -4. The time now is 10:21.