[wyldckat]

Greetings to all,

I completely forgot to create a thread back in November, dedicated to answering problems people with using the then announced wiki page at openfoamwiki.net. The announcement thread is this one.

So, for all the foamers out there having problems with the wiki page "Cross-compiling OpenFOAM 1.6 on Linux for Windows 32 and 64bits with Mingw-w64", feel free to ask, report and answer about it on this thread!

And with this, any major updates made to that particular wiki page will also be reported on this thread too!

Best regards,
Bruno Santos

[philippose]

Hello and a Good Evening (hot though!!),

I cross-compiled OpenFOAM-1.6 on my Fedora 10 system today using the mingw-w32 compiler installation available from the Fedora repositories, and everything worked out quite well.

However, while running a simulation in Windows using this cross-compiled version, I keep getting a warning that the folder "uniform" could not be removed, and subsequently another warning that the corresponding time folder could not be removed.

Due to this, even though I have specified a "purgeWrite" option in controlDict, OpenFOAM deletes the contents of the "uniform" subfolder, and the files present in the time folder, but does not remove the folder because it cannot remove "uniform" for some reason (though the folder is empty).

I had a quick look at the code (in MSWindows.C) but could not find anything directly wrong (unless I missed something).

Any idea what the issue could be?

I wish you a lovely evening ahead!

Philippose

[wyldckat]

Hi Philippose,

Wow, I'm glad to finally read feedback on this thread

OK, do you know of a tutorial case where the very same issue occurs? Or can you post a case that has the same issue? Without a test case for reproducing that issue, I have no idea where to start looking!

Best regards and a lovely evening to you too
Bruno

[philippose]

Hello again :-)!

Wow.... I am happy to get a reply from you so quickly :-)!

I must say..... thats a lot of work you people have put in to enable OpenFOAM to be cross-compiled :-)! I would like to extend my appreciation for not just the work put into creating the patches and the build system, but more over.... for the effort you have put in to documenting the process in such a precise yet detailed manner :-)! Thanks a lot for the effort!!

So.... to make this reply a little more structured...:

1. I have been using OpenFOAM on Linux for over 3 years now (and to be honest, I prefer to use it on Linux)..... however, I need not explain how difficult it is to get conservative engineering companies and engineers to start using Linux.... All I need to say is "Li...." and their eyes start growing large.... their mouths start opening in protest, and by the time I reach the "....nux" bit, they are up in arms :-)!

Hence, I have been continuously looking at "scalable" and "maintainable" options for getting OpenFOAM working on Windows.... I have seen your instructions for a while now, and have always wondered whether I should give it a try, but somehow kept putting it off..... but finally yesterday I went the whole nine yards :-)!


2. I cross-compiled OpenFOAM-1.6 on a Fedora 10 (64-bit) Quad Core system with a 32-bit Windows system as the target. The good thing with Fedora is, that they have the entire "mingw-w32" build environment available through their standard "yum" RPM repositories, so I did not have to do any special building, or setup.... the cross-compile environment works basically out of the box.


3. I used the patches you have made available on the OpenFOAM Wiki, and followed your instructions wherever relevant, and as I mentioned earlier, the entire process went through very smoothly :-)! Thanks for that!


4. Now for the actual problem / issue I am facing...... as an example, you could take the "pitzDaily" tutorial case for the simpleFoam solver.

Here are the steps you need to follow to reproduce the problem:

a) Change the "purgeWrite" option in controlDict from "0" to say... "2"
b) Change the "writeInterval" option from "50" to say... "10"
c) Run the simulation

:-)! Yes... it is as simple as that....

The simulation starts, and once iteration 30 is written to disk, OpenFOAM should delete iteration 10.... At this point you get the following two warnings one after the other:

--> FOAM Warning : 
    From function rmdir(const fileName&)
    in file MSwindows.C at line 967
    failed to remove directory "H:/OpenFOAM_Win/ofuser-1.6/run/pitzDaily/10/uniform"
