[deal.II] Re: configuration with LAPACK/BLAS fails
I fixed the failing gmsh test case. I am reporting it here, just in case
someone else faced the same problem. It turned out that the gmsh I was
using was linking to the blas library shipped with Ubuntu, but since my
manually installed openblas appeared first on my path, gmsh wasn't picking
up the right blas library. I ended up installing gmsh on my ubuntu machine
and had deal.ii use the manually installed gmsh library, instead. Now all
deal.ii tests pass
Thanks everyone for their suggestions and help
On Wednesday, July 3, 2019 at 1:46:21 PM UTC-4, Ahmad Shahba wrote:
>
> Thanks Jean-Paul and Bruno for your input
>
> *Regarding OpenBLAS:* I installed OpenBLAS, reconfigured PETSc (to use
> OpenBLAS). Using the following CMake invocation
>
> export PREFIX_PETSC_ARCH=$PETSC_DIR/$PETSC_ARCH
>
> cmake \
>-DDEAL_II_COMPONENT_DOCUMENTATION=OFF \
>-DGSL_DIR=$HOME/workspace/gsl \
>-DHDF5_DIR=$PREFIX_PETSC_ARCH \
>-DMETIS_DIR=$PREFIX_PETSC_ARCH \
>-DP4EST_DIR=$HOME/workspace/p4est-2.2/FAST \
>-DDEAL_II_WITH_P4EST=ON \
>-DPETSC_DIR=$PETSC_DIR \
>-DPETSC_ARCH=$PETSC_ARCH \
>-DSLEPC_DIR=$SLEPC_DIR \
>-DZLIB_DIR=$PREFIX_PETSC_ARCH \
>-DDEAL_II_WITH_LAPACK=ON \
>-DLAPACK_FOUND=true \
>-DLAPACK_LIBRARIES="/opt/OpenBLAS/lib/libopenblas.so" \
>-DLAPACK_LINKER_FLAGS="-lgfortran -lpthread -lm -ldl" \
>-DDEAL_II_WITH_MPI=ON \
>-DCMAKE_INSTALL_PREFIX=$installationPath \
>../
>
> Now I can successfully configure deal.ii and compile the library. I am
> running the post-installation tests by invoking
>
> make test
>
> I see that all the tests pass except for one related to *gmsh*. It
> produces an error
>
> This exception -- which is used in many places in the library -- usually
> indicates that some condition which the author of the code thought must be
> satisfied at a certain point in an algorithm, is not fulfilled. An example
> would be that the first part of an algorithm sorts elements of an array in
> ascending order, and a second part of the algorithm later encounters an
> element that is not larger than the previous one.
> There is usually not very much you can do if you encounter such an
> exception since it indicates an error in deal.II, not in your own program.
>
> I am going to post this issue as another question in the forum
>
> *Regarding LAPACK/BLAS in MKL: *It appears that I was missing one library
> (*libmkl_intel_lp64.so*). I reconfigured deal.ii using the following
> CMake command
>
> export PREFIX_PETSC_ARCH=$PETSC_DIR/$PETSC_ARCH
> cmake \
>-DDEAL_II_COMPONENT_DOCUMENTATION=OFF \
>-DGSL_DIR=$HOME/workspace/gsl \
>-DHDF5_DIR=$PREFIX_PETSC_ARCH \
>-DMETIS_DIR=$PREFIX_PETSC_ARCH \
>-DP4EST_DIR=$HOME/workspace/p4est-2.2/FAST \
>-DDEAL_II_WITH_P4EST=ON \
>-DPETSC_DIR=$PETSC_DIR \
>-DPETSC_ARCH=$PETSC_ARCH \
>-DSLEPC_DIR=$SLEPC_DIR \
>-DZLIB_DIR=$PREFIX_PETSC_ARCH \
>-DDEAL_II_WITH_LAPACK=ON \
>-DLAPACK_FOUND=true \
>-DLAPACK_LIBRARIES=
> "${MKLROOT}/lib/intel64/libmkl_blas95_lp64.a;${MKLROOT}/lib/intel64/libmkl_lapack95_lp64.a;${MKLROOT}/lib/intel64/libmkl_gf_lp64.a;${MKLROOT}/lib/intel64/libmkl_intel_lp64.so;${MKLROOT}/lib/intel64/libmkl_sequential.so;${MKLROOT}/lib/intel64/libmkl_core.so"
>
> \
>-DLAPACK_LINKER_FLAGS="-lgfortran -lpthread -lm -ldl" \
>-DDEAL_II_WITH_BLAS=ON \
>-DBLAS_FOUND=true \
>-DBLAS_LIBRARIES=
> "${MKLROOT}/lib/intel64/libmkl_blas95_lp64.a;${MKLROOT}/lib/intel64/libmkl_lapack95_lp64.a;${MKLROOT}/lib/intel64/libmkl_gf_lp64.a;${MKLROOT}/lib/intel64/libmkl_intel_lp64.so;${MKLROOT}/lib/intel64/libmkl_sequential.so;${MKLROOT}/lib/intel64/libmkl_core.so"
>
> \
>-DBLAS_LINKER_FLAGS="-lgfortran -lpthread -lm -ldl" \
>-DSCALAPACK_DIR==$PREFIX_PETSC_ARCH \
>-DDEAL_II_WITH_MPI=ON \
>-DCMAKE_INSTALL_PREFIX=$installationPath \
>../
>
> CMake still fails to locate LAPACK/BLAS. The *CMakeError.Log* file is
> attached. Bruno's comment and previous post
> made me
> think of something. The LAPACK and BLAS libraries provided in MKL are
> static .a libraries. Could this be the reason why CMake cannot locate
> them?
>
>
> On Wednesday, July 3, 2019 at 9:49:40 AM UTC-4, Bruno Turcksin wrote:
>>
>> Ahmad,
>>
>> The first thing is that you should not try to set the flags yourself. You
>> should let CMake take care of that. You should just set the paths (BLAS_DIR
>> and LAPACK_DIR) and let CMake do the rest. The second thing is that I am
>> not sure sure that you are using the right MKL libraries. You can go here
>>
>> to check what you need.
>>
>> Best,
>>
>> Bruno
>>
>> On Tuesday, July 2, 2019 at 7:18:40 PM UTC-4, Ahmad Shahba wrote:
>>>
>>> I am trying to compile deal.ii (version 9.1.1) on my Ubuntu laptop with
>>> gcc compilers. I have tried two methods to configure deal.ii with
>>>
[deal.II] deal.II Newsletter #86
Hello everyone! This is deal.II newsletter #86. It automatically reports recently merged features and discussions about the deal.II finite element library. ## Below you find a list of recently proposed or merged features: #8356: std::strings stores the filename, not the file handler (proposed by kostyfisik) https://github.com/dealii/dealii/pull/8356 #8355: Fix documentation of HermiteLikeInterpolation (proposed by kronbichler) https://github.com/dealii/dealii/pull/8355 #8353: Add a space between sentences in ExcNumberNotFinite (proposed by GrahamBenHarper; merged) https://github.com/dealii/dealii/pull/8353 #8352: Add functionality to support multiple mappings per element in FE_PolyTensor (proposed by GrahamBenHarper) https://github.com/dealii/dealii/pull/8352 #8350: Remove int2type and bool2type. (proposed by drwells; merged) https://github.com/dealii/dealii/pull/8350 #8349: Add notes on packaging for distributions. (proposed by drwells) https://github.com/dealii/dealii/pull/8349 #8348: Extend MatrixFree with a second template argument to control vectorization (proposed by peterrum) https://github.com/dealii/dealii/pull/8348 #8346: Annotate Point members usable in CUDA kernels (proposed by masterleinad) https://github.com/dealii/dealii/pull/8346 #8345: Add maxwell equations tutorial (proposed by dangars) https://github.com/dealii/dealii/pull/8345 #8344: CMake: Update CTest configuration (proposed by tamiko; merged) https://github.com/dealii/dealii/pull/8344 #8343: Fix compilation of loop.h with some versions of clang. (proposed by luca-heltai; merged) https://github.com/dealii/dealii/pull/8343 #8342: Extend VectorizedArray with a second template argument to control vector length (proposed by peterrum) https://github.com/dealii/dealii/pull/8342 #8341: hp::Refinement: Error prediction. (proposed by marcfehling) https://github.com/dealii/dealii/pull/8341 #8340: Fix include to intrinsics (proposed by kronbichler; merged) https://github.com/dealii/dealii/pull/8340 #8339: Fix a bug in print_as_numpy_arrays (proposed by Rombur; merged) https://github.com/dealii/dealii/pull/8339 #8338: CUDA device annotations for Tensor (proposed by masterleinad) https://github.com/dealii/dealii/pull/8338 #8337: Fix a bug in CUDA matrix-free with adapted mesh when using Volta (proposed by Rombur; merged) https://github.com/dealii/dealii/pull/8337 #8336: Add a couple of comments to functions in utilities.cc. (proposed by bangerth; merged) https://github.com/dealii/dealii/pull/8336 #8325: Introduced hp::Refinement namespace. (proposed by marcfehling; merged) https://github.com/dealii/dealii/pull/8325 ## And this is a list of recently opened or closed discussions: #8354: Pass MatrixFree::AdditionalData by const reference (opened) https://github.com/dealii/dealii/issues/8354 #8351: FE_PolyTensor does not support mapping_covariant for shape functions (opened) https://github.com/dealii/dealii/issues/8351 #8347: CUDAWrappers::MatrixFree doesn't provide initialize_dof_vector (opened) https://github.com/dealii/dealii/issues/8347 #8273: C2 continuity (closed) https://github.com/dealii/dealii/issues/8273 A list of all major changes since the last release can be found at https://www.dealii.org/developer/doxygen/deal.II/changes_after_8_5_0.html. Thanks for being part of the community! Let us know about questions, problems, bugs or just share your experience by writing to dealii@googlegroups.com, or by opening issues or pull requests at https://www.github.com/dealii/dealii. Additional information can be found at https://www.dealii.org/. -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/5d2392c6.1c69fb81.6ed77.6ac3SMTPIN_ADDED_MISSING%40gmr-mx.google.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Re: Eigenproblem and creating a preconditioner out of a linear operator, Eigensolver Selection
Hi Andreas, On Sunday, July 7, 2019 at 4:26:39 PM UTC+2, Andreas Hegendörfer wrote: > > I also tried a spectral transformation with the Arpack solver with the > same result as without spectral transformation. I am interested in the > smallest real eigenvalues. I know from previous calculations with the > Krylov Schur solver form SLEPc that using or not using a spectral > transformation makes a very big difference here. > Yes, using a spectral transformation makes a huge difference if your eigenvalues are from the interior of the spectrum, although if you are interested in the smallest real eigenvalue, the difference might not be that important. The drawback of an spectral transformation is that you have to use a direct solver. You can use an iterative solver with an spectral transformation for very large problems. However, using an iterative linear solver with an spectral transformation makes the overall solution process less robust. Although the direct solver approach may seem too costly, the factorization is only carried out at the beginning of the eigenvalue calculation and this cost is amortized in each subsequent application of the operator. I think that the drawback of an iterative solver is that it requires lot of memory and does not scale very well. This figure can give you an idea of the scalability of MUMPS (direct parallel solver). https://www.researchgate.net/figure/Strong-scalability-of-an-iterative-solver-with-different-preconditioners-versus-MUMPS_fig2_282172435 > I do not want to use SLEPc here because I think handling the PETSc > Matrices and vectors is too uncomfortable for my application. Am I right at > this point? What do you think about using SLEPc here? > I'm writing a tutorial about how to calculate the eigenmodes of an electromagnetic cavity. So far, I've written the code, I'm writing now the documentation. You can take a look. You can find the code in this pull request: https://github.com/dealii/dealii/pull/8345 The tutorial uses MPI, and SLEPc with std::complex. The eigenvalues in this tutorial are from the interior of the spectrum, therefore I have to use an spectral transformation with a direct solver. Note that PETSc has to be compiled with MUMPS if you want to run that tutorial. Best, Daniel -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/5399942a-80d6-43b3-a2ea-7236e19e4842%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
