I'm working my way through this patch and trying to understand what's included in it and how it all works. Here's what I've come across so far:

First, setup changes have only been made to .bashrc and .OpenFOAM-1.2/bashrc; those of us who are tcsh-users will need to make parallel changes to the equivalent cshrc files.

* The system name test is for "CYGWIN_NT-5.0". This will only work on Windows 2000; Windows XP reports "CYGWIN_NT-5.1" (I think), and Windows 2003 reports "CYGWIN_NT-5.2".

* The .OpenFOAM-1.2/bashrc file sets LOGNAME=$USER. Is this needed? On both of my Cygwin systems, this is already set correctly.

Also, there appear to be some extraneous changes in the patch file that have nothing to do with the Cygwin port, but are related to other bug-fixes. Can I get a confirmation as to whether the changes to the following files are indeed unrelated?

* applications/utilities/postProcessing/dataConversion/foamToVTK/writeFuns.C
* src/lagrangian/basic/Cloud/Cloud.H
* src/lagrangian/dieselSpray/parcel/parcelIO.C
* src/lagrangian/dieselSpray/parcel/parcelIO.H
* src/lagrangian/dieselSpray/spray/spray.C
* src/triSurface/triSurface/octreeData/octreeDataTriSurface.C
* src/triSurface/triSurface/triSurfaceSearch/triSurfaceSearch.C

Thanks much!

[gschaider]

At first thanks for your comment. Petr was really looking forward to feedback and he'll answer in course, but let me take the blame where I should take the blame (the praise should go to Petr because he worked hard at something that doesn't involve his core interest):

- the tcsh-thing is a valid point: the problem is that Petr is living amongst a bunch of Bashists so he isn't exposed to that kind of cultural diversity (he's got to live amongst Austrians as a Czech, that's hard enough)

- for the windows-versions it's similar (and of course you're right): Petr didn't have any other Windows versions for testing because we've got a Stalinist point of view on windows versions here (my point is: "Windows should run Word/Powerpoint to keep the boss and the secretary happy and support USB-ports and Quake to keep the rest happy" ->Win2000. If it wasn't for USB we would still run NT4.0; the process scheduler was much better IMO)

- LOGNAME: seems to be a Win2000-thing (but the final word is with Petr)

- the patches: you're right again. Petr got the patched sources we use for working when he started the port. When the port was finished and he started doing the patch he did so against the downloaded 1.2-sources.
writeFuncs.C: this had to do with the MacOS-port (->unrelated)
src/lagrangian: (unrelated but very valuable if you want to use dieselFoam, have been published elsewhere on the board)
src/triSurface: these I can't remember doing. Going to check with Petr

Thanks for the reply!

I did some more checking on LOGNAME just now. It appears to be a Cygwin-bash thing, oddly enough. If I start a bash window, LOGNAME is not set; if I set a tcsh window, it is set. (And, if I start bash from within tcsh, which is how I tested it the first time, it stays set.) Weird.

Incidentally, I'll be glad to supply my cshrc files once I get things running at my end, so no need to worry about creating them.

More comments later.

Addendum: I was looking at the changes to writeFuns.C, and noticed that they started with "#ifdef Cygwin" -- so I suppose those are related after all.

I can't really tell whether the src/triSurface changes are related or not; they're adding #include "octreeDataTriSurfaceTreeLeaf.H" to octreeDataTriSurface.C and triSurfaceSearch.C.

A suggested addendum to the HOWTO document: Compiling OpenFOAM in Cygwin requires that one have the bison and flex packages installed. (They're not installed by default as part of Cygwin; one has to specifically install them.)

[pvita]

Greetings! It is nice to have somebody who try it and is mad enough to want to get OpenFOAM under Cygwin working.

ad 1) bash/csh: I am a bash-man. It will be nice if you can introduce those changes to other rc-scripts as well.

ad 2) Windows-clones: I have Windows 2000 as Bernhard is hard-core Stalinist, what I as former citizen of Czechoslovakia understand and sustain, that is why I could not test other platforms. We will have to change that test to:

if [ `uname -s | sed -e '/CYGWIN*/c\Cygwin'` = "Cygwin" ]; then
.
.
.

ad 3) LOGNAME=$USER: This is probably bash problem.

ad 4) *.C and *.H files:

applications/utilities/postProcessing/dataConversion/foamToVTK/writeFuns.C: Definitions of a little and big endian was provided by #include <sys/param.h> not in by #include <sys/endian.h> at time I gone through applications.