--> FOAM Warning : 
    From function rmdir(const fileName&)
    in file MSwindows.C at line 940
    failed to remove directory "uniform" while removing directory "H:/OpenFOAM_Win/ofuser-1.6/run/pitzDaily/10"

The simulation continues to run, and all the files within the folder for iteration "10" are deleted, and all the files within the subfolder "10\uniform" are deleted, but the subfolder "uniform" itself remains, and so does the folder "10".

This happens for every 10 iterations thereafter, and OpenFOAM leaves behind a trail of empty iteration folders in its wake :-)!

I have attached some screenshots to show this.....



5. To try and solve the issue, I looked at the "MSWindows.C" file... specifically, the "rmDir" function..... but it looks ok to me (unless I am missing something that is staring at me!!)


I wonder if any one else has faced this issue..... and if anyone has a solution to the issue...... I was able to reproduce this on the Windows XP (32-bit) system at work, and here at home (I use SP3, and all the latest Windows updates are installed).


Have a nice evening ahead :-)!

Philippose

[wyldckat]

Hi Philippose,

Thank you very much for the detailed bug report And we are glad to contribute back to the community, since it has already given us so much!

OK, I haven't tested this yet, but I think I know what's the problem with the code: the Windows function "::RemoveDirectory" is alergic to Un*x paths, just like with case sensitive paths :P
Windows already has a lot of code that works with both path slashes and letter case sensitivity, but it's still very incomplete. And "RemoveDirectory" is still one of those that need updating (if it ever will be updated).
I've browsed Qt's code to figure out how they solve the issue, and at its core, they resort to the Windows C function "GetFullPathName" for getting a valid path for "RemoveDirectory". But like I said, i haven't tested this yet.

We at blueCAPE will be dedicating some time to finish fixing the patches for OpenFOAM 1.6 and will update them for 1.7, but only in about two or three weeks will we have everything wrapped up... unless a client demands it sooner And hopefully this is one of the bugs that will get fixed, because this same issue also happens with foamToVTK!

Anyway, the quick fix for now will be to replace the occurrences of '/' for '\\' (which will mean a single '\' after compiling) in the folder paths to be removed!
I'm not going to post any code here, because I can't test it right now. But Philippose, if you manage to code the fix for it, feel free to post the code here too

Best regards and a very good day to you and all
Bruno

[gocarts]

Originally Posted by wyldckat

the Windows function "::RemoveDirectory" is alergic to Un*x paths

This is incorrect, ::RemoveDirectory works fine with the *nix path separator.

I fixed a similar file removal (maybe the same) problem with my latest Windows patch (v10 released March 5, 2010) over at:
http://www.symscape.com/openfoam-1-6-x-on-windows

I tested the case you tried and it works fine with this latest patch.

The problem relates to holding on to a directory iterator while removing files in the directory. It only showed up on Windows XP.

Hope this helps.

[philippose]

Hello Bruno and Richard,

A Good Evening to you :-)! Its blistering hot here.... any better whereever you both are :-) !?

Thank you very much for the suggestions.... I was going to reply today, because I have done more digging into this issue.

As Richard has already mentioned, the problem does not arise due to any of the following usual causes:

1. Forward slash / backslash in the path (RemoveDirectory works with both)
2. Upper / lower case in the path (again, RemoveDirectory works with both)
3. Full Pathname issues (I tried with "GetFullPathName" also)


As the next step, I called the "GetLastError()" function immediately after the RemoveDirectory function call, and I got error number 32. This error translates to "ERROR_SHARING_VIOLATION" (Windows Error Codes)

This led me also to the same conclusion, that the problem should lie in the fact that the DirectoryIterator opens a Handle to the directory, but does not release it after generating the file list.


I shall look into the Patch that was mentioned in the last post, and post feedback as soon as I test it.

Once again, thank you very much for all the support :-)!

