CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Programming & Development (http://www.cfd-online.com/Forums/openfoam-programming-development/)
-   -   Trouble compiling utilities using source-built OpenFOAM (http://www.cfd-online.com/Forums/openfoam-programming-development/125472-trouble-compiling-utilities-using-source-built-openfoam.html)

Artur October 26, 2013 05:16

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:

Code:

Making dependency list for source file myIcoFoam.C
could not open file SubListI.H for source file myIcoFoam.C
could not open file intersection.H for source file myIcoFoam.C
could not open file pointHit.H for source file myIcoFoam.C
could not open file ListListOps.H for source file myIcoFoam.C
could not open file faceI.H for source file myIcoFoam.C
could not open file faceTemplates.C for source file myIcoFoam.C
could not open file cellList.H for source file myIcoFoam.C
could not open file cellShapeList.H for source file myIcoFoam.C
could not open file boolList.H for source file myIcoFoam.C
could not open file HashSet.H for source file myIcoFoam.C
could not open file Map.H for source file myIcoFoam.C
could not open file primitiveMeshI.H for source file myIcoFoam.C
could not open file pointIOField.H for source file myIcoFoam.C
could not open file faceIOList.H for source file myIcoFoam.C
could not open file labelIOList.H for source file myIcoFoam.C
could not open file polyBoundaryMesh.H for source file myIcoFoam.C
could not open file boundBox.H for source file myIcoFoam.C
could not open file pointZoneMesh.H for source file myIcoFoam.C
could not open file faceZoneMesh.H for source file myIcoFoam.C
could not open file cellZoneMesh.H for source file myIcoFoam.C
could not open file lduMesh.H for source file myIcoFoam.C
could not open file fvBoundaryMesh.H for source file myIcoFoam.C
could not open file surfaceInterpolation.H for source file myIcoFoam.C
could not open file fvSchemes.H for source file myIcoFoam.C
could not open file fvSolution.H for source file myIcoFoam.C
could not open file data.H for source file myIcoFoam.C
could not open file DimensionedField.H for source file myIcoFoam.C
could not open file volFieldsFwd.H for source file myIcoFoam.C
could not open file surfaceFieldsFwd.H for source file myIcoFoam.C
could not open file pointFieldsFwd.H for source file myIcoFoam.C
could not open file slicedVolFieldsFwd.H for source file myIcoFoam.C
could not open file slicedSurfaceFieldsFwd.H for source file myIcoFoam.C
could not open file fvPatchFvMeshTemplates.C for source file myIcoFoam.C
could not open file fvc.H for source file myIcoFoam.C
could not open file fvMatrices.H for source file myIcoFoam.C
could not open file fvm.H for source file myIcoFoam.C
could not open file linear.H for source file myIcoFoam.C
could not open file uniformDimensionedFields.H for source file myIcoFoam.C
could not open file calculatedFvPatchFields.H for source file myIcoFoam.C
could not open file fixedValueFvPatchFields.H for source file myIcoFoam.C
could not open file adjustPhi.H for source file myIcoFoam.C
could not open file findRefCell.H for source file myIcoFoam.C
could not open file constants.H for source file myIcoFoam.C
could not open file argList.H for source file myIcoFoam.C
could not open file timeSelector.H for source file myIcoFoam.C
could not open file setRootCase.H for source file myIcoFoam.C
could not open file createTime.H for source file myIcoFoam.C
could not open file createMesh.H for source file myIcoFoam.C
could not open file createFields.H for source file myIcoFoam.C
could not open file initContinuityErrs.H for source file myIcoFoam.C
could not open file readPISOControls.H for source file myIcoFoam.C
could not open file CourantNo.H for source file myIcoFoam.C
could not open file continuityErrs.H for source file myIcoFoam.C

SOURCE=myIcoFoam.C ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/finiteVolume/lnInclude -IlnInclude -I. -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/OpenFOAM/lnInclude -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/OSspecific/POSIX/lnInclude  -fPIC -c $SOURCE -o Make/linux64GccDPOpt/myIcoFoam.o
In file included from myIcoFoam.C:53:0:
/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/finiteVolume/lnInclude/readPISOControls.H: In function ‘int main(int, char**)’:
/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/finiteVolume/lnInclude/readPISOControls.H:3:15: warning: unused variable ‘nOuterCorr’ [-Wunused-variable]
    const int nOuterCorr =
              ^
/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/finiteVolume/lnInclude/readPISOControls.H:12:16: warning: unused variable ‘momentumPredictor’ [-Wunused-variable]
    const bool momentumPredictor =
                ^
/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/finiteVolume/lnInclude/readPISOControls.H:15:16: warning: unused variable ‘transonic’ [-Wunused-variable]
    const bool transonic =
                ^
g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/finiteVolume/lnInclude -IlnInclude -I. -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/OpenFOAM/lnInclude -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/OSspecific/POSIX/lnInclude  -fPIC -Xlinker --add-needed -Xlinker --no-as-needed Make/linux64GccDPOpt/myIcoFoam.o -L/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/platforms/linux64GccDPOpt/lib \
        -lfiniteVolume -lOpenFOAM -ldl  -lm -o /home/akl1g09/OpenFOAM/akl1g09-2.2.2/platforms/linux64GccDPOpt/bin/myIcoFoam

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...

wyldckat October 26, 2013 05:59

Greetings Artur,

Uhm... it specifically says it's just a warning ;):
Quote:

warning: unused variable
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::
Quote:

Originally Posted by wyldckat (Post 277669)
Those warnings are actually normal. AFAIK, those solvers use header files that are common to various solvers and not all solvers use those variables, therefore it triggers warning messages on those that don't use them.

Best regards,
Bruno

Artur October 26, 2013 06:10

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

wyldckat October 26, 2013 07:16

Hi Artur,

Quote:

Originally Posted by Artur (Post 459098)
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.

: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:
Code:

Making dependency list for source file
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

Artur October 26, 2013 09:12

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):

Code:

[akl1g09@blue32 ~]$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Oct 14  2009 /bin/sh -> bash

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

Code:

.SUFFIXES: .c .cc .cxx .cpp .C .F .f .dep

MKDEP      = $(WMAKE_BIN)/wmkdep -I$(*D) $(LIB_HEADER_DIRS)

.c.dep:
    $(MAKE_DEP)

.cc.dep:
    $(MAKE_DEP)

.cxx.dep:
    $(MAKE_DEP)

.cpp.dep:
    $(MAKE_DEP)

.C.dep:
    $(MAKE_DEP)

.F.dep:
    $(MAKE_DEP)

.f.dep:
    $(MAKE_DEP)

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).

