Trouble compiling utilities using source-built OpenFOAM
 

Hi,

I've just built OF 2.2.2 from source on my University's cluster. Everything went much smoother than expected, foamInstallationTest returned no problems, I ran the cavity tutorial OK, echo'ed most of the environment variables and they seem OK too.

When I try recompiling icoFoam as myIcoFoam I get the following:

The reason I recompiled OF in the first place to prevent these from happening on the build that I have already available on the cluster. It seems that files from $FOAM_SRC/OpenFOAM/lnInclude cannot be accessed for some reason (I checked, they are all there physically). I tried adding that directory explicitly in Make/options for the compiler but that didn't help.

Strangely enough, the compiled utility works. I ran the cavity tutorial with it successfully. Hence I am not sure whether I should just ignore these warnings or will they cause problems for me in the future?

Any advice will be much appreciated,

A

EDIT: I didn't say that it's the "cannot open file" that I'm worried about, not the "unused variable" warnings...

Greetings Artur,

Uhm... it specifically says it's just a warning ;):
Let me find something I wrote on this sometime ago... here we go, I'll quote myself from a post I made back in 2010 :cool::
Best regards,
Bruno

Hi,

Thanks for the answer. In my question I was referring to the "cannot open file" highlighted in red, sorry I didn't make it very clear.

Best wishes,

A

Hi Artur,

:eek: Ooops, sorry, I should have read it more carefully.

Quick question: did you run wclean before wmake? If not, this could be the reason for those messages.


I actually ended up learning to ignore those particular messages, because that only occurs on the pre-calculation of dependencies section:
The problem is usually related to the wmkdep not being able to find those files. For reference, it is called through the rule file "wmake/rules/General/sourceToDep".
AFAIK, this issue usually occurs for roughly 2 reasons:

1. The paths to the header files aren't properly given to wmkdep to process. This is due to some sort of bug on the scripts.
2. Or because the header files that have been diagnosed as necessary, actually aren't necessary.
   • For example, this happens on swak4Foam, which is compatible with both the official OpenFOAM version and the Extend variant(s) of OpenFOAM (1.5-dev and 1.6-ext). It actually builds because there are macro definitions that tell apart which parts of the code should be used, but wmkdep isn't able to process these macros, which is why it tries to find all included files.

Mmm... this is a good question that you ask! I've had this problem on Windows+MSys and haven't taken the time to diagnose the actual problem... but on Linux, it's somewhat strange that this occurs :confused:

I can try to have a better look into this, so I could use some more information on the exact steps you've taken:

1. For your "myIcoFoam" customized version, did you simply copy the folder from the "icoFoam" source code, then change the file "Make/files" and then run wmake?
   1. Or did you also run wclean, as I asked above?
   2. And was there any another change in particular?
2. Which Linux distribution is being used on the cluster you are using?Which shell are you using, namely if it's bash, dash or csh?
   • Perhaps in this case the most important is what "/bin/sh" actually is? This can be checked by running:
     
     Code:

     ---

     ls -l /bin/sh

     ---

     For example, for me it says this on my Ubuntu 12.04:
     
     Code:

     ---

     /bin/sh -> dash

     ---

3. The last issue is what kind of file system is being used on the cluster. This is because if the file system is using a shared "/home" folder among all nodes, this could lead to certain issues for some programs... mostly due to how symbolic links are handled.

Best regards,
Bruno

Thanks a lot for the exhaustive answer. In reply to your questions:

1. I did simply copy the original solver into OpenFOAM/artur-2.2.2/applications, and then ran wclean, rmdepall and wmake it; this is what I always do when compiling stuff on a newly set up OpenFOAM release and I never ran into this problem before I started using this cluster.

2. the cluster I'm using uses Redhat Enterprise 5 Linux