Have a great evening ahead!

Philippose

[wyldckat]

Greetings Richard and Philippose,

Originally Posted by gocarts

This is incorrect, ::RemoveDirectory works fine with the *nix path separator.

Well, I did say in the first phrase that I didn't test it yet

Richard, many thanks for the heads up on this! It will save me from some hair pulling when I would reach that bug issue


Philippose, it's very hot around here in Portugal too! And many thanks for the additional report on your attempts to fix the bug.

I've looked at Richard's patches and the fix is quite simple: putting rmDir's search block inside a bracket block, including the Iterator! This way the iterator is terminated before RemoveDirectory is called!

Best regards and many thanks!
Bruno

[philippose]

Perfect :-)!

I could'nt wait till later, so I quickly sneaked into Linux, and made the change suggested by Richard, and voila.... it worked like a charm :-)!

I must say.... that is a very elegant and simple fix to the issue :-)!

Thank you very much Richard :-)!

I did not check to see if there were any other large changes in v10 of the patch.... were there any significant ones?

And is there anything in the direction of getting the Windows version of OpenFOAM running in parallel with OpenMPI instead of MPICH2? (OpenMPI does work in Windows.... since version 1.3.3 I think. The current version is 1.4.2)

Have a great weekend!

Philippose

[wyldckat]

Hi Philippose,

Originally Posted by philippose

And is there anything in the direction of getting the Windows version of OpenFOAM running in parallel with OpenMPI instead of MPICH2? (OpenMPI does work in Windows.... since version 1.3.3 I think. The current version is 1.4.2)

AFAIK OpenMPI can be built using M$ Visual Studio C++ Express... which is "free". But according to my searches, OpenMPI isn't build-able with MinGW yet... but I haven't tested this yet myself. I've been using MPICH2 for a while now, since they also have implementations for Linux.
Additionally, I don't know what is the performance hit when comparing OpenMPI vs MPICH2 under Windows So that's another reason (for now) to keep resorting to MPICH2. Additionally, MPICH2 comes already built and properly optimized, which doesn't always happen when I build things myself

Best regards and a great weekend to you and all
Bruno

[gocarts]

Originally Posted by philippose

I did not check to see if there were any other large changes in v10 of the patch.... were there any significant ones?

And is there anything in the direction of getting the Windows version of OpenFOAM running in parallel with OpenMPI instead of MPICH2? (OpenMPI does work in Windows.... since version 1.3.3 I think. The current version is 1.4.2)

I'm not sure that v10 has anything other than a few mods for Mac compilation. In fact I think the 'directory delete fix' was likely in an earlier version.

You might be interested in my latest 1.6.x patch release which is due out any moment. It supports 64-bit and can use Microsoft's HPC 2008 SDK (msmpi.dll) native version of MPICH2 - which means it can run in parallel on a multi-processor/core Windows machine or Microsoft HPC Server 2008 (cluster).

Weather here in New Hampshire = glorious: 75F (24C) and sunny

[billybore]

For Wyldckat:

I follow correctly the windows compilation wiki for OF 1.7, but during the compilation of scotch (bashrc-minwg-w64; compilation of mingw44 done correctly) it appears an error:
.../OpenFOAM/ThirdParty-1.7.0/platforms/linuxmingw-w64/mingw/lib/gcc/x86_64-w64-mingw32/4.4.4/../../../../x86_64-w64-mingw32/bin/ld: cannot find -lscotcherr
collect2: ld returned 1 exit status
make[2]: *** [libscotch.dll] Error 1
make[2]: Leaving directory `.../OpenFOAM/ThirdParty-1.7.0/scotch_5.1/src/libscotch'
make[1]: *** [scotch] Error 2
make[1]: Leaving directory `.../OpenFOAM/ThirdParty-1.7.0/scotch_5.1/src/libscotch'
make: *** [scotch] Error 2
This affect the global compilation of OF?
How can be solved?

