Alex,
I am glad it is finally working. To answer your question, when using
Trilinos MPI is required. We just merged a fix that makes this clear:
https://github.com/dealii/dealii/pull/12381
Best,
Bruno
Le mer. 9 juin 2021 à 11:18, Alex Cumberworth
a écrit :
>
> Hello,
>
> I finally managed to g
Hello,
I finally managed to get everything compiled and running. To solve the last
issue, I started completely fresh with trilinos, and it no longer tried to
find the static version of sacado. I think there must have been something
leftover in the cmake files in the installation of trilinos fro
Alex,
I think this is a problem related to the cluster's OS. On Cray XC50, I had
to explicitly set the link type to dynamic before installation, because by
default Cray does a static link. I had to set
export XTPE_LINK_TYPE=dynamic
export CRAYPE_LINK_TYPE=dynamic
before the installation. You can
On 6/7/21 10:35 AM, Alex Cumberworth wrote:
make[2]: *** No rule to make target
'/home/ipausers/cumberworth/lib/libsacado.a', needed by
'lib/libdeal_II.g.so.9.3.0'. Stop.
make[1]: *** [CMakeFiles/Makefile2:3238: source/CMakeFiles/deal_II.g.dir/all]
Error 2
make: *** [Makefile:149: all] Erro
I have now run into another error, although I suspect it should be more
straightforward to solve:
make[2]: *** No rule to make target
'/home/ipausers/cumberworth/lib/libsacado.a', needed by
'lib/libdeal_II.g.so.9.3.0'. Stop.
make[1]: *** [CMakeFiles/Makefile2:3238:
source/CMakeFiles/deal_II.g
On 6/7/21 10:02 AM, Alex Cumberworth wrote:
The cause of this particular issue actually appears to be some symlinks to the
mpi include directory in my home directory. I am surprised that this was the
cause of the errors as they still point to the same mpi directory that cmake
finds. Once I remo
The cause of this particular issue actually appears to be some symlinks to
the mpi include directory in my home directory. I am surprised that this
was the cause of the errors as they still point to the same mpi directory
that cmake finds. Once I removed them the errors disappeared. While I am
On 6/7/21 8:41 AM, Alex Cumberworth wrote:
I noticed that I attached the error file for 9.2, and that the source of the
error in 9.3 is different. In 9.2, something goes wrong when one of the
bundled sundials files is compiled, while 9.3, it is when one of the bundled
arborx files is compiled.
Hi Daniel,
I have actually set
DEAL_II_WITH_SUNDIALS:BOOL=OFF
so I don't really understand why it is trying to compile with sundials.
Sundials is actually not installed on my system, so deal.ii must be using
the bundled version. I will try to compile sundials and see if that helps.
Best,
Alex
Alex,
it looks like Trilinos and SUNDIALS are using different MPI implementations
that are incompatible. There is not much we can do about this within
deal.II.
Can you try to reinstall SUNDIALS or Trilinos using the same MPI
implementation as the other one?
Best,
Daniel
Am Mo., 7. Juni 2021 um 0
Alex,
This is really strange. I've never seen that error before. Can you try
to install deal.II 9.3
https://github.com/dealii/dealii/releases/tag/v9.3.0 and see if you
get the same error?
Best,
Bruno
Le lun. 7 juin 2021 à 05:54, Alex Cumberworth
a écrit :
>
> Hello,
>
> I recompiled trilinos w
Hello,
I recompiled trilinos without tpetra to sidestep this error, but ended up
with another error involving epetra, and apparently epetra is minimal
module required for trilinos with deal.ii, so I cannot do the same
thing.The error:
[ 31%] Building CXX object
source/numerics/CMakeFiles/obj_
Hi Vachan,
Thanks for your response. This actually works. However, I still end up with
an incompatibility of the MPI configuration between the Trilinos library
and deal.ii. I ended up compiling Trilinos from source (12-4-1), but during
compilation of deal.ii, I have a new error:
In file includ
Hi Alex,
I previously ran into a lot of issues when I tried to install dealii on our
institute's cluster. The OS was different though and I had problems with
PETSc.
I don't know if this helps but this is the relevant section in
dealii-9.2.0/cmake/modules/FindTRILINOS.cmake file which searches for
Hello,
The file does exist and is readable. If I set a manual include flag it is
able to find it:
CMAKE_CXX_FLAGS_DEBUGRELEASE
-I/opt/ohpc/pub/libs/gnu9/openmpi4/trilinos/13.0.0/include
then it is able to get past this point. From the output in my previous
message, it seems that cmake is not
Alex,
I have also tried
cmake -DTRILINOS_DIR=/opt/ohpc/pub/libs/gnu9/openmpi4/trilinos/13.0.0 ..
It is also unable to find the epetra header file.
I can not tell why that would be so (but you should be able to find out by
searching for the place in CMakeFiles/CMakeErrors.log where it sho
Hello,
I have been working with the cluster system administrators, but we are
still having trouble with Trilinos. Trilinos is a package in the repository
of the distribution, and we have installed it and loaded the module. The
version is 13.0.0. It does seem to find trilinos, but for whatever r
On 5/27/21 4:25 AM, Alex Cumberworth wrote:
However, trilinos is loaded as a module, and even with the fresh configuration
it is unable to find the header. Even with
//Path to a file.
SACADO_CONFIG_H:FILEPATH=/opt/ohpc/pub/libs/gnu9/mpich/trilinos/13.0.0/include/Sacado.hpp
//Path to a file.
I am working on the cluster that is available at my research institute, so
I don't actually have root access. It is CentOS 8.3.2011 with openHPC. With
the weird stl header file issues, it seemed that the compiler module had
not been properly loaded, and then when I did properly load it, I didn't
On 5/26/21 11:17 AM, Alex Cumberworth wrote:
It seems that the issues stem from not setting the include directories
properly. Even with CPATH, C_INCLUDE_PATH, and CPLUS_INCLUDE_PATH set as I
mentioned in my previous response, I am running into errors. The compilation
proceeds for a while, but t
Alex,
How did you install your compiler? You should not need to set these
paths yourself.
Best,
Bruno
Le mer. 26 mai 2021 à 13:17, Alex Cumberworth
a écrit :
>
> It seems that the issues stem from not setting the include directories
> properly. Even with CPATH, C_INCLUDE_PATH, and CPLUS_INCLU
It seems that the issues stem from not setting the include directories
properly. Even with CPATH, C_INCLUDE_PATH, and CPLUS_INCLUDE_PATH set as I
mentioned in my previous response, I am running into errors. The
compilation proceeds for a while, but then at some point when cmath is
included, it
On 5/21/21 11:03 AM, Alex Cumberworth wrote:
I don't really see how this can be, as this version of the compiler fully
supports C++11. I also tried setting the flag DEAL_II_CXX_VERSION_FLAG, but
using valid standard specifiers just results in errors like "The supplied flag
"c++11" was not rec
Hello,
I am trying to compile deal.II, version 9.2, on CentOS 8.3.2011 (the last
version). I have gcc 9.3.0, which is relatively recent. However, when I run
cmake, I end up with the following message:
The current combination of compiler and C++ version flag is missing some
features of the C
24 matches
Mail list logo
