 |
 |
 |
|
|
|
[Sponsors] | ||||
OpenFOAM on MinGW crosscompiler hosted on Linux |
 |
|
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
March 18, 2008, 18:07
|
Hi, All,
Just created a
|
#1 |
|
New Member
Allen Zhao
Join Date: Mar 2009
Location: Westmont, IL, USA
Posts: 26
Rep Power: 17  |
Hi, All,
Just created a MinGW cross-compiler which is hosted on a openSuSE 10.3 box. I am trying to compile OpenFOAM package (a linux distribution so far) with this cross-compiler, and I think the include path is used in a case insensitive manner by mingw-gcc. For example, include "scaler.H" The mingw-gcc's include search path actually find a different one "Scaler.H", and fault out. At least, that is what it looks like right now. This is my question: is there an option (either when mingw-gcc is invoked or get compiled) that disables this path issue? Obviously, on win32 platform where MinGW is hosted most of time, the path case in-sensitivity is the default behavior; but on Linux, I do think it is a plus to have path case sensitive. Can someone give me a helping hand? Best regards, Allen Zhao |
|
|
|
|
|
March 19, 2008, 11:51
|
There is a port of OpenFOAM on
|
#2 |
|
Senior Member
Dragos
Join Date: Mar 2009
Posts: 648
Rep Power: 20 |
||
|
|
|
|
|
March 19, 2008, 12:22
|
Hi, Dragos,
Cygwin port may
|
#3 |
|
New Member
Allen Zhao
Join Date: Mar 2009
Location: Westmont, IL, USA
Posts: 26
Rep Power: 17 |
Hi, Dragos,
Cygwin port may not work for us, because our main application is a C++/F90 native Win32 application, and we would like to link (statically or via dynamic loading) to OpenFOAM DLL. Can a native W32 application link with a Cygwin shared library? Cygwin seems to carry a lot of other baggages as well, and ultimately creates way too many support problem in the future. At least, this is my current understanding. Correct me if I am indeed dead wrong. Using MinGW x-compiler hosted on Linux provides a cleaner solution, it seems. But I am open to any better solutions and suggestions. |
|
|
|
|
|
|
March 20, 2008, 02:18
|
This is something I don't know
|
#4 |
|
Senior Member
Dragos
Join Date: Mar 2009
Posts: 648
Rep Power: 20 |
This is something I don't know, but I would expect the dll interface to be standard, so it shouldn't matter what compiler you've used to produce it.
Anyway if you want to use MinGW compiler instead of Cygwin, I think all you have to do is to take the windows port and change the appropriate environment variables. But this is just a guess, those who struggled with the porting know better. Dragos |
|
|
|
|
|
|
March 20, 2008, 04:27
|
Hi,
I neither have so much ex
|
#5 |
|
Super Moderator
Takuya OSHIMA
Join Date: Mar 2009
Location: Niigata City, Japan
Posts: 518
Blog Entries: 1
Rep Power: 20 |
Hi,
I neither have so much experience in MinGW. However, if the case sensitivity is your first big problem I agree with Dragos in that using the Cygwin port is a good starting point. You can try the MinGW port upon the Cygwin port as the basis, and after getting a working port and knowing how it works, you can decide if any further work on the long standing case sensitivity problem will be worthwhile. In any way I'm interested in how your attempt turns out. Takuya |
|
|
|
|
|
|
March 20, 2008, 10:44
|
Let me update the situation.
|
#6 |
|
New Member
Allen Zhao
Join Date: Mar 2009
Location: Westmont, IL, USA
Posts: 26
Rep Power: 17 |
Let me update the situation.
1) MinGW x-compiler actually honor the case sensitivity in the include path. Wew... What a relief. So, there should be no file level manipulation as described in the cygwin port. 2) The initial problem when compiling dummy/Pstream.dll is due to the lack of implementation of j0f, j1f, jnf, y0f, y1f, and ynf on the MinGW. The emitted error has both Scalar.H and scalar.H listed, and therefore causes the false alarm. The solution is to mess with floatScalar.H, doubleScalar.H, and Scalar.H to have the single precision version of above bessel function implementation. I still want to try out the MinGW port without using CygWin special package, considering that the original OpenFOAM package must be edited. Our vision is following: we would like to supply our own version of OpenFOAM DLLs to be linked with our Main F90/C++ application for both Linux and Win32. But we would like to keep the door open for user to substitute the OpenFOAM binaries with their own compilation. On the other hand, I am not sure this is feasible at all for win32 at this moment. Sign... Ok, here is another road block for creating libPstream.dll, and it looks like a linker error: + cd Pstream + ./Allwmake + wmake libso dummy Making dependency list for source file Pstream.C SOURCE=Pstream.C ; /usr/mingw/bin/i686-pc-mingw32-g++ -I/usr/mingw/i686-pc-mingw32/include -D_MINGW_PORT -Dlinux -DDP -Wall -Wno-strict-aliasing -Wextra -Wno-unused-parameter -Wold-style-cast -O3 -DNoRepository -ftemplate-depth-40 -IlnInclude -I. -I/User/allen/OpenFOAM/OpenFOAM-1.4.1/src/OpenFOAM/lnInclude -c $SOURCE -o Make/linuxGccDPOpt/Pstream.o Pstream.o:Pstream.C  .text+0xb1): undefined reference to `Foam::FatalError' Pstream.o:Pstream.C .text+0xb6): undefined reference to `Foam::error::operator()(char const*, char const*, int)' Pstream.o:Pstream.C .text+0xc6): undefined reference to `Foam::operator<<(Foam: stream&, char const*)' Pstream.o:Pstream.C .text+0xcb): undefined reference to `Foam::error::abort()' Pstream.o:Pstream.C .text+0xd6): undefined reference to `Foam::FatalError' Pstream.o:Pstream.C .text+0xdc): undefined reference to `Foam::error::abort()' Pstream.o:Pstream.C .text+0xe3): undefined reference to `Foam::FatalError' Pstream.o:Pstream.C .text+0x111): undefined reference to `Foam::FatalError' Pstream.o:Pstream.C .text+0x116): undefined reference to `Foam::error::operator()(char const*, char const*, int)' Pstream.o:Pstream.C .text+0x126): undefined reference to `Foam::operator<<(Foam:stream&, char const*)' Pstream.o:Pstream.C .text+0x136): undefined reference to `Foam::operator<<(Foam:stream&, char)' Pstream.o:Pstream.C .text+0x146): undefined reference to `Foam::operator<<(Foam:stream&, char const*)' Pstream.o:Pstream.C .text+0x14b): undefined reference to `Foam::error::exit(int)' Pstream.o:Pstream.C .text+0x156): undefined reference to `Foam::FatalError' Pstream.o:Pstream.C .text+0x15c): undefined reference to `Foam::error::exit(int)' Pstream.o:Pstream.C .text+0x16b): undefined reference to `Foam::FatalError' Pstream.o:Pstream.C .text+0x1a1): undefined reference to `Foam::FatalError' Pstream.o:Pstream.C .text+0x1a6): undefined reference to `Foam::error::operator()(char const*, char const*, int)' Pstream.o:Pstream.C .text+0x1b6): undefined reference to `Foam::operator<<(Foam:stream&, char const*)' Pstream.o:Pstream.C .text+0x1bb): undefined reference to `Foam::error::abort()' Pstream.o:Pstream.C .text+0x1c6): undefined reference to `Foam::FatalError' Pstream.o:Pstream.C .text+0x1cc): undefined reference to `Foam::error::abort()' Pstream.o:Pstream.C .text+0x1d3): undefined reference to `Foam::FatalError' IPread.o:IPread.C .text+0x91): undefined reference to `Foam::FatalError' IPread.o:IPread.C .text+0x96): undefined reference to `Foam::error::operator()(char const*, char const*, int)' IPread.o:IPread.C .text+0xa6): undefined reference to `Foam::operator<<(Foam:stream&, char const*)' IPread.o:IPread.C .text+0xab): undefined reference to `Foam::error::abort()' IPread.o:IPread.C .text+0xb6): undefined reference to `Foam::FatalError' IPread.o:IPread.C .text+0xbc): undefined reference to `Foam::error::abort()' IPread.o:IPread.C .text+0xc3): undefined reference to `Foam::FatalError' IPread.o:IPread.C .text+0x1ae): undefined reference to `vtable for Foam::IPstream' IPread.o:IPread.C .text+0x1d7): undefined reference to `Foam::FatalError' IPread.o:IPread.C .text+0x1e3): undefined reference to `Foam::error::operator()(char const*, char const*, int)' IPread.o:IPread.C .text+0x1f3): undefined reference to `Foam::operator<<(Foam:stream&, char const*)' IPread.o:IPread.C .text+0x1f8): undefined reference to `Foam::error::abort()' IPread.o:IPread.C .text+0x203): undefined reference to `Foam::FatalError' IPread.o:IPread.C .text+0x209): undefined reference to `Foam::error::abort()' IPread.o:IPread.C .text+0x210): undefined reference to `Foam::FatalError' IPread.o:IPread.C .text+0x25c): undefined reference to `vtable for Foam::IOstream' IPread.o:IPread.C .text+0x2d6): undefined reference to `vtable for Foam::IOstream' IPread.o:IPread.C .text+0x51e): undefined reference to `vtable for Foam::IPstream' IPread.o:IPread.C .text+0x547): undefined reference to `Foam::FatalError' IPread.o:IPread.C .text+0x553): undefined reference to `Foam::error::operator()(char const*, char const*, int)' IPread.o:IPread.C .text+0x563): undefined reference to `Foam::operator<<(Foam:stream&, char const*)' IPread.o:IPread.C .text+0x568): undefined reference to `Foam::error::abort()' IPread.o:IPread.C .text+0x573): undefined reference to `Foam::FatalError' IPread.o:IPread.C .text+0x579): undefined reference to `Foam::error::abort()' IPread.o:IPread.C .text+0x580): undefined reference to `Foam::FatalError' IPread.o:IPread.C .text+0x5cc): undefined reference to `vtable for Foam::IOstream' IPread.o:IPread.C .text+0x646): undefined reference to `vtable for Foam::IOstream' IPread.o:IPread.C .text$_ZNK4Foam8IOstream4nameEv[Foam::IOstream::name() const]+0x2): undefined reference to `Foam::IOstream::name_' IPread.o:IPread.C .text$_ZN4Foam8IOstream4nameEv[Foam::IOstream::name()]+0x2): undefined reference to `Foam::IOstream::name_' IPread.o:IPread.C .text$_ZN4Foam4ListIcE7setSizeEi[Foam::List<char>::setSize(int)]+0xd1): undefined reference to `Foam::FatalError' IPread.o:IPread.C .text$_ZN4Foam4ListIcE7setSizeEi[Foam::List<char>::setSize(int)]+0xd6): undefined reference to `Foam::error::operator()(char const*, char const*, int)' IPread.o:IPread.C .text$_ZN4Foam4ListIcE7setSizeEi[Foam::List<char>::setSize(int)]+0xe6): undefined reference to `Foam::operator<<(Foam:stream&, char const*)' IPread.o:IPread.C .text$_ZN4Foam4ListIcE7setSizeEi[Foam::List<char>::setSize(int)]+0xf2): undefined reference to `Foam::operator<<(Foam:stream&, int)' IPread.o:IPread.C .text$_ZN4Foam4ListIcE7setSizeEi[Foam::List<char>::setSize(int)]+0xf7): undefined reference to `Foam::error::abort()' IPread.o:IPread.C .text$_ZN4Foam4ListIcE7setSizeEi[Foam::List<char>::setSize(int)]+0x102): undefined reference to `Foam::FatalError' IPread.o:IPread.C .text$_ZN4Foam4ListIcE7setSizeEi[Foam::List<char>::setSize(int)]+0x108): undefined reference to `Foam::error::abort()' IPread.o:IPread.C .text$_ZN4Foam4ListIcE7setSizeEi[Foam::List<char>::setSize(int)]+0x10f): undefined reference to `Foam::FatalError' IPread.o:IPread.C .text$_ZN4Foam7IstreamD1Ev[Foam::Istream::~Istream()]+0x62): undefined reference to `vtable for Foam::IOstream' IPread.o:IPread.C .text$_ZN4Foam7IstreamD1Ev[Foam::Istream::~Istream()]+0x1af): undefined reference to `vtable for Foam::IOstream' IPread.o:IPread.C .text$_ZN4Foam7IstreamD0Ev[Foam::Istream::~Istream()]+0x63): undefined reference to `vtable for Foam::IOstream' IPread.o:IPread.C .text$_ZN4Foam7IstreamD0Ev[Foam::Istream::~Istream()]+0x1bf): undefined reference to `vtable for Foam::IOstream' IPread.o:IPread.C .rdata$_ZTVN4Foam7IstreamE[vtable for Foam::Istream]+0x18): undefined reference to `Foam::IOstream::check(char const*) const' IPread.o:IPread.C .rdata$_ZTVN4Foam7IstreamE[vtable for Foam::Istream]+0x24): undefined reference to `Foam::IOstream::print(Foam:stream&) const' OPwrite.o Pwrite.C.text+0x91): undefined reference to `Foam::FatalError' OPwrite.o Pwrite.C.text+0x96): undefined reference to `Foam::error::operator()(char const*, char const*, int)' OPwrite.o Pwrite.C.text+0xa6): undefined reference to `Foam::operator<<(Foam:stream&, char const*)' OPwrite.o Pwrite.C.text+0xab): undefined reference to `Foam::error::abort()' OPwrite.o Pwrite.C.text+0xb6): undefined reference to `Foam::FatalError' OPwrite.o Pwrite.C.text+0xbc): undefined reference to `Foam::error::abort()' OPwrite.o Pwrite.C.text+0xc3): undefined reference to `Foam::FatalError' OPwrite.o Pwrite.C.text+0x12c): undefined reference to `Foam::FatalError' OPwrite.o Pwrite.C.text+0x138): undefined reference to `Foam::error::operator()(char const*, char const*, int)' OPwrite.o Pwrite.C.text+0x148): undefined reference to `Foam::operator<<(Foam:stream&, char const*)' OPwrite.o Pwrite.C.text+0x14d): undefined reference to `Foam::error::abort()' OPwrite.o Pwrite.C.text+0x158): undefined reference to `Foam::FatalError' OPwrite.o Pwrite.C.text+0x15e): undefined reference to `Foam::error::abort()' OPwrite.o Pwrite.C.text+0x165): undefined reference to `Foam::FatalError' OPwrite.o Pwrite.C.text+0x17d): undefined reference to `vtable for Foam::IOstream' OPwrite.o Pwrite.C.text+0x1bd): undefined reference to `vtable for Foam::IOstream' OPwrite.o Pwrite.C.text+0x246): undefined reference to `Foam::FatalError' OPwrite.o Pwrite.C.text+0x252): undefined reference to `Foam::error::operator()(char const*, char const*, int)' OPwrite.o Pwrite.C.text+0x262): undefined reference to `Foam::operator<<(Foam:stream&, char const*)' OPwrite.o Pwrite.C.text+0x267): undefined reference to `Foam::error::abort()' OPwrite.o Pwrite.C.text+0x272): undefined reference to `Foam::FatalError' OPwrite.o Pwrite.C.text+0x278): undefined reference to `Foam::error::abort()' OPwrite.o Pwrite.C.text+0x27f): undefined reference to `Foam::FatalError' OPwrite.o Pwrite.C.text+0x297): undefined reference to `vtable for Foam::IOstream' OPwrite.o Pwrite.C.text+0x2e5): undefined reference to `vtable for Foam::IOstream' OPwrite.o Pwrite.C.text+0x36c): undefined reference to `Foam::FatalError' OPwrite.o Pwrite.C.text+0x378): undefined reference to `Foam::error::operator()(char const*, char const*, int)' OPwrite.o Pwrite.C.text+0x388): undefined reference to `Foam::operator<<(Foam:stream&, char const*)' OPwrite.o Pwrite.C.text+0x38d): undefined reference to `Foam::error::abort()' OPwrite.o Pwrite.C.text+0x398): undefined reference to `Foam::FatalError' OPwrite.o Pwrite.C.text+0x39e): undefined reference to `Foam::error::abort()' OPwrite.o Pwrite.C.text+0x3a5): undefined reference to `Foam::FatalError' OPwrite.o Pwrite.C.text+0x3bd): undefined reference to `vtable for Foam::IOstream' OPwrite.o Pwrite.C.text+0x405): undefined reference to `vtable for Foam::IOstream' OPwrite.o Pwrite.C.text$_ZN4Foam7OstreamD0Ev[Foam:stream::~Ostream()]+0x8): undefined reference to `vtable for Foam::IOstream' OPwrite.o Pwrite.C.text$_ZN4Foam7OstreamD1Ev[Foam:stream::~Ostream()]+0x8): undefined reference to `vtable for Foam::IOstream' OPwrite.o Pwrite.C.rdata$_ZTVN4Foam8OPstreamE[vtable for Foam:Pstream]+0x18): undefined reference to `Foam::IOstream::check(char const*) const' OPwrite.o Pwrite.C.rdata$_ZTVN4Foam8OPstreamE[vtable for Foam:Pstream]+0x24): undefined reference to `Foam:Pstream::print(Foam:stream&) const' OPwrite.o Pwrite.C.rdata$_ZTVN4Foam8OPstreamE[vtable for Foam:Pstream]+0x28): undefined reference to `Foam:Pstream::write(Foam::token const&)' OPwrite.o Pwrite.C.rdata$_ZTVN4Foam8OPstreamE[vtable for Foam:Pstream]+0x2c): undefined reference to `Foam:Pstream::write(char)' OPwrite.o Pwrite.C.rdata$_ZTVN4Foam8OPstreamE[vtable for Foam:Pstream]+0x30): undefined reference to `Foam:Pstream::write(char const*)' OPwrite.o Pwrite.C.rdata$_ZTVN4Foam8OPstreamE[vtable for Foam:Pstream]+0x34): undefined reference to `Foam:Pstream::write(Foam::word const&)' OPwrite.o Pwrite.C.rdata$_ZTVN4Foam8OPstreamE[vtable for Foam:Pstream]+0x38): undefined reference to `Foam:Pstream::write(Foam::string const&)' OPwrite.o Pwrite.C.rdata$_ZTVN4Foam8OPstreamE[vtable for Foam:Pstream]+0x3c): undefined reference to `Foam:Pstream::write(int)' OPwrite.o Pwrite.C.rdata$_ZTVN4Foam8OPstreamE[vtable for Foam:Pstream]+0x40): undefined reference to `Foam:Pstream::write(float)' OPwrite.o Pwrite.C.rdata$_ZTVN4Foam8OPstreamE[vtable for Foam:Pstream]+0x44): undefined reference to `Foam:Pstream::write(double)' OPwrite.o Pwrite.C.rdata$_ZTVN4Foam8OPstreamE[vtable for Foam:Pstream]+0x48): undefined reference to `Foam:Pstream::write(char const*, int)' OPwrite.o Pwrite.C.rdata$_ZTVN4Foam7OstreamE[vtable for Foam:stream]+0x18): undefined reference to `Foam::IOstream::check(char const*) const' OPwrite.o Pwrite.C.rdata$_ZTVN4Foam7OstreamE[vtable for Foam:stream]+0x24): undefined reference to `Foam::IOstream::print(Foam:stream&) const' collect2: ld returned 1 exit status make: *** [/User/allen/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/dummy/libPstream.dll] Error 1 ------------------------------------------- These functions are defined in error.H eventhough error.C is not part of the libPstream.dll compilation, but why I got all these crazy errors? Does libPstream.dll depends on another library for these symbol resolution? Any clue and suggestion? |
|
|
|
|
|
|
March 20, 2008, 19:56
|
Hi Allen,
The error is anothe
|
#7 |
|
Super Moderator
Takuya OSHIMA
Join Date: Mar 2009
Location: Niigata City, Japan
Posts: 518
Blog Entries: 1
Rep Power: 20 |
Hi Allen,
The error is another very reason you should refer to the Cygwin port. Since on Windows all symbols must be pre-bound, you have to do a bit of trick to get rid of this dependency loop. You'll see step-by-step porting patches and good explanations at Brook's site [1]. They are a bit oldish since they are for version 1.3 but you still can see the ideas how they resolved the issue (OpenFOAM-1.3.cygwin-src-0.3.diff) and a good estimate of the amount of work waiting ahead (OpenFOAM-1.3.cygwin-src-0.5.diff). [1] http://dpdx.net/openfoam-cygwin/ Takuya |
|
|
|
|
|
|
March 21, 2008, 16:45
|
Hi Allen,
I've just complet
|
#8 |
|
Senior Member
Richard Smith
Join Date: Mar 2009
Location: Enfield, NH, USA
Posts: 138
Blog Entries: 4
Rep Power: 17 |
Hi Allen,
I've just completed a patch for OpenFOAM 1.4.1 to run as a native Windows applications using a MinGW cross compiler. You can find details and the patch at: http://www.symscape.com/openfoam-on-windows Rich
__________________
Symscape, Computational Fluid Dynamics for all |
|
|
|
|
|
|
March 25, 2008, 14:29
|
Hi Rich!
I'm just trying to
|
#9 |
|
Assistant Moderator
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51 |
Hi Rich!
I'm just trying to apply your patch. For reasons that are not directly related to your patch (precompiled mingw-gcc that uses includes in the 'wrong' order) it currently doesn't compile. I just wanted to check which versions of mingw-gcc are you using? Bernhard BTW: In the patch there are some references to changed svn-properties that patch can not interpret
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request |
|
|
|
|
|
|
March 25, 2008, 15:05
|
Hi Bernhard,
I've just repl
|
#10 |
|
Senior Member
Richard Smith
Join Date: Mar 2009
Location: Enfield, NH, USA
Posts: 138
Blog Entries: 4
Rep Power: 17 |
Hi Bernhard,
I've just replaced the patch file without the svn-properties. I build my cross compiler using vanilla gcc, not MinGW modified. GCC Versions: gcc-core-4.2.3 gcc-g++-4.2.3 Win Versions: binutils-2.18.50-20080109 mingw-runtime-3.14 w32api-3.11 Hope this helps. Rich
__________________
Symscape, Computational Fluid Dynamics for all |
|
|
|
|
|
|
March 26, 2008, 07:50
|
Hi Rich!
OK. Got it to work
|
#11 |
|
Assistant Moderator
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51 |
Hi Rich!
OK. Got it to work (using the prebuilt cross-compiler from http://sourceforge.net/projects/mingw-cross/). Works nice. How do you do postprocessing? I guess you havn't got paraFoam to run yet? (or was it so trivial that you didn't mention it on the page) I tried foamToVTK, but it produces files that paraview can't read. After treating them with dos2unix they can be read. Bernhard BTW: I think the tip with the float.h should be moved up to the "Build process". This seems to be a problem with all mingw-crosscompilers (not just yours, I guess that is why you included it "only" as a tip)
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request |
|
|
|
|
|
|
March 26, 2008, 08:22
|
Hi Richard,
And how does it p
|
#12 |
|
Super Moderator
Takuya OSHIMA
Join Date: Mar 2009
Location: Niigata City, Japan
Posts: 518
Blog Entries: 1
Rep Power: 20 |
Hi Richard,
And how does it perform against the Cygwin port or Linux native? I'm expecting the MinGW port to outperform the Cygwin port at least in I/O. Takuya |
|
|
|
|
|
|
March 26, 2008, 11:42
|
Hi Bernhard,
Great that it
|
#13 |
|
Senior Member
Richard Smith
Join Date: Mar 2009
Location: Enfield, NH, USA
Posts: 138
Blog Entries: 4
Rep Power: 17 |
Hi Bernhard,
Great that it works for you too. As you suggested I moved the float.h modification description into the build process. I haven't tried post-processing, you are way ahead of me. If there's one thing I've learned about porting it's: nothing is trivial... Rich
__________________
Symscape, Computational Fluid Dynamics for all |
|
|
|
|
|
|
March 26, 2008, 11:53
|
Hi Takuya,
I've performed a
|
#14 |
|
Senior Member
Richard Smith
Join Date: Mar 2009
Location: Enfield, NH, USA
Posts: 138
Blog Entries: 4
Rep Power: 17 |
Hi Takuya,
I've performed a timing comparison between Windows and Linux on the same, dual-boot, machine for the icoDyMFoam movingCone tutorial. The MinGW (native) Windows version took 129% of the native Linux version. For more details visit: http://www.symscape.com/openfoam-on-windows#comment-129 I don't have OpenFOAM on Cygwin to compare with - maybe someone else could try it. Rich
__________________
Symscape, Computational Fluid Dynamics for all |
|
|
|
|
|
|
March 26, 2008, 20:04
|
Hi Richard,
Thanks a lot for
|
#15 |
|
Super Moderator
Takuya OSHIMA
Join Date: Mar 2009
Location: Niigata City, Japan
Posts: 518
Blog Entries: 1
Rep Power: 20 |
Hi Richard,
Thanks a lot for the performance numbers. Only around 30% performance penalty against the linux build means the port is faster than the Cygwin port anyway. I'll definitely give it a shot when I have time. For postprocessing, you can try a native reader for ParaView [1] and a precompiled ParaView 3.2.1 Windows binary with the reader included[2]. [1] http://www.cfd-online.com/cgi-bin/Op...1231#POST21231 [2] http://oshima.eng.niigata-u.ac.jp/Op...iew/index.html Takuya |
|
|
|
|
|
|
March 27, 2008, 16:59
|
Hi Takuya,
Thanks for the i
|
#16 |
|
Senior Member
Richard Smith
Join Date: Mar 2009
Location: Enfield, NH, USA
Posts: 138
Blog Entries: 4
Rep Power: 17 |
Hi Takuya,
Thanks for the info on post-processing. I just performed another timing comparison for a bigger case (suggested by Henry Weller) - Xoodles pitzDaily3D. The MinGW (native) Windows version was 41% slower than the native Linux version. Wine (a windows emulator running under Linux) was only 34% slower than Linux. For more details (logs etc) visit: http://www.symscape.com/openfoam-on-windows#comment-131 In making this case work I came across a runtime lower/uppercase clash, so I've incorporated a fix in the latest patch on my website.
__________________
Symscape, Computational Fluid Dynamics for all |
|
|
|
|
|
|
March 27, 2008, 17:18
|
Hi Rich!
Some remarks about
|
#17 |
|
Assistant Moderator
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51 |
Hi Rich!
Some remarks about your port (I know: it sounds like I'm only complaining): - to completely compile OF I had to copy a foamFlex++ binary from the Linux installation to the applications/bin/linuxmingw32-directory (obviously the foamFlex++.exe that is produced during compilation isn't used) - when compiling on a 64-machine the WM_64 environment variable has to be cleared. Otherwise it will try to write all the objects etc to linux64mingw32-directories (A 'export WM_64=' in the bashrc should do the trick) - A regular and a mingw installation don't live happily in the same installation because they conflict with the links in OpenFOAM/lnInclude that got to OpenFOAM/OSspecific/<unix/mswindows>. If the links are set to MSWindows the Linuxs stuff won't compile (propably the other way around wouldn't work also). My proposed solution would be to generate two directories 1. OpenFOAM/lnInclude - with links to OSSpecific/Unix 2. OpenFOAM/msLnInclude - with links to OSSpecific/MSWindows (plus all the other stuff) and in wmake/rules/linuxmingw32/general add a line PROJECT_INC=-I$(LIB_SRC)/$(WM_PROJECT)/msLnInclude to select the "other" lnInclude. Using that "workaround" I was able to compile applications for Linux and Windows from the same OF-Installation The changes I did to wmakeLnInclude (I only included the part that is changed and it contains a lot of code dublication and only works if called by hand) are # Exclude opposite OSspecfic otherwise we try # linking to both EXCLUDE_OS_DIR="MSwindows" echo $0: linking include files to $INCDIR echo cd $INCDIR find .. -name "*nInclude" -prune -o -name '.svn' -prune -o -name $EXCLUDE_OS_DIR -prune -o -name Make -prune -o \( -name '*.[hcHCx]*' -o -name '*.type' \) -exec ln $LNOPTION {} . \; if [ "$BASEDIR" = "OpenFOAM" ]; then cd ../.. if [ "mingw32" = "$WM_COMPILER" ]; then INCDIR=$BASEDIR/msLnInclude if [ -d $INCDIR ] then #echo $0: include directory $INCDIR already exists, exiting. exit 0 fi mkdir $INCDIR if [ ! -d $INCDIR ] then echo $0: failed to create include directory $INCDIR exit 0 fi EXCLUDE_OS_DIR="Unix" cd $INCDIR find .. -name "*nInclude" -prune -o -name '.svn' -prune -o -name $EXCLUDE_OS_DIR -prune -o -name Make -prune -o \( -name '*.[hcHCx]*' -o -name '*.type' \) -exec ln $LNOPTION {} . \; fi fi
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request |
|
|
|
|
|
|
March 28, 2008, 15:44
|
Hi Bernhard,
Thanks for hel
|
#18 |
|
Senior Member
Richard Smith
Join Date: Mar 2009
Location: Enfield, NH, USA
Posts: 138
Blog Entries: 4
Rep Power: 17 |
Hi Bernhard,
Thanks for helping 'debug' this patch. I appreciate the time you've spent working on this. Henry Weller suggested moving the contents of the src/OpenFOAM/OSspecific directory to src/OSspecific and moving the OSspecific.H file into src/OpenFOAM/OSspecific which avoids the dependency/linking problems and it works well in practice. As with your suggestion, it's now possible to build 2 or more platforms without starting from scratch each time. I also incorporated your 64 bit environment variable fix. I've issued a new patch (v3) and updated the tips sections after your findings with foamFlex++ For details visit: http://www.symscape.com/openfoam-on-windows#comment-132 Thanks again, Rich
__________________
Symscape, Computational Fluid Dynamics for all |
|
|
|
|
|
|
March 29, 2008, 02:23
|
Hi Richard,
OK it now works.
|
#19 |
|
Super Moderator
Takuya OSHIMA
Join Date: Mar 2009
Location: Niigata City, Japan
Posts: 518
Blog Entries: 1
Rep Power: 20 |
Hi Richard,
OK it now works. The port (v3-patch) just compiled flawlessly with the cross compiler binaries Bernhard suggested. I did a quick benchmarking under the same case you've done (first 20 steps of Xoodles/pitsDaily3D). The MinGW and Cygwin ports are different in OF versions but I had confirmed they perform roughly identically under Linux (240s vs. 237s for OF1.4.1 vs. OF1.4 on an Opteron 2.4GHz box). Processor: Core 2 Duo 3GHz, 4GB RAM OS: Windows Vista SP1 32bit Job priority: Normal (The numbers are all in wall clock time) OF 1.4.1 MinGW port blockMesh 21s, Xoodles 294s OF 1.4 Cygwin port blockMesh 50s, Xoodles 321s OF 1.4.1 under Ubuntu 7.10 on VMware blockMesh 20s, Xoodles 324s The Cygwin port is not so bad for calculation itself, but its pre/postprocessing performance is somehow simply terrible. I also have several (not so important) remarks so I think I'll be back here with a patch or something later. Takuya |
|
|
|
|
|
|
March 29, 2008, 13:48
|
Hi Tayuya,
Great to see tim
|
#20 |
|
Senior Member
Richard Smith
Join Date: Mar 2009
Location: Enfield, NH, USA
Posts: 138
Blog Entries: 4
Rep Power: 17 |
Hi Tayuya,
Great to see timings compared to Cygwin and VMware. Also your test machine rocks - over twice as fast as my test machine. I've just updated the patch to v4, which now builds the OSspecific library as an object collection rather than directly compiling it within the OpenFOAM shared library, again suggested by Henry Weller. For details and the patch visit: http://www.symscape.com/openfoam-on-windows#comment-133 Rich
__________________
Symscape, Computational Fluid Dynamics for all |
|
|
|
|
|
|
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| OpenFOAM 15x MinGW Windows Port | gocarts | OpenFOAM Installation | 1 | April 17, 2009 11:41 |
| divide by zero FPE issue in OpenFOAM 141 MingW port | allenzhao | OpenFOAM Installation | 9 | September 22, 2008 18:13 |
| OpenFOAM on SuSE Linux 100 | musahossein | OpenFOAM Installation | 4 | June 20, 2008 17:47 |
| OpenFoam and Linux | Tomislav Maric | Main CFD Forum | 13 | October 25, 2007 05:45 |
| OpenFOAM and linux distros | billy | OpenFOAM | 8 | September 8, 2005 02:43 |
Linear Mode