[wyldckat]

Greetings billybore and welcome to the forum!

I've just downloaded the patches from the wiki and tested in OpenSUSE 11.1 x64 for the same options as you did and I didn't get that problem you have.

So, lets try and solve this:

• What Linux version and architecture are you using?
• Did the patches work properly? To verify if they did, run:

  find $WM_PROJECT_DIR/ -name "*.rej"
  find $WM_THIRD_PARTY_DIR/ -name "*.rej"

  If any files show up, then there something went wrong when applying the patches
• As for Scotch, please run this:

  cd $WM_THIRD_PARTY_DIR
  ./AllwmakeMinGWScotch > scotchBuild.log 2>&1
  tar -czf scotchBuild.tar.gz scotchBuild.log

  And then post the scotchBuild.tar.gz file here in the thread. This way I should be able to figure out what went wrong.

If the error was only with Scotch, the rest should build and work without any problems... except for the missing Scotch library, which some executables might require.


Edit: the patches have been updated, but this reported issue was not handled due to lack of information on how it occurs

Best regards,
Bruno

[billybore]

I've cross-compiled OF successfully at 32bit SP and DP and 64bit SP and DP, without any error message (libscoth issues solved).
When I launch it on windows machine most of the utilities seems to work, but I cannot launch the solver for some tutorial cases.
For example for the cavity icoFoam tutorial I can launch blockMesh.exe without any error but in all the 4 compilation (32SP,32DP,64SP,64DP) when I launch the icoFoam.exe solver I have this error message:

--> FOAM FATAL ERROR:
Cannot find file "points" in directory "polyMesh" in times 0 down to constant

But is present the points file.

If there are any thoughts about this problem I'll be gracefull.

Thanks

[wyldckat]

Greetings billybore,

Wow, that's a lot of builds Personally I've never built 64bit SP, because it feels redundant... but never benchmarked them to be sure if it was worth the effort or not.

OK, as for the problem you are having, without knowing:

• some more information about the Linux/Cygwin platform you used to cross-compile OpenFOAM;
• and what method of running the applications in Windows (MSys or Windows Command Line);

Without these, I can't try and replicate the issues that you are having. Therefore, I can only think that:

• it could be a problem with file permissions of some sort.
• Or that there could be some damages to the file system.
• Or you might have installed OpenFOAM in "C:\Program Files", which is a big "no no" in Windows Vista and 7. Why? Because Windows Vista/7 has this super ghost system for compatibility with XP applications, thus allowing to have a Virtual Store where to store the changes that would otherwise be made directly to the real folder. And this system might not be perfect, as you might be experiencing...

So, if you can give us some more feedback, it'll be easier to diagnose the problem

Best regards,
Bruno

[vatavuk]

Hi Bruno,
Some time ago you sent me some advice and I was able to cross-copile and install the files in my windows machine.
I have a doubt concerning the diferent end of line characters used in windows and unix files. When I open an openFoam file with windows notepad it messes it, trying to put everything on the same line. If I convert all files to the windows format using the unix2dos program will openFoam still be able to read the files? Do you have another solution for this problem?
Thanks

[wyldckat]

Hi Paulo,

Yes I remember you I though about sending you an email telling you that the new patch version for OF 1.7.0 builds with no problems with mingw32 but then time got in the way

As for editing OpenFOAM files: I personally use Notepad2 which can handle Linux files without any problems and has syntax highlighting for various coding languages.
Inside the attached zip file is a Windows Registry file for adding Notepad2 to the right-click for files in Windows Explorer. Edit it (with Notepad2 ) and change the target path. Then after saving, right-click on it and merge. Now you can edit each file simply by right clicking on it

But if you still want to use the basic notepad, you should do unix2dos, edit, then dos2unix. Hopefully it will work without any problems

You could also try using the editor that comes with openfoam-mswin, although it is still something of a proof of concept.


