[Time4Tea]

Hi, I am trying to compile the pisoFoam application (following the example given here) on OpenFOAM 6, on a shared Linux system that I have a user account on (but do not have admin rights to).

I have copied the pisoFoam source folder to a personal directory that I have write access to. I do not have write access to the main OpenFOAM project/installation directory on the shared system.

I have set $FOAM_USER_APPBIN to point to a personal directory that I have write access to, and $LIB_SRC is set correctly. However, when I type wmake in the pisoFoam folder, I get the following:

$ wmake
wmakeLnIncludeAll: running wmakeLnInclude on dependent libraries:
    mkdir: cannot create directory '$WM_PROJECT_DIR/src/OSspecific//lnInclude': Permission denied
wmakeLnInclude error: failed to create include directory $WM_PROJECT_DIR/src/OSspecific//lnInclude

(I have substituted part of the path above with '$WM_PROJECT_DIR', so as not to divulge the folder structure of the shared system)

So, clearly it is throwing the error because it is trying to create a directory in the main OF installation tree, which I don't have write access to. However, why is it trying to do this? All I want to do is read the installed OF headers and link to the installed libraries, so I can compile and run the application in the area I do have write access to. I have no desire to re-compile or update any of the installed OF libraries.

Is there some way I can compile pisoFoam, without the build script trying to write to installed OF directories, which I haven't got write access to?

[alexeym]

Hi,

It looks like wmake tries to recompile OpenFOAM itself. Are you sure OpenFOAM-6 is compiled? Keep in mind compilation flags (i.e. Opt, Prof, size of label type, etc). Is there $WM_PROJECT_DIR/src/OSspecific/lnInclude folder?

[Time4Tea]

@alexeym: yes, OpenFOAM definitely seems to be compiled. All of the dynamic libraries are present in $FOAM_LIBBIN and if I do which pisoFoam, which icoFoam etc. the application binaries are present.


There is no $WM_PROJECT_DIR/src/OSspecific/lnInclude folder though, no.

[alexeym]

Hi,

My second guess was: OpenFOAM(R) was installed from binary package (so there is no compilation folders) but I have checked and at least Foundation packages lnInclude folders in their package.

Unfortunately include flags with $(LIB_SRC)/OpenFOAM/lnInclude and $(LIB_SRC)/OSspecific/POSIX/lnInclude are automatically added by wmake, so you wont be able to proceed without them.

Maybe you can ask to recompile OpenFOAM? Or al least run Allwmake script to recreate lnInclude folders.

[Time4Tea]

@alexeym: $(LIB_SRC)/OSspecific/POSIX/lnInclude does exist. It's $(LIB_SRC)/OSspecific//lnInclude that it's trying to create. Actually, the fact there are two slashes in that path seems a little odd. Perhaps there is a wmake-related environment variable that relates to the OS, which is not set (and is therefore returning a blank)?



If there is no way to modify the build script, then I think that is a shame, because it seems to make it very difficult to compile OF applications on shared systems. What I might have to do is try copying the entire OF installation tree to my own directory (depending on how large it is).

[alexeym]

You are right, there is WM_OSTYPE environment variable, which normally is set to POSIX (at least on Linux and macOS). In your case it is empty for some reason.

If you would like to discuss wmake idiosyncrasies, it would be better to start new thread (or do it directly in Foundation's bug-tracker).

[Time4Tea]

@alexeym: yes, I had a look through the $WM_PROJECT_DIR/etc/bashrc script and saw that variable. For some reason, it wasn't set and setting it to 'POSIX' does seem to resolve the error I was having. Thanks for your help!

[Time4Tea]

So, setting the WM_OSTYPE variable resolved the error I was getting initially; however, I am now getting the following error when I try to compile pisoFoam:

Compiling enabled on 2 cores
icpc -std=c++11 -fp-trap=common -fp-model precise -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_ -DWM_LABEL_SIZE= -Wall -Wextra -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -diag-disable 327,654,1125,1292,2289,2304,11062,11074,11076 -O3  -DNoRepository -I($LIB_SRC)/TurbulenceModels/turbulenceModels/lnInclude -I($LIB_SRC)/TurbulenceModels/incompressible/lnInclude -I($LIB_SRC)/transportModels -I($LIB_SRC)/transportModels/incompressible/singlePhaseTransportModel -I($LIB_SRC)/finiteVolume/lnInclude -I($LIB_SRC)/meshTools/lnInclude -I($LIB_SRC)/sampling/lnInclude -IlnInclude -I. -I($LIB_SRC)/OpenFOAM/lnInclude -I($LIB_SRC)/OSspecific/POSIX/lnInclude   -fPIC -c pisoFoam.C -o Make/linux64IccDPInt32Opt/pisoFoam.o
In file included from ($LIB_SRC)/OpenFOAM/lnInclude/labelList.H(47),
                 from ($LIB_SRC)/OpenFOAM/lnInclude/UPstream.H(42),
                 from ($LIB_SRC)/OpenFOAM/lnInclude/Pstream.H(42),
                 from ($LIB_SRC)/OpenFOAM/lnInclude/parRun.H(35),
                 from ($LIB_SRC)/finiteVolume/lnInclude/fvCFD.H(4),
                 from pisoFoam.C(37):
($LIB_SRC)/OpenFOAM/lnInclude/label.H(47): error: expected an expression
  #if WM_LABEL_SIZE != 32 && WM_LABEL_SIZE != 64
                    ^

Do you have any idea what might be causing this? It seems to be a fairly basic preprocessor #if statement, so I have no idea why it is not recognizing the '!=' expression.

[Time4Tea]

Hmm ... I set WM_LABEL_SIZE=32 and that error went away, but now I'm getting another one:

($LIB_SRC)/OpenFOAM/lnInclude/scalar.H(101): error: #error directive: "Precision not set, please set either WM_SP, WM_DP or WM_LP"
      #error "Precision not set, please set either WM_SP, WM_DP or WM_LP"
       ^

It seems there are several environment variables that have not been set properly. I'll have to look into this - I did source the bashrc file, so perhaps some of the variables are not set correctly for this system.

[alexeym]

Your WM_LABEL_SIZE environment variable is empty. The is why compiler flag looks like:

-DWM_LABEL_SIZE=

it should be 32 or 64, so the flag becomes -DWM_LABEL_SIZE=32 (or -DWM_LABEL_SIZE=64).

The next error will be caused by WM_PRECISION_OPTION environment variable being empty. Due to this, compiler flag looks like:

-DWM_

usually value is DP and the flag looks like -DWM_DP.

[Time4Tea]

Awesome - I set those variables and it compiled fine. Thanks very much for your help @alexeym, I really appreciate it!