[userjjb]

I'm trying to build ESI OpenFOAM v2012 from source on a HPC cluster. I have my OpenFOAM and ThirdParty source/build folders on a local scratch disk (e.g. /scratch/OpenFOAM-v2012) on a compute node, but would like to install to a separate directory on the cluster's networked file server (e.g. /share/openfoam/v2012/OpenFOAM).

How do I specify a different directory to install to separate from where the build files are? I've seen both FOAM_INST_DIR and WM_PROJECT_INST_DIR mentioned, but these are unset in .../config.sh/unset and noted as outdated.

On the current build instructions for v2012 it mentions "foamInstall" in the bashrc, however there is no mention of it in there. Furthermore, looking in foamConfigurePaths it's listed as an obsolete option and will be ignored. There is no mention of what to do now that it is obsolete.

I also see mention of a "prefixDir" in .../config.sh/setup, but I don't think this is what I want.

Question 2: Is it safe to build in parallel with something like ./Allwmake -j 8? My colleague mentioned this may sometimes fail, but iterating through build issues and needing to wait 6 hours each time when using just 1 core is painful. Note that again this is building on a cluster with a networked file server. Building from /scratch seems to help some, but I'm not confident that wmake will behave robustly when writing to disk over a network.

Question 3: There is already a system build of Paraview 5.8.1 The build instructions etc. are a little hazy, but I should be able to forego building the Paraview in ThirdParty and use the system version right? I know that the custom one in ThirdParty has some additional functionality, but I don't think this will be needed. Do I need to provide a path to the system Paraview when doing the full build of OpenFOAM?

Thanks for any assistance/tips you can provide!

[olesen]

Originally Posted by userjjb

I'm trying to build ESI OpenFOAM v2012 from source on a HPC cluster. I have my OpenFOAM and ThirdParty source/build folders on a local scratch disk (e.g. /scratch/OpenFOAM-v2012) on a compute node, but would like to install to a separate directory on the cluster's networked file server (e.g. /share/openfoam/v2012/OpenFOAM).

How do I specify a different directory to install to separate from where the build files are? I've seen both FOAM_INST_DIR and WM_PROJECT_INST_DIR mentioned, but these are unset in .../config.sh/unset and noted as outdated.

On the current build instructions for v2012 it mentions "foamInstall" in the bashrc, however there is no mention of it in there. Furthermore, looking in foamConfigurePaths it's listed as an obsolete option and will be ignored. There is no mention of what to do now that it is obsolete.

I also see mention of a "prefixDir" in .../config.sh/setup, but I don't think this is what I want.

Question 2: Is it safe to build in parallel with something like ./Allwmake -j 8? My colleague mentioned this may sometimes fail, but iterating through build issues and needing to wait 6 hours each time when using just 1 core is painful. Note that again this is building on a cluster with a networked file server. Building from /scratch seems to help some, but I'm not confident that wmake will behave robustly when writing to disk over a network.

Question 3: There is already a system build of Paraview 5.8.1 The build instructions etc. are a little hazy, but I should be able to forego building the Paraview in ThirdParty and use the system version right? I know that the custom one in ThirdParty has some additional functionality, but I don't think this will be needed. Do I need to provide a path to the system Paraview when doing the full build of OpenFOAM?

Thanks for any assistance/tips you can provide!

You ask several questions, I'll try my best to answer most of them, but may miss something.
The web content is still being migrated to a new CMS, which means that some of the build/install instructions are partly out-of-date. Generally speaking the build-wiki
https://develop.openfoam.com/Develop...wikis/building
is the better place to start.
I do not expect any serious problems with using the '-j' to build in parallel. It is done all the time. There have been a few small glitches in the past in combination with using the '-q' (queuing) option. They are largely sorted, but may still be something odd there - perhaps this is where the reservation about parallel builds arises.
Regardless of building in serial or parallel, remember that you can always use the Allwmake repeatedly. Which means that if your build does happen to fail part way through, you can come back later and it will only rebuild the missed bits. One thing that some people do is the following:

./Allwmake -s -j -l -k   # pass 1 with "keep-going" (error tolerant)
./Allwmake -s -j -l       # pass 2 with fail on error

Since you can come back and build/rebuild successively, it is definitely advisable to build the first time without bothering with paraview/vtk bits. In general, you probably don't really need them anyhow:
https://develop.openfoam.com/Develop...raview-plugins
In fact, the entire visualization parts were split out and recombined to allow later building of various paraview/vtk combinations (serial, mpi, osmesa, etc) with an existing OpenFOAM installation. You could also use your system installation of paraview for building the plugins, provided that it has development headers (which it probably does not), but like the FAQ states, you are probably just fine without needing to build any plugins.
The installation directories for OpenFOAM are completely arbitrary. You can easily compile in one location and then copy elsewhere, without editing any files. You do need to preserve the directory structure, but can discard the 'build/' directory on the way (eg, with rsync --exclude 'build' ). If you want a wrapped version of doing this, take a look at the installation scripts:

bin/tools/install-dirs -help
bin/tools/install-platforms -help

They are split according to

• Simple installer to copy OpenFOAM non-binary directories.
• Simple installer to copy OpenFOAM binary bin/, lib/ (platforms) directories.

The parts within the foamConfigurePaths aremeant to be used before compilation, as a scriptable alternative to editing the various etc files.


BTW: if you are building on a cluster, you may find the spack recipes a good alternative. Otherwise, if you wish to get a bit trickier and are on a RedHat-derivative or openSUSE system, you can also grab the precompiled RPM packages. They should be relocatable, but haven't tested this for a while.
Let us know how you get on.