If we were to do conversion between line endings integrated into OpenFOAM, there would be a downside: execution would become slightly slower... and the objective is for OpenFOAM to be as fast as possible in Windows, when compared to Linux

Best regards,
Bruno

[vatavuk]

Hi Bruno,
Both Notepad2 and the registry file worked perfectly.
Thanks,
Paulo

[ThomasFP]

For wyldckat.

Could you please help me compile OpenFOAM? I am trying to build OpenFOAM 1.7.0 for windows by following your instructions. Very good work. Thank you very much for all your hard work.

Right now OpenFOAM builds fine and I am able to run it in windows but snappyHexMesh doesn't build. I have looked at the output from the compilation and I get the following error messages:

make[2]: *** [libscotch.dll] Error 1
make[2]: Leaving directory `/home/thomas/OpenFOAM/ThirdParty-1.7.0/scotch_5.1/src/libscotch'
make[1]: *** [scotch] Error 2
make[1]: Leaving directory `/home/thomas/OpenFOAM/ThirdParty-1.7.0/scotch_5.1/src/libscotch'
make: *** [scotch] Error 2

And after that:

make[2]: *** [libptscotch.dll] Error 1
make[2]: Leaving directory `/home/thomas/OpenFOAM/ThirdParty-1.7.0/scotch_5.1/src/libscotch'
make[1]: *** [ptscotch] Error 2
make[1]: Leaving directory `/home/thomas/OpenFOAM/ThirdParty-1.7.0/scotch_5.1/src/libscotch'
make: *** [ptscotch] Error 2

Could that be why snappyHexMesh (and possibly other utilities) doen't build corrently.

This is similar to the problem billybore had, så I ran the code below but no files showed up.
find $WM_PROJECT_DIR/ -name "*.rej"
find $WM_THIRD_PARTY_DIR/ -name "*.rej"

@billybore: How did you resolve the problem with scotch?

I have also run the code below and have attached scotchBuild.tar.gz to this post.

cd $WM_THIRD_PARTY_DIR
./AllwmakeMinGWScotch > scotchBuild.log 2>&1
tar -czf scotchBuild.tar.gz scotchBuild.log

Currently I use mingw-w32 with gcc 4.5.0 on a virtualbox. But I have also tried to compile OpenFOAM with gcc 4.4.0 with mingw32 and mingw-w32, with mingw32 and gcc 4.5.0 and with i686-w64-mingw32. I had some problems compiling OpenFOAM, which I thought was compiler related, so I tried different combinations to resolve the problems.

Finally, I have found that if you have libstdc++-6.dll else where on your computer and added to the windows PATH OpenFOAM does't work when you start it with the DOS_Mode.bat file, but gives an error message. My workaround was to copy libstdc++-6.dll to the C:\OpenFOAM\OpenFOAM-1.7.0\applications\bin\linuxi686-w64-mingw32DPOpt folder. Now everything works.

Kind regards,
Thomas.

[wyldckat]

Greetings Thomas and welcome to the forum!

Many thanks for the details and the attached log file! OK, as for the details list, I'll respond inline:

Originally Posted by ThomasFP

make[2]: *** [libscotch.dll] Error 1
make[2]: Leaving directory `/home/thomas/OpenFOAM/ThirdParty-1.7.0/scotch_5.1/src/libscotch'
make[1]: *** [scotch] Error 2
make[1]: Leaving directory `/home/thomas/OpenFOAM/ThirdParty-1.7.0/scotch_5.1/src/libscotch'
make: *** [scotch] Error 2

Just to let you know: the more relevant error message was 2 lines above this and said:

(...)ld: cannot find -lscotcherr

Similarly the same happened for ptscotch

Originally Posted by ThomasFP

Could that be why snappyHexMesh (and possibly other utilities) doen't build corrently.

Yep, this is one of the reasons all right!

Originally Posted by ThomasFP

