Build runs on a single CPU - not obvious how to use multiple CPUs

This page says that WM_NCOMPPROCS should specify the number of CPUs, but WM_NCOMPPROCS is never mentioned in the source tree.

Google doesn't know this either.

Multi-CPU option works by itself for almost all other projects.

please see the section "Compile OpenFOAM faster". note that the valid versions in the link given by yourself was stated as 1.4.x.

please reopen the ticket if the issue remains relevant.

closed

"Compile OpenFOAM faster" says that './Allwmake -j' should build on all cores but it still builds on a single CPU.

It says that it builds on 8 cores, but in fact it still uses only one core.

I don't experience any of these reported issues. Could you report the issue in a more explicit way, please?

@kuti - he is working on FreeBSD not Linux, so I wouldn't be too surprised about somethings odd. Do you have an installation of FreeBSD about, or using container image?

./Allwmake -j first prints:

Compiling enabled on 8 cores

but then only one compiler process runs at any given time.

This doesn't happen with any other project.

OS: FreeBSD 13.1

mentioned in issue #2518 (closed)

Hi @yurivict - this is still totally weird. Any luck with "wmake -j N" or "./Allwmake -j N" at all?

Is there something different about the make used there? I'm guessing that it is not "GNU Make"

Any luck with "wmake -j N" or "./Allwmake -j N" at all?

./Allwmake -j N says that it runs on N cores but then only one compiler process runs at any given time.

Is there something different about the make used there? I'm guessing that it is not "GNU Make"

GNU make (gmake) is placed in path as a makecommand for the duration of the build by the ports framework.

$ gmake -v
GNU Make 4.3
Built for amd64-portbld-freebsd13.0
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Really, really weird. We are however calling make and not gmake internally, so maybe you are still getting a different make somehow?

Really, really weird. We are however calling make and not gmake internally, so maybe you are still getting a different make somehow?

It starts Allwmake with make symlinked to gmake in PATH. I checked, the running instance of make has a binary image /usr/local/bin/gmake.

However, gmake is run without -j N flag by Allwmake for some reason.

It continues to be pretty weird. What is the fastest/easiest way for a FreeBSD noob to get started? Not saying that I can tackle it right away or anything, but I am interested in seeing OpenFOAM also running on FreeBSD too.

@yurivict I encountered something similar on archlinux actually. What solved the issue for me was the -q flag. i.e. running ./Allwmake -j -q did the trick. I thing something with queuing up other files to compile at the same time is important in the Allwmake command to utilize all cores.

Also nice to see you here as well!

@mark can you comment on this?

Should the build parallelization documentation be updated to reflect the -q observations faced on archlinux and freebsd? Is there a distro that does not need the -q flag for all core utilization that you know of which I can test on my own?

The -q is probably some other side-effect. We compile all of the time on opensuse/fedora/redhat/debian/ubuntu (ie, all of our regular builds) without using the -q option at all.

So the question is probably why Arch and FreeBSD behave differently.

reopened

I have a pre-written answer, copy-pasting it here:

---

Is there an easy way to test under FreeBSD?

1. Install the FreeBSD VM image into VirtualBox.
2. Boot FreeBSD
3. Install git: pkg install git
4. Check out the ports tree: git clone https://git.FreeBSD.org/ports.git /usr/ports
5. cd /usr/ports/graphics/pcl-pointclouds # replace with the port you are interested in
6. Install dependencies: pkg install -A make missing
7. Build: make
8. Run tests: make test

---

This is for some existing port.

However, the port science/openfoam isn't committed yet since I am still working on it.

@acxz Likewise, very nice to talk to you!

./Allwmake -j -q seems to build in parallel, but then it prints errors like these:

clang++: error: no such file or directory: '/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/build/linux64ClangDPInt32Opt/modules/cfmesh/meshLibrary/utilities/octrees/meshOctree/refinementControls/objectRefinement/hollowConeRefinement.o'
clang++: error: no such file or directory: '/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/build/linux64ClangDPInt32Opt/modules/cfmesh/meshLibrary/utilities/triSurfaceTools/triSurface2DCheck/triSurface2DCheck.o'
clang++: error: no such file or directory: '/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/build/linux64ClangDPInt32Opt/modules/cfmesh/meshLibrary/utilities/triSurfaceTools/triSurfaceChecks/triSurfaceChecks.o'
clang++: error: no such file or directory: '/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/build/linux64ClangDPInt32Opt/modules/cfmesh/meshLibrary/utilities/triSurfaceTools/triSurfaceCleanupDuplicates/triSurfaceCleanupDuplicates.o'
clang++: error: no such file or directory: '/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/build/linux64ClangDPInt32Opt/modules/cfmesh/meshLibrary/utilities/triSurfaceTools/triSurfaceCleanupDuplicates/triSurfaceCleanupDuplicatesFunctions.o'
clang++: error: no such file or directory: '/disk-samsung/freebsd-ports/science/openfoam/work/OpenFOAM-v2112/build/linux64ClangDPInt32Opt/modules/cfmesh/meshLibrary/utilities/triSurfaceTools/triSurfaceCleanupDuplicateTriangles/triSurfaceCleanupDuplicateTriangles.o'

Please consider anything under modules/ as purely optional. If you want, can either compile with at the top-level with "./Allwmake -prefix=none", move the modules/ directory elsewhere, or edit the modules/Allwmake to simply "exit 0" as its first thing.

This will let you concentrate on the core problems of OpenFOAM itself.

added community label

I wonder if this is some weird bug only seen with clang++? Can you try with gcc?