3. the test you recommended returns (akl1g09 is my user name; no, I didn't get to choose it :P):

My wmake/rules/General/sourceToDep file looks as follows:

All the best,

A

P.S. I just noticed that the WMAKE_BIN is not defined in my path, when I try to echo it, it returns a null value. I suppose this might be a problem... I'll try to explore it a bit and compare with other linux machines I have with OF on them.

P.P.S. on my home machine the WMAKE_BIN also cannot be echo'ed but the same test (recompiling icoFoam) doesn't complain about not being able to open the headers... (on this machine I installed OF using apt-get install - it's Ubuntu 12.04).

Hi Artur,

"WMAKE_BIN" is defined during the build process, in the file "wmake/Makefile":
To see the actual path in the shell:
It should show you that the following files exist:
OK, from the information you've provided, it's likely that the bash shell is a lot older than OpenFOAM has been tested with. I'll try to test this later today on a VM with CentOS 5.8, to see if I get the same issue.

Best regards,
Bruno

Thanks a lot for your support and willingness to help, I really appreciate that!

I do have all the three files you mentioned located in that directory.

All the best,

A

Hi Artur,

If you edit the file "wmake/rules/General/sourceToDep" and change this line:
To this:
Then try on the folder of your modified solver:
It should give you at the beginning of the output something like this:
The "|||" characters are just for making it easier to spot the hack made. The list of folders seems somewhat repeated, but that's normal.
Please check what you get on your side.

From what I can see, the source code of "wmake/src/wmkdep.l" doesn't reveal any specific coding problems that might occur, so my guess is that it's the provided paths through "wmake/rules/General/sourceToDep" that are broken somehow.

Best regards,
Bruno

Hi Bruno,

Thanks a lot for spending your time to look into this. I followed your suggestion and modified the sourceToDep file. The output of the compiler returns:

It clearly seems that src/OpenFOAM/lnInclude is being linked and yet somehow the files aren't found...

I rand the bin/foamInstallationTest script again and went through the output once more, here's what it's got to say:

I don't see anything unusual but then it's my first time building OF from source so....

Not sure what to check next to be honest.

All the best,

Artur

Hi Artur,

I had a better look into this on Windows and then I saw and remembered what the problem is: the wmkdep utility needs to open way more than 100 files at the same time :rolleyes: And the reason why it gives those messages is because it's no longer able to open any more files.

This is known by the veterans who use OpenFOAM technology and usually easily forgotten :rolleyes: Here's a thread on this topic: http://www.cfd-online.com/Forums/ope...pen-files.html

So, the solution? Try running this command before wmake on the cluster:
This is so to avoid issues with applications that try to do hostile take overs of the system or simply to break the system.

Best regards,
Bruno

That makes so much sense... Thanks a lot for helping me in understanding the issue.

As I try running I get a message that says that I'm not allowed to do this. When I try just it returns 256.

Do you think that this may cause to me receiving some random linker errors in the future or should I just ignore it? I suppose I could try emailing the system administrators to ask them to change the settings for my profile but I don't think they would do that :p

Best wishes,

Artur

Hi Artur,

Well, from my experience, this issue doesn't break the building process. All it does is to not create a full list of dependencies for each source code file, which will force you to rebuild your custom utility. This usually happens in case you are using OpenFOAM 2.2.x and do a git pull + Allwmake.

In other words: if the base OpenFOAM source changes, wmake won't be fully aware if myIcoFoam needs to be rebuilt or not.

Best regards,
Bruno

I see. It's good to know that. Fortunately I don't plan on modifying any of the very base OF files in the foreseeable future.

Thanks again for all your help,

Artur

Hi Artur,

I haven't managed to test this myself, but there is something I'm wondering about. There are two similarly named utilities in OpenFOAM wmake toolkit:
From what I could figure out from the comment section of the wmkdepend source code (located at "wmake/src"), I suspect that wmkdepend was in fact born as an idea from that other thread I reported to the other day.
Therefore, in theory, if in the file "wmake/rules/General/sourceToDep" we replace wmkdep for wmkdepend, perhaps the messages do not show up and the desired functionality will occur.
But as I said, I have not tested this yet myself.

Best regards,
Bruno

That actually worked! Making the dependency list takes longer than it does with wmakedep (as one would expect) but no "cannot open file" messages appear. Thanks again for all your help!

Best wishes,

Artur