This is similar to the problem billybore had, så I ran the code below but no files showed up.
find $WM_PROJECT_DIR/ -name "*.rej"
find $WM_THIRD_PARTY_DIR/ -name "*.rej"

OK, that's actually a good sign! It should mean that the patches were applied without any problems!

Originally Posted by ThomasFP

Currently I use mingw-w32 with gcc 4.5.0 on a virtualbox. But I have also tried to compile OpenFOAM with gcc 4.4.0 with mingw32 and mingw-w32, with mingw32 and gcc 4.5.0 and with i686-w64-mingw32. I had some problems compiling OpenFOAM, which I thought was compiler related, so I tried different combinations to resolve the problems.

OK, two things here:

1. I hope you did follow the additional instructions for using gcc 4.5.0! Otherwise there will be problems with some of OpenFOAM's applications.
2. Which Linux version are you using in your Virtualbox virtual machine? If I knew which Linux version it is, I can try to reproduce the error, which seems deeply related to the Linux version I've used Ubuntu 9.10 and 10.04, as well as Cygwin in Windows with success, so it feels a bit odd as to why Scotch is being so picky

Originally Posted by ThomasFP

Finally, I have found that if you have libstdc++-6.dll else where on your computer and added to the windows PATH OpenFOAM does't work when you start it with the DOS_Mode.bat file, but gives an error message. My workaround was to copy libstdc++-6.dll to the C:\OpenFOAM\OpenFOAM-1.7.0\applications\bin\linuxi686-w64-mingw32DPOpt folder. Now everything works.

Mmm, this is odd as well... the script Allwmake in ThirdParty-1.7.0 should have done that for you and I quote:

    echo ========================================
    echo Copying gcc related DLLs
    echo
    cp $WM_COMPILER_DIR/bin/*.dll $FOAM_LIBBIN

I wonder why that didn't work
EDIT: I re-read your post: what is the error that DOS_Mode.bat gives you when it starts?

As for the error you are getting, I think I got a lead on what the problem might be: the build order is off and make didn't cope with the bad build order

So, please try following these instructions:

1. Edit the file "ThirdParty-1.7.0/scotch_5.1/src/libscotch/Makefile".
2. Find these lines (starts in line 58):

                       $(MAKE) CC="$(CCS)" CCD="$(CCSS)" SCOTCHLIB=scotch    \
                       scotch.h                        \
                       scotchf.h                        \
                       libscotch$(LIB)                        \
                       libscotcherr$(LIB)                    \
                       libscotcherrexit$(LIB)

   And change them to this:

                       $(MAKE) CC="$(CCS)" CCD="$(CCSS)" SCOTCHLIB=scotch    \
                       scotch.h                        \
                       scotchf.h                        \
                       libscotcherr$(LIB) libscotcherrexit$(LIB) libscotch$(LIB)

3. Similarly, do the same for ptscotch - find (starts about in line 71):

                       $(MAKE) CFLAGS="$(CFLAGS) -DSCOTCH_PTSCOTCH" CC="$(CCP)" SCOTCHLIB=ptscotch    \
                       scotch.h                                    \
                       scotchf.h                                    \
                       libptscotch$(LIB)                                \
                       libptscotcherr$(LIB)                                \
                       libptscotcherrexit$(LIB)

   And change to this:

                       $(MAKE) CFLAGS="$(CFLAGS) -DSCOTCH_PTSCOTCH" CC="$(CCP)" SCOTCHLIB=ptscotch    \
                       scotch.h                                    \
                       scotchf.h                                    \
                       libptscotcherr$(LIB) libptscotcherrexit$(LIB) libptscotch$(LIB)

4. OK, save the file, close the editor, and try to build Scotch once again as you did before.

If the errors still occurs (or if a new comes up), please post again the new log file. But if it works, please tell us about it and also please tell me which Linux you are using in Virtualbox, so I can try to reproduce these errors! This way I can try and prevent similar problems from occurring in the future

Best regards,
Bruno