CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Installation

Windows Installation BugsComments on Petrbs patch

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   February 7, 2006, 16:13
Default I'm working my way through thi
  #1
brooksmoses
Guest
 
Posts: n/a
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!
  Reply With Quote

Old   February 7, 2006, 17:21
Default At first thanks for your comme
  #2
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,837
Rep Power: 38
gschaider will become famous soon enoughgschaider will become famous soon enough
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
__________________
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
gschaider is offline   Reply With Quote

Old   February 7, 2006, 20:26
Default Thanks for the reply! I did
  #3
brooksmoses
Guest
 
Posts: n/a
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.
  Reply With Quote

Old   February 7, 2006, 22:56
Default Addendum: I was looking at the
  #4
brooksmoses
Guest
 
Posts: n/a
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.
  Reply With Quote

Old   February 8, 2006, 01:35
Default A suggested addendum to the HO
  #5
brooksmoses
Guest
 
Posts: n/a
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.)
  Reply With Quote

Old   February 8, 2006, 04:55
Default Greetings! It is nice to have
  #6
Member
 
Petr Vita
Join Date: Mar 2009
Posts: 57
Rep Power: 7
pvita is on a distinguished road
Send a message via MSN to pvita Send a message via Skype™ to 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
pvita is offline   Reply With Quote

Old   February 8, 2006, 16:41
Default Petr - I think I am indeed mad
  #7
brooksmoses
Guest
 
Posts: n/a
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.
  Reply With Quote

Old   February 8, 2006, 19:06
Default While I'm waiting for OpenFOAM
  #8
brooksmoses
Guest
 
Posts: n/a
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....
  Reply With Quote

Old   February 8, 2006, 19:09
Default Hehe... I throw that idea to d
  #9
Member
 
Petr Vita
Join Date: Mar 2009
Posts: 57
Rep Power: 7
pvita is on a distinguished road
Send a message via MSN to pvita Send a message via Skype™ to 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 is offline   Reply With Quote

Old   February 8, 2006, 19:18
Default Nobody knows what happens in W
  #10
Member
 
Petr Vita
Join Date: Mar 2009
Posts: 57
Rep Power: 7
pvita is on a distinguished road
Send a message via MSN to pvita Send a message via Skype™ to 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.
pvita is offline   Reply With Quote

Old   February 8, 2006, 21:06
Default 1.) Yup. I added the followin
  #11
brooksmoses
Guest
 
Posts: n/a
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.
  Reply With Quote

Old   February 9, 2006, 03:53
Default One more question, from down a
  #12
brooksmoses
Guest
 
Posts: n/a
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?
  Reply With Quote

Old   February 9, 2006, 04:05
Default No, I didn't compiled parallel
  #13
Member
 
Petr Vita
Join Date: Mar 2009
Posts: 57
Rep Power: 7
pvita is on a distinguished road
Send a message via MSN to pvita Send a message via Skype™ to 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.
pvita is offline   Reply With Quote

Old   February 9, 2006, 04:17
Default Ah, ok. (I wasn't sure whethe
  #14
brooksmoses
Guest
 
Posts: n/a
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!
  Reply With Quote

Old   February 9, 2006, 04:18
Default I have taken a short look into
  #15
Member
 
Petr Vita
Join Date: Mar 2009
Posts: 57
Rep Power: 7
pvita is on a distinguished road
Send a message via MSN to pvita Send a message via Skype™ to 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 is offline   Reply With Quote

Old   February 9, 2006, 04:28
Default MICO is just for FoamX so you
  #16
Member
 
Petr Vita
Join Date: Mar 2009
Posts: 57
Rep Power: 7
pvita is on a distinguished road
Send a message via MSN to pvita Send a message via Skype™ to 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.
pvita is offline   Reply With Quote

Old   February 10, 2006, 01:14
Default Ok, I've now got a complete wo
  #17
brooksmoses
Guest
 
Posts: n/a
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.
  Reply With Quote

Old   February 10, 2006, 08:17
Default Well, I am very happy to hear
  #18
Member
 
Petr Vita
Join Date: Mar 2009
Posts: 57
Rep Power: 7
pvita is on a distinguished road
Send a message via MSN to pvita Send a message via Skype™ to 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. ;-)
pvita is offline   Reply With Quote

Old   February 18, 2006, 19:41
Default Petr: Hope you had a good vaca
  #19
brooksmoses
Guest
 
Posts: n/a
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....
  Reply With Quote

Old   February 20, 2006, 04:31
Default I have got perfect vacation wi
  #20
Member
 
Petr Vita
Join Date: Mar 2009
Posts: 57
Rep Power: 7
pvita is on a distinguished road
Send a message via MSN to pvita Send a message via Skype™ to 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.
pvita is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
HELP NEEDED HOW TO MAP VALUES FROM PATCH OF ONE MESH TO PATCH OF ANOTHER MESH mkraposhin OpenFOAM Running, Solving & CFD 3 September 4, 2011 09:42
INSTALLATION OF 141 naveen OpenFOAM Installation 3 January 30, 2009 04:19
Regarding installation vidyaprakash CD-adapco 0 December 21, 2006 23:03
Installation of 13 grtabor OpenFOAM Installation 14 August 24, 2006 12:43
Windows Installation Petrbs Port Redux Patches and Binary Distribution brooksmoses OpenFOAM Installation 0 February 10, 2006 17:35


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