src/lagrangian/basic/Cloud/Cloud.H,
src/lagrangian/dieselSpray/parcel/parcelIO.C,
src/lagrangian/dieselSpray/parcel/parcelIO.H,
src/lagrangian/dieselSpray/spray/spray.C: A solution to an instantiation problem of methods void Cload<t>::writeFields() const and void Cload<t>::readFields() const for class parcel. I met this yet with GNU GCC 3.4.4 and I let it be there for GNU GCC 4.0.2 as it breaks nothing and is consistent with the rest of code.

src/lagrangian/basic/Cloud/Cloud.H: Those added virtual method modifiers reflect discussion in lagrangian code, see thread Running - dieselFoam - error. This should probably get out of the patch for Cygwin.

src/triSurface/triSurface/octreeData/octreeDataTriSurface.C,
src/triSurface/triSurface/triSurfaceSearch/triSurfaceSearch.C: The same instantiation problem of template method bool treeLeaf<t>::findNearest() for class octreeDataTriSurface.

PV

Petr - I think I am indeed mad; I had the idea to try to get it working without using a managed mount, and got far enough along before I realized how hard it would be that it was easier to keep going and finish it.

1.) Once I have this confirmed working, I will provide the tcsh scripts. (For reference of anyone following along, I found another one that needs changes: wmake/cshScripts/addCompile. This provided a very cryptic result of making .dep files where it should make .idep files, until I fixed it.)

2.) Indeed; thanks! That's much cleaner than explicitly checking for CYGWIN_NT-5.0, CYGWIN_NT-5.1, and CYGWIN_NT-5.2, as I was doing.

3.) Perhaps the most elegant way to handle this is to set LOGNAME to $USER if $LOGNAME is undefined.

4.) Thanks; that helps.

At this point, I have just gotten things to the point where wmake tells me:
"`/disk2/brooks/OpenFOAM/OpenFOAM-1.2/lib/cygwinGcc4Opt/dummy/libPstream.dll' is up to date."
I am very happy with this!

Finally, for those who don't want to spend three hours compiling GCC, I've zipped up my compiled version (made with your script to set the appropriate configuration for OpenFOAM) and put it up at http://dpdx.net/software/openfoam/cygwin so other people can use that rather than having to compile their own copy.

While I'm waiting for OpenFOAM to try to make, I've got another comment.... In the HOWTO, there's the comment:

You will get to point where OpenFOAM will try to link all its headers and source files into directory ~/OpenFOAM/OpenFOAM-1.2/src/OpenFOAM/lnInclude.

4a. Compilation got stucked! Nothing happens for a very long time. The task manager show process ln takes near 99% of CPU time, all in user space only. You are damned. Follow instructions in point 5.

What do are you considering a "very long time" here? I've found that wmakeLnInclude normally takes about five minutes to run on the OpenFOAM directory on my computer, but it seems that it does always reliably finish if I let it run....

[pvita]

Hehe... I throw that idea to do it without managed out away at the start as it should be done only through help of core developers... I am to lazy to clean that mess...

ad 1) addCompile: I have no sources around at this very moment as I write from home, but if I remember well, addCompile has four flavours-bash, ksh, tcsh and csh. They are based basically on only two original scripts as the rest is created through sed. Have a look in makeWmake, I guess, if you are editing the right one...

ad 3) LOGNAME: Yeap...

Can you introduce all those changes and addendums you done/proposed into all relevant files and create a new patch please? If it will be possible, give it some version number so we won't be lost later in them. I am on holidays next week so I won't push my brain to it.

PV

[pvita]

Nobody knows what happens in Windows... On my machine ln.exe gots reguraly stucked. I define that moment just based on performance monitoring as it takes only CPU time in user space and not in system space oposite to CPU usage history. But as I said, it can go through. I identify this state in this way and get it to work effectively crippling Windows processes. It do not need to be so by other OpenFOAMiminators.

1.) Yup. I added the following code to the front of cshScripts/addCompile, and it seems to work:

if ($2 == "--import") then
set objectName=$sourceName:r_import.o
set depName=$1:r.idep
else
set objectName=$sourceName:r.o
set depName=$1:r.dep
endif

As for a new patch: This is indeed my plan -- I've been taking your patch and dividing it up into various parts with notes on what each part does, and making similar patches with my changes. And, once I get everything working on my system so that I know I've done everything right, I will very definitely post all of them.

As for ln -- I should, indeed, have paid more attention to your comment about userspace versus systemspace.