wyldckat October 26, 2013 09:59

Hi Artur,

Quote:

Originally Posted by Artur (Post 459129)
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).

"WMAKE_BIN" is defined during the build process, in the file "wmake/Makefile":
Quote:

https://github.com/OpenFOAM/OpenFOAM.../Makefile#L109
Code:

WMAKE_BIN    = $(WM_DIR)/platforms/$(WM_ARCH)$(WM_COMPILER)

To see the actual path in the shell:
Code:

ls -l $WM_DIR/platforms/$WM_ARCH$WM_COMPILER
It should show you that the following files exist:
Code:

dirToString
wmkdep
wmkdepend

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

Artur October 26, 2013 14:45

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

wyldckat October 27, 2013 08:18

Hi Artur,

If you edit the file "wmake/rules/General/sourceToDep" and change this line:
Code:

MKDEP      = $(WMAKE_BIN)/wmkdep -I$(*D) $(LIB_HEADER_DIRS)
To this:
Code:

MKDEP      = echo "||| $(WMAKE_BIN)/wmkdep -I$(*D) $(LIB_HEADER_DIRS) |||"; $(WMAKE_BIN)/wmkdep -I$(*D) $(LIB_HEADER_DIRS)
Then try on the folder of your modified solver:
Code:

wclean
wmake

It should give you at the beginning of the output something like this:
Code:

||| /home/user/OpenFOAM/OpenFOAM-2.2.x/wmake/platforms/linux64Gcc/wmkdep -I. -I/home/user/OpenFOAM/OpenFOAM-2.2.x/src/finiteVolume/lnInclude -I/home/user/OpenFOAM/OpenFOAM-2.2.x/src/sampling/lnInclude -IlnInclude -I. -I/home/user/OpenFOAM/OpenFOAM-2.2.x/src/OpenFOAM/lnInclude -I/home/user/OpenFOAM/OpenFOAM-2.2.x/src/OSspecific/POSIX/lnInclude  |||
Making dependency list for source file icoFoam.C

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

Artur October 27, 2013 16:19

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:

Code:

