[hjasak]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

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)?

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.

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]

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]

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]

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]

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]

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]

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 ']'