Package Base Details: openfoam

Git Clone URL: https://aur.archlinux.org/openfoam.git (read-only, click to copy)
Submitter: None
Maintainer: petronny (AutoUpdateBot)
Last Packager: AutoUpdateBot
Votes: 60
Popularity: 1.97
First Submitted: 2009-07-02 09:16 (UTC)
Last Updated: 2023-09-25 09:53 (UTC)

Packages (1)

Pinned Comments

petronny commented on 2020-08-04 08:36 (UTC) (edited on 2023-04-14 08:48 (UTC) by petronny)

Pre-built binaries of this package and its dependencies can be found in the arch4edu repository.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 27 Next › Last »

espinozahg commented on 2020-04-26 18:14 (UTC)

Hi, what about latest patch of v7 https://github.com/OpenFOAM/OpenFOAM-7/archive/20200120.tar.gz

leibniz commented on 2020-04-19 18:26 (UTC)

@Xwang if it is still relevant, in the appropriate directory you could go with: touch cavity.foam && paraview $_ &

Xwang commented on 2020-03-01 15:27 (UTC) (edited on 2020-03-01 23:37 (UTC) by Xwang)

I have the following issue using paraFOAM.

When I try to follow the cavity test case as in the OpenFOAm user guide I get the following message:


paraFoam &
[1] 285428
[andreak@n752vx cavity]$ FATAL ERROR: The official reader module for OpenFOAM data does not exist on
your system.  This means that the version of ParaView you are using was not
compiled with OpenFOAM, or distributed with a packaged version of OpenFOAM.

For information on packaged versions of OpenFOAM/ParaView and compilation of
OpenFOAM/ParaView, see https://openfoam.org/download

Alternatively, you might be able to view your OpenFOAM data with the reader
module provided with ParaView by running:
    paraFoam -builtin


[1]+  Uscita 1                paraFoam

So I try to use the -builtin option and I get:


[andreak@n752vx cavity]$ paraFoam -builtin &
[1] 285430
[andreak@n752vx cavity]$ Created temporary 'cavity.foam'
Cannot open data file " --mesa "

Do you know how to solve it?

It seems (but I'm not sure) that this library is missing: libPVFoamReader_SM.so

disc-kuraudo commented on 2020-02-18 09:45 (UTC) (edited on 2020-02-18 09:57 (UTC) by disc-kuraudo)

Yeah there's no need to split-package this as it will be built on the machine it will run on anyway, in contrast to tensorflow/tensorflow-opt that is in the main repositories and the binaries are distributed.

For people that don't want to waste time and resources/energy and set their /etc/makepkg.conf accordingly this change would improve the OpenFOAM performance.

For people that left the /etc/makepkg.conf untouched basically nothing changes (even the -O2 gets overridden by a -O3 that is already there in the cOpt/c++Opt file as it comes afterwards).

lahwaacz commented on 2020-02-18 09:03 (UTC)

Using flags specified in makepkg.conf is not actually about enabling optimizations by itself, but it allows users to configure whatever flags they want. For openfoam-opt you would have to actually force some specific flags, but that's unnecessary for a source-based repo like the AUR - users can change the pkgname themselves if they need.

petronny commented on 2020-02-18 08:55 (UTC) (edited on 2020-02-18 08:56 (UTC) by petronny)

So is the difference like the difference between tensorflow and tensorflow-opt? The 2nd one enables more instructions like AVX/AVX2.

Should I add an package called openfoam-opt like that?

disc-kuraudo commented on 2020-02-18 07:57 (UTC)

The default CFLAGS/CXXFLAGS set in the /etc/makepkg.conf are currently

-march=x86-64 -mtune=generic -O2 -pipe -fno-plt

With this it will sort of run on every x86-64 (amd64) machine.

Usually build tools like GNU Autotools, CMake etc. will automatically include the values set in the environment variables like that in the build process. OpenFOAM with this special WMake build tool apparently doesn't do so.

For my Desktop PC I changed the makepkg.conf CFLAGS/CXXFLAGS line to

-march=znver2 -mtune=znver2 -O3 -pipe -fno-plt

so it enables all the AVX/AVX2/FMA3 SIMD instructions when building packages which is for my Zen 2 AMD CPU and that will improve the performance for scientific computations a lot.

Can check and see what the default flags for compilation with GCC are with

gcc -Q --help=target | grep "march\|mtune\|sse\|avx\|fma"

It basically sets back to very basic Pentium 4 era SSE2 SIMD instructions and use none the instruction set extensions "recent" CPUs have implemented.

https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html

petronny commented on 2020-02-18 05:13 (UTC)

@daren Will the binaries be still compatible with old machines after applying your changes?

disc-kuraudo commented on 2020-02-12 13:17 (UTC) (edited on 2020-02-12 14:00 (UTC) by disc-kuraudo)

The CXXFLAGS environment variable set in makepkg.conf don't seem to be picked up in the build system.

How could these be used so it doesn't create binaries that only contain 20 year old amd64 instructions? There's no -march flag whatsoever in the compile commands.

Edit: Setting this in the build() function before building works.

  # Apply CFLAGS and CXXFLAGS to compile options
  sed -e "s/\(cOPT.*=\)/\1 ${CFLAGS}/g" \
      -i ${srcdir}/${_distpkgname}-${pkgver}/wmake/rules/linux64Gcc/cOpt
  sed -e "s/\(c++OPT.*=\)/\1 ${CXXFLAGS}/g" \
      -i ${srcdir}/${_distpkgname}-${pkgver}/wmake/rules/linux64Gcc/c++Opt

petronny commented on 2019-08-28 04:55 (UTC)

@ng0177 Well, we can't help you if there is no log or output. I have no idea what the MPI error is.