Meanwhile, the current status report from wmake:
`/disk2/brooks/OpenFOAM/OpenFOAM-1.2/lib/cygwinGcc4Opt/libOpenFOAM.dll' is up to date.

One more question, from down at the end of src/Allmake, where it's making MICO. The commands to make MICO involve "gmake", but there isn't a gmake on my Cygwin machine. I'm presuming that the appropriate thing to do is to use "make", but I'm curious whether you ran into this difficulty....

Actually, now that I've run make on it, I see that compilation fails anyway, due to a lack of an asinl function, so getting it to compile would be rather more complicated than that.

So: did you get MICO to compile? Did you just ignore the errors? Or is there something that I'm missing in stepping through the Allmake by hand that causes the make process to not attempt to compile it at all?

[pvita]

No, I didn't compiled parallel stuff as it is not on my roadmap at this time. The first think was to get OpenFOAM single version running. The MICO/LAM is a future stuff for now.

Ah, ok. (I wasn't sure whether MICO was for the parallel code, or something else.) I guess the "gmake not found" errors are a convenient way to avoid trying to make it on Cygwin, then!

Oh, and one very last question before I go to bed:

When I try to run wmake on solvers/basic/scalarTransportFoam, I get the following output and error:

SOURCE_DIR=.
SOURCE=scalarTransportFoam.C ; g++ -m32 -Dcygwin -Wall -W -Wno-unused-parameter -Wold-style-cast -O
3 -ffast-math -DNoRepository -ftemplate-depth-30 -I/disk2/brooks/OpenFOAM/OpenFOAM-1.2/src/cfdTools
/incompressible -I/disk2/brooks/OpenFOAM/OpenFOAM-1.2/src/cfdTools/general/lnInclude -I/disk2/brooks
/OpenFOAM/OpenFOAM-1.2/src/OpenFOAM/lnInclude -IlnInclude -I. -c $SOURCE -o Make/cygwinGcc4Opt/sc
alarTransportFoam.o
/disk2/brooks/OpenFOAM/OpenFOAM-1.2/wmake/Makefile:149: *** unterminated variable reference. Stop.

I find that particularly baffling because all of the other solvers in the basic and incompressible directories (those are the only ones I've had time to try to compile so far) compile fine with wmake, and I can't see anything obvious that's different for this one. Any ideas?

Thanks very much!

[pvita]

I have taken a short look into LAM and MICO pages and it should not be problem.

MICO should be driect compilable as standard Unix installation, see INSTALL.txt in mico-2.3.11 folder.

LAM should work as well. Have a look in a LAM FAQ: Platform Specific Question, Question 2.

[pvita]

MICO is just for FoamX so you can click-clack some parameters. Simply not core stuff to get to number crunching.

LAM is MPI implementation, ie. parallel crunching.

scalarTransportFoam: Take a look into Make\options and correct the 7th line to:

-L$(FOAM_LIBBIN)/dummy \

There is forgoten closed parenthesis of FOAM_LIBBIN variable.

Ok, I've now got a complete working compilation (well, aside from FoamX and parallel-processing and the other things that depended on MICO), without using a managed mount. Hooray! Tremendous thanks to Petr and his coworkers for making this possible.

I'll post a new thread on that with patches and so forth tomorrow, once I get a chance to upload some tarballs and do a bit of testing to make sure the compiled files work correctly.

Most of the patches are only marginally affected by the changes I made to deal with case-insensitivity problems, so it should be pretty simple to see how they affect the managed-mount version.

[pvita]

Well, I am very happy to hear you got it compiled as well, thanks a lot for your help and cooperation. I am looking forward on that new enhanced patch but I will comment it after my holidays first. Hope we will not met a lot of problems while trying to use it now. ;-)

Petr: Hope you had a good vacation!

So far, I've only come across one bug in using the Cygwin version, once I got it compiled -- apparently the extra linking going on in making Pstream.dll causes all of my programs to print the "OpenFOAM" banner twice. Is that happening on your version, too? (If so, I'm pretty sure I know a way to fix it.)

Also, how do you figure out which applications need extra libraries linked in for the Cygwin version? (I mean all the additions in the Make/options files.) So far, I've just been doing those for my own applications by guesswork based on the ones that you've done....

[pvita]

I have got perfect vacation with six sunny days on the Austrian slopes. Thanks for asking. As I have seen you made a tremedous work going through the whole patch. Good work!

ad 1) OpenFOAM banner: Yes, I have it twice as well. I suspect a static variable initialization that occurs in both dll-files. That code is global, uses just std::cout and is done twice for libOpenFOAM.dll and libPstream.dll. I was not treating it as a bug, just let us say as a Cygwin anomaly without side-effect.

ad 2) Well, I am using quite straitforward reasoning method. Imagine a case when compilation fails because of undefined reference to method foam::A::a(). I will look-up this method in doxygen documentation to find out the source file. That source file has to be core part of some library, ie. it is listed in some Make\files as non-imported one. Well, and this library gets in Make\options. Rule of thumb: Error stuff needs libPstream.dll, most of code libOpenFOAM.dll and the rest is a special case.