||| /home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/wmake/platforms/linux64Gcc/wmkdep -I. -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/finiteVolume/lnInclude -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/sampling/lnInclude -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/OpenFOAM/lnInclude -IlnInclude -I. -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/OpenFOAM/lnInclude -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/OSspecific/POSIX/lnInclude  |||
Making dependency list for source file myIcoFoam.C
could not open file SubListI.H for source file myIcoFoam.C
could not open file intersection.H for source file myIcoFoam.C
could not open file pointHit.H for source file myIcoFoam.C
could not open file ListListOps.H for source file myIcoFoam.C
could not open file faceI.H for source file myIcoFoam.C
could not open file faceTemplates.C for source file myIcoFoam.C
could not open file cellList.H for source file myIcoFoam.C
could not open file cellShapeList.H for source file myIcoFoam.C
could not open file boolList.H for source file myIcoFoam.C
could not open file HashSet.H for source file myIcoFoam.C
could not open file Map.H for source file myIcoFoam.C
could not open file primitiveMeshI.H for source file myIcoFoam.C
could not open file pointIOField.H for source file myIcoFoam.C
could not open file faceIOList.H for source file myIcoFoam.C
could not open file labelIOList.H for source file myIcoFoam.C
could not open file polyBoundaryMesh.H for source file myIcoFoam.C
could not open file boundBox.H for source file myIcoFoam.C
could not open file pointZoneMesh.H for source file myIcoFoam.C
could not open file faceZoneMesh.H for source file myIcoFoam.C
could not open file cellZoneMesh.H for source file myIcoFoam.C
could not open file lduMesh.H for source file myIcoFoam.C
could not open file fvBoundaryMesh.H for source file myIcoFoam.C
could not open file surfaceInterpolation.H for source file myIcoFoam.C
could not open file fvSchemes.H for source file myIcoFoam.C
could not open file fvSolution.H for source file myIcoFoam.C
could not open file data.H for source file myIcoFoam.C
could not open file DimensionedField.H for source file myIcoFoam.C
could not open file volFieldsFwd.H for source file myIcoFoam.C
could not open file surfaceFieldsFwd.H for source file myIcoFoam.C
could not open file pointFieldsFwd.H for source file myIcoFoam.C
could not open file slicedVolFieldsFwd.H for source file myIcoFoam.C
could not open file slicedSurfaceFieldsFwd.H for source file myIcoFoam.C
could not open file fvPatchFvMeshTemplates.C for source file myIcoFoam.C
could not open file fvc.H for source file myIcoFoam.C
could not open file fvMatrices.H for source file myIcoFoam.C
could not open file fvm.H for source file myIcoFoam.C
could not open file linear.H for source file myIcoFoam.C
could not open file uniformDimensionedFields.H for source file myIcoFoam.C
could not open file calculatedFvPatchFields.H for source file myIcoFoam.C
could not open file fixedValueFvPatchFields.H for source file myIcoFoam.C
could not open file adjustPhi.H for source file myIcoFoam.C
could not open file findRefCell.H for source file myIcoFoam.C
could not open file constants.H for source file myIcoFoam.C
could not open file argList.H for source file myIcoFoam.C
could not open file timeSelector.H for source file myIcoFoam.C
could not open file setRootCase.H for source file myIcoFoam.C
could not open file createTime.H for source file myIcoFoam.C
could not open file createMesh.H for source file myIcoFoam.C
could not open file createFields.H for source file myIcoFoam.C
could not open file initContinuityErrs.H for source file myIcoFoam.C
could not open file readPISOControls.H for source file myIcoFoam.C
could not open file CourantNo.H for source file myIcoFoam.C
could not open file continuityErrs.H for source file myIcoFoam.C
SOURCE=myIcoFoam.C ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/finiteVolume/lnInclude -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/sampling/lnInclude -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/OpenFOAM/lnInclude -IlnInclude -I. -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/OpenFOAM/lnInclude -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/OSspecific/POSIX/lnInclude  -fPIC -c $SOURCE -o Make/linux64GccDPOpt/myIcoFoam.o
In file included from myIcoFoam.C:53:0:
/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/finiteVolume/lnInclude/readPISOControls.H: In function ‘int main(int, char**)’:
/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/finiteVolume/lnInclude/readPISOControls.H:3:15: warning: unused variable ‘nOuterCorr’ [-Wunused-variable]
    const int nOuterCorr =
              ^
/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/finiteVolume/lnInclude/readPISOControls.H:12:16: warning: unused variable ‘momentumPredictor’ [-Wunused-variable]
    const bool momentumPredictor =
                ^
/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/finiteVolume/lnInclude/readPISOControls.H:15:16: warning: unused variable ‘transonic’ [-Wunused-variable]
    const bool transonic =
                ^
g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/finiteVolume/lnInclude -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/sampling/lnInclude -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/OpenFOAM/lnInclude -IlnInclude -I. -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/OpenFOAM/lnInclude -I/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/src/OSspecific/POSIX/lnInclude  -fPIC -Xlinker --add-needed -Xlinker --no-as-needed Make/linux64GccDPOpt/myIcoFoam.o -L/home/akl1g09/OpenFOAM/OpenFOAM-2.2.2/platforms/linux64GccDPOpt/lib \
        -lfiniteVolume -lsampling -lOpenFOAM -ldl  -lm -o /home/akl1g09/OpenFOAM/akl1g09-2.2.2/platforms/linux64GccDPOpt/bin/myIcoFoam

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:

Code:

Executing ./foamInstallationTest:


Checking basic setup...
-------------------------------------------------------------------------------
Shell:              bash
Host:              blue32
OS:                Linux version 2.6.18-164.6.1.el5
-------------------------------------------------------------------------------


Checking main OpenFOAM env variables...
-------------------------------------------------------------------------------
Environment_variable Set_to_file_or_directory                Valid      Crit
-------------------------------------------------------------------------------
$WM_PROJECT_INST_DIR /home/akl1g09/OpenFOAM                  yes      yes
$WM_PROJECT_USER_DIR /home/akl1g09/OpenFOAM/akl1g09-2.2.2    yes      no
$WM_THIRD_PARTY_DIR  /home/akl1g09/OpenFOAM/ThirdParty-2.2.2  yes      yes
-------------------------------------------------------------------------------


Checking the OpenFOAM env variables set on the PATH...
-------------------------------------------------------------------------------
Environment_variable Set_to_file_or_directory                Valid Path Crit
-------------------------------------------------------------------------------
$WM_PROJECT_DIR      /home/akl1g09/OpenFOAM/OpenFOAM-2.2.2    yes  yes  yes

$FOAM_APPBIN        ...-2.2.2/platforms/linux64GccDPOpt/bin  yes  yes  yes
$FOAM_SITE_APPBIN    .../2.2.2/platforms/linux64GccDPOpt/bin  no        no
$FOAM_USER_APPBIN    ...-2.2.2/platforms/linux64GccDPOpt/bin  yes  yes  no
$WM_DIR              ...kl1g09/OpenFOAM/OpenFOAM-2.2.2/wmake  yes  yes  yes
-------------------------------------------------------------------------------


Checking the OpenFOAM env variables set on the LD_LIBRARY_PATH...
-------------------------------------------------------------------------------
Environment_variable Set_to_file_or_directory                Valid Path Crit
-------------------------------------------------------------------------------
$FOAM_LIBBIN        ...-2.2.2/platforms/linux64GccDPOpt/lib  yes  yes  yes
$FOAM_SITE_LIBBIN    .../2.2.2/platforms/linux64GccDPOpt/lib  no        no
$FOAM_USER_LIBBIN    ...-2.2.2/platforms/linux64GccDPOpt/lib  yes  yes  no
$MPI_ARCH_PATH      ...2/platforms/linux64Gcc/openmpi-1.6.3  yes  yes  yes
-------------------------------------------------------------------------------


Third party software
-------------------------------------------------------------------------------
Software Version  Location
-------------------------------------------------------------------------------
flex              /usr/bin/flex                                           
gcc      4.8.1    /local/software/rh53/gcc/4.8.1/bin/gcc                 
gzip    1.3.5    /bin/gzip                                               
tar      1.15.1    /bin/tar                                               
icoFoam  2.2.2    ...M/OpenFOAM-2.2.2/platforms/linux64GccDPOpt/bin/icoFoam
-------------------------------------------------------------------------------


Summary
-------------------------------------------------------------------------------
Base configuration ok.
Critical systems ok.

Done

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

wyldckat October 27, 2013 16:34

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:
Code:

ulimit -n 1024
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

Artur October 27, 2013 17:45

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

As I try running
Code:

ulimit -n 1024
I get a message that says that I'm not allowed to do this. When I try just
Code:

ulimit -n
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

wyldckat October 28, 2013 03:45

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

Artur October 28, 2013 05:47

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

wyldckat October 28, 2013 17:51

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:
Code:

wmkdep
wmkdepend

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

Artur October 29, 2013 11:59

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


All times are GMT -4. The time now is 20:49.