[deal.II] Re: error during installation with spack on CentOS7

[Denis Davydov]

Hi Alberto,

Try reporting issue on Spack Github and ping @balay .

Denis.

On Friday, October 4, 2019 at 12:50:24 PM UTC+2, Alberto Salvadori wrote:
>
> Dear community
>
> I apologize for this too long bothering on  installing deal.ii on a linux 
> machine equipped with CentOS7. I am having quite a large amount of issues, 
> perhaps related to the gcc compiler(?). 
> The very last, which I was unable to solve up to now, relates to slepc . I 
> wonder if any of you had a similar problem and in case could address its 
> solution.
>
> Here is the outcome of installation via spack:
>
> *==>* *Installing* *slepc*
>
> *==>* Searching for binary cache of slepc
>
> *==>* Warning: No Spack mirrors are currently configured
>
> *==>* No binary for slepc found: installing from source
>
> *==>* Fetching http://slepc.upv.es/download/distrib/slepc-3.12.0.tar.gz
>
>  
> 100.0%
>
> *==>* Staging archive: 
> /tmp/deal.ii/spack-stage/slepc-3.12.0-5md6u45rynyaqtcta4e5dmecqhkp2jkr/slepc-3.12.0.tar.gz
>
> *==>* Created stage in 
> /tmp/deal.ii/spack-stage/slepc-3.12.0-5md6u45rynyaqtcta4e5dmecqhkp2jkr
>
> *==>* No patches needed for slepc
>
> *==>* Building slepc [Package]
>
> *==>* Executing phase: 'install'
>
> *==>* Error: ProcessError: Command exited with status 1:
>
> './configure' 
> '--prefix=/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/slepc-3.12.0-5md6u45rynyaqtcta4e5dmecqhkp2jkr'
>  
> '--with-arpack-dir=/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/arpack-ng-3.7.0-i5fx7mowpxx7acbasidsfc4r3owcd2vx/lib'
>  
> '--with-arpack-flags=-lparpack,-larpack'
>
> See build log for details:
>
>   
> /tmp/deal.ii/spack-stage/slepc-3.12.0-5md6u45rynyaqtcta4e5dmecqhkp2jkr/spack-build-out.txt
>
>
> and the log (s):
>
> ==> Executing phase: 'install'
>
> ==> [2019-10-03-20:48:03.194513] './configure' 
> '--prefix=/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/slepc-3.12.0-5md6u45rynyaqtcta4e5dmecqhkp2jkr'
>  
> '--with-arpack-dir=/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/arpack-ng-3.7.0-i5fx7mowpxx7acbasidsfc4r3owcd2vx/lib'
>  
> '--with-arpack-flags=-lparpack,-larpack'
>
> Checking environment... done
>
> Checking PETSc installation... 
>
> ERROR: Unable to link with PETSc
>
> ERROR: See "installed-arch-linux2-c-opt/lib/slepc/conf/configure.log" file 
> for details
>
>
>
> 
>
> Starting Configure Run at Thu Oct  3 20:48:03 2019
>
> Configure Options: 
> --prefix=/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/slepc-3.12.0-5md6u45rynyaqtcta4e5dmecqhkp2jkr
>  
> --with-arpack-dir=/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/arpack-ng-3.7.0-i5fx7mowpxx7acbasidsfc4r3owcd2vx/lib
>  
> --with-arpack-flags=-lparpack,-larpack
>
> Working directory: 
> /tmp/deal.ii/spack-stage/slepc-3.12.0-5md6u45rynyaqtcta4e5dmecqhkp2jkr/spack-src
>
> Python version:
>
> 2.7.16 (default, Oct  3 2019, 20:40:41) 
>
> [GCC 9.2.0]
>
> make: /usr/bin/gmake
>
> PETSc source directory: 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/petsc-3.12.0-7b3mdm63ap32riorneym2mtcmwjlb63s
>
> PETSc install directory: 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/petsc-3.12.0-7b3mdm63ap32riorneym2mtcmwjlb63s
>
> PETSc version: 3.12.0
>
> SLEPc source directory: 
> /tmp/deal.ii/spack-stage/slepc-3.12.0-5md6u45rynyaqtcta4e5dmecqhkp2jkr/spack-src
>
> SLEPc install directory: 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/slepc-3.12.0-5md6u45rynyaqtcta4e5dmecqhkp2jkr
>
> SLEPc version: 3.12.0
>
>
> 
>
> Checking PETSc installation...
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
>
> Running command:
>
> cd /tmp/slepc-7TxU8j;/usr/bin/gmake checklink TESTFLAGS=""
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
>
> #include "petscsnes.h"
>
> int main() {
>
> Vec v; Mat m; KSP k;
>
> PetscInitializeNoArguments();
>
> VecCreate(PETSC_COMM_WORLD,);
>
> MatCreate(PETSC_COMM_WORLD,);
>
> KSPCreate(PETSC_COMM_WORLD,);
>
> return 0;
>
> }
>
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/openmpi-3.1.4-4lzhe2gtz3nzhffn6efu2fzgochphcix/bin/mpicc
>  
> -o checklink.o -c -fPIC   
> -I/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/petsc-3.12.0-7b3mdm63ap32riorneym2mtcmwjlb63s/include
>  
> -I/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/hypre-2.18.0-dbexk2cnwvnsjd5fm6ltw7o7q66ik3hy/include
>  
> -I/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/superlu-dist-6.1.1-stsykz4xojdqtlnjavms2opkppopzush/include
>  
> -I/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/hdf5-1.10.5-lt5jyi3ix6dbrbblku7ygutgek7wg5w2/include
>  
> 

Re: [deal.II] Re: error during installation with spack on CentOS7

[Denis Davydov]

Great, happy to hear you sorted this out by tweaking compilers.yaml 
settings.

On Friday, October 4, 2019 at 12:38:20 PM UTC+2, Alberto Salvadori wrote:
>
> Hi Denis
>
> thanks for your note. I figured out that by adding the path in the 
> compilers.yaml file, in this way
>
> - compiler:
>
> environment: 
>
>   append-path:
>
> LD_LIBRARY_PATH: /usr/local/lib64
>
> extra_rpaths: []
>
> flags: {}
>
> modules: []
>
> operating_system: centos7
>
> paths:
>
>   cc: /usr/local/bin/gcc
>
>   cxx: /usr/local/bin/g++
>
>   f77: /usr/local/bin/gfortran
>
>   fc: /usr/local/bin/gfortran
>
> spec: gcc@9.2.0
>
>     target: x86_64
>
> sorts out the issue.
>
>
> Il giorno mercoledì 2 ottobre 2019 19:26:06 UTC+2, Denis Davydov ha 
> scritto:
>>
>> Hi Alberto,
>>
>> Looks like the issue is known to Spack community: 
>> https://github.com/spack/spack/issues/11224 where there is also a 
>> possible source of the problem you can try as a fix (un-do on-line PR).
>>
>> Regards,
>> Denis.
>>
>> On Wednesday, October 2, 2019 at 3:14:46 PM UTC+2, Bruno Turcksin wrote:
>>>
>>> Alberto, 
>>>
>>> So what happens is that spack is using gcc 9.2 like you want but it 
>>> usess the libstdc++ from gcc 4.8.5 I usually spack to install a new 
>>> compiler and my compilers.yaml looks like your *but* I have the path 
>>> to the correct libstdc++ in my LD_LIBRARY_PATH when I load the module. 
>>> So I guess you need to add that path somewhere in your compilers.yaml 
>>>
>>> Best, 
>>>
>>> Bruno 
>>>
>>> Le mer. 2 oct. 2019 à 08:51, Alberto Salvadori 
>>>  a écrit : 
>>> > 
>>> > Thank you, Bruno. In fact, my aim was to use my system compiler. 
>>> > Here is my  .spack/linux/packages.yaml: 
>>> > 
>>> > packages: 
>>> > 
>>> >   all: 
>>> > 
>>> > compiler: [gcc] 
>>> > 
>>> > providers: 
>>> > 
>>> >   mpi: [openmpi] 
>>> > 
>>> >   openmpi: 
>>> > 
>>> > version: [3.1.4] 
>>> > 
>>> > paths: 
>>> > 
>>> >   openmpi@3.1.4%gcc@9.2.0: /usr/local/ 
>>> > 
>>> > buildable: False 
>>> > 
>>> >   perl: 
>>> > 
>>> > paths: 
>>> > 
>>> >   perl@5.16.3%gcc@9.2.0: /usr 
>>> > 
>>> >   cmake: 
>>> > 
>>> > version: [3.15.3] 
>>> > 
>>> > paths: 
>>> > 
>>> >   cmake@3.15.3%gcc@9.2.0: /usr/local/ 
>>> > 
>>> >   hdf5: 
>>> > 
>>> > version: [1.8.12] 
>>> > 
>>> > paths: 
>>> > 
>>> >   hdf5@1.8.12%gcc@9.2.0: /usr 
>>> > 
>>> > variants: +hl+fortran 
>>> > 
>>> >   netcdf: 
>>> > 
>>> > version: [7.2.0] 
>>> > 
>>> > paths: 
>>> > 
>>> >  netcdf@7.2.0%gcc@9.2.0: /usr 
>>> > 
>>> >   netcdf-cxx: 
>>> > 
>>> > version: [4.2.8] 
>>> > 
>>> > paths: 
>>> > 
>>> >  netcdf-cxx@4.2.8%gcc@9.2.0: /usr 
>>> > 
>>> >   dealii: 
>>> > 
>>> > variants: +optflags~python 
>>> > 
>>> > 
>>> > Shall I perhaps add something to the compiler flag (paths or so)? 
>>> > Here is also my  .spack/linux/compilers.yaml 
>>> > 
>>> > compilers: 
>>> > 
>>> > - compiler: 
>>> > 
>>> > environment: {} 
>>> > 
>>> > extra_rpaths: [] 
>>> > 
>>> > flags: {} 
>>> > 
>>> > modules: [] 
>>> > 
>>> > operating_system: centos7 
>>> > 
>>> > paths: 
>>> > 
>>> >   cc: /usr/bin/gcc 
>>> > 
>>> >   cxx: /usr/bin/g++ 
>>> > 
>>> >   f77: /usr/bin/gfortran 
>>> > 
>>> >   fc: /usr/bin/gfortran 
>>> > 
>>> > spec: gcc@4.8.5 
>>> > 
>>> > target: x86_64 
>>> > 
>>> > - compiler: 
>>&

Re: [deal.II] Re: error during installation with spack on CentOS7

[Denis Davydov]

Hi Alberto,

Looks like the issue is known to Spack 
community: https://github.com/spack/spack/issues/11224 where there is also 
a possible source of the problem you can try as a fix (un-do on-line PR).

Regards,
Denis.

On Wednesday, October 2, 2019 at 3:14:46 PM UTC+2, Bruno Turcksin wrote:
>
> Alberto, 
>
> So what happens is that spack is using gcc 9.2 like you want but it 
> usess the libstdc++ from gcc 4.8.5 I usually spack to install a new 
> compiler and my compilers.yaml looks like your *but* I have the path 
> to the correct libstdc++ in my LD_LIBRARY_PATH when I load the module. 
> So I guess you need to add that path somewhere in your compilers.yaml 
>
> Best, 
>
> Bruno 
>
> Le mer. 2 oct. 2019 à 08:51, Alberto Salvadori 
> > a écrit : 
> > 
> > Thank you, Bruno. In fact, my aim was to use my system compiler. 
> > Here is my  .spack/linux/packages.yaml: 
> > 
> > packages: 
> > 
> >   all: 
> > 
> > compiler: [gcc] 
> > 
> > providers: 
> > 
> >   mpi: [openmpi] 
> > 
> >   openmpi: 
> > 
> > version: [3.1.4] 
> > 
> > paths: 
> > 
> >   openmpi@3.1.4%gcc@9.2.0: /usr/local/ 
> > 
> > buildable: False 
> > 
> >   perl: 
> > 
> > paths: 
> > 
> >   perl@5.16.3%gcc@9.2.0: /usr 
> > 
> >   cmake: 
> > 
> > version: [3.15.3] 
> > 
> > paths: 
> > 
> >   cmake@3.15.3%gcc@9.2.0: /usr/local/ 
> > 
> >   hdf5: 
> > 
> > version: [1.8.12] 
> > 
> > paths: 
> > 
> >   hdf5@1.8.12%gcc@9.2.0: /usr 
> > 
> > variants: +hl+fortran 
> > 
> >   netcdf: 
> > 
> > version: [7.2.0] 
> > 
> > paths: 
> > 
> >  netcdf@7.2.0%gcc@9.2.0: /usr 
> > 
> >   netcdf-cxx: 
> > 
> > version: [4.2.8] 
> > 
> > paths: 
> > 
> >  netcdf-cxx@4.2.8%gcc@9.2.0: /usr 
> > 
> >   dealii: 
> > 
> > variants: +optflags~python 
> > 
> > 
> > Shall I perhaps add something to the compiler flag (paths or so)? 
> > Here is also my  .spack/linux/compilers.yaml 
> > 
> > compilers: 
> > 
> > - compiler: 
> > 
> > environment: {} 
> > 
> > extra_rpaths: [] 
> > 
> > flags: {} 
> > 
> > modules: [] 
> > 
> > operating_system: centos7 
> > 
> > paths: 
> > 
> >   cc: /usr/bin/gcc 
> > 
> >   cxx: /usr/bin/g++ 
> > 
> >   f77: /usr/bin/gfortran 
> > 
> >   fc: /usr/bin/gfortran 
> > 
> > spec: gcc@4.8.5 
> > 
> > target: x86_64 
> > 
> > - compiler: 
> > 
> > environment: {} 
> > 
> > extra_rpaths: [] 
> > 
> > flags: {} 
> > 
> > modules: [] 
> > 
> > operating_system: centos7 
> > 
> > paths: 
> > 
> >   cc: /usr/local/bin/gcc 
> > 
> >   cxx: /usr/local/bin/g++ 
> > 
> >   f77: /usr/local/bin/gfortran 
> > 
> >   fc: /usr/local/bin/gfortran 
> > 
> > spec: gcc@9.2.0 
> > 
> > target: x86_64 
> > 
> > 
> > 
> > Alberto 
> > 
> > 
> > Alberto Salvadori 
> >  Dipartimento di Ingegneria Meccanica e Industriale (DIMI) 
> >  Universita` di Brescia, via Branze 43, 25123 Brescia 
> >  Italy 
> >  tel 030 3711239 
> >  fax 030 3711312 
> > 
> > e-mail: 
> >  alberto@unibs.it  
> > web-page: 
> >  http://m4lab.unibs.it/faculty.html 
> > 
> > 
> > 
> > On Wed, Oct 2, 2019 at 2:41 PM Bruno Turcksin  > wrote: 
> >> 
> >> Alberto, 
> >> 
> >> On Wednesday, October 2, 2019 at 7:24:32 AM UTC-4, Alberto Salvadori 
> wrote: 
> >>> 
> >>> 
> >>> Thank you so much W and D, 
> >>> As you pointed out there seems to be a mistake in the most recent 
> version of perl during installation. 
> >>> I will propagate this to the proper communities. 
> >>> 
> >>> As Denis proposed, I went on simply tell Spack to use Perl from 
> system: 
> >>> 
> >>> perl: 
> >>> paths: 
> >>>  perl@5.26.2%gcc@9.2.0: /usr 
> >>> 
> >>> but I bumped into another issue: 
> >>> 
> >>> [deal.ii@localhost spack]$ spack install dealii^cmake@3.9.4 
> >>> 
> >>> ==> libsigsegv is already installed in 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/libsigsegv-2.11-brkulrpubdu66nzym2zt2j6c3h6nw463
>  
>
> >>> 
> >>> ==> m4 is already installed in 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/m4-1.4.18-23npyrcdfzqehgp4s2mhka4nknjjkbzt
>  
>
> >>> 
> >>> ==> perl@5.16.3 : externally installed in /usr 
> >>> 
> >>> ==> perl@5.16.3 : already registered in DB 
> >>> 
> >>> ==> autoconf is already installed in 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/autoconf-2.69-2vk2foufmuyjm2gh47u6nouxezza3p6p
>  
>
> >>> 
> >>> ==> automake is already installed in 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/automake-1.16.1-z52jybnv7ass3otkgegjazvdbbughw2q
>  
>
> >>> 
> >>> ==> libtool is already installed in 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/libtool-2.4.6-mr3m4npcnryydzctugoebk2zuoav7zte
>  
>
> >>> 
> >>> ==> adol-c is already installed in 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/adol-c-develop-xioth2pegguh6rb6mzfzk7zhvb2kgeue
>  
>
> >>> 
> >>> ==> pkgconf is 

[deal.II] Re: Issue with boost serialization and spack?

[Denis Davydov]

On Wednesday, October 2, 2019 at 11:50:53 AM UTC+2, Konrad Simon wrote:
>
> Thank you, Denis. I use a pretty stupid (but simple) workaround: I setup 
>>> and compile deal.ii myself since all dependencies are compiled and use the 
>>> cmake command used by spack. That works. And I do not get the serialization 
>>> error.
>>>
>>
>>
>> now that is strange. Are you sure you pick up the same boost?
>> Could you post the original error from CMake error logs that shows how 
>> serialization test fails?
>>  
>>
> Cmake in my little modification seems to pick up the right boost. (for 
> error log with boost see above)
>

For the error log I meant  CMakeError.log which should contain the failing 
serialization test. 
What you posted is the output of CMake config which only states that the 
serialization test failed, but does not give details as to why.
But that's not iimportant as 1.70 works for you.

 
> DEAL_II_WITH_BOOST set up with external dependencies 
> #BOOST_VERSION = 1.70.0 
> #BOOST_DIR = 
> /scratch/cen/numgeo/spack-lib/linux-debian8-x86_64/gcc-7.3.0/boost-1.70.0 
> #BOOST_CXX_FLAGS = -Wno-unused-local-typedefs 
> #BOOST_DEFINITIONS = BOOST_NO_AUTO_PTR 
> #BOOST_USER_DEFINITIONS = BOOST_NO_AUTO_PTR 
> #BOOST_INCLUDE_DIRS = 
> /scratch/cen/numgeo/spack-lib/linux-debian8-x86_64/gcc-7.3.0/boost-1.70.0/include
>  
>
> #BOOST_USER_INCLUDE_DIRS = 
> /scratch/cen/numgeo/spack-lib/linux-debian8-x86_64/gcc-7.3.0/boost-1.70.0/include
>  
>
> #BOOST_LIBRARIES = 
> /scratch/cen/numgeo/spack-lib/linux-debian8-x86_64/gcc-7.3.0/boost-1.70.0/lib/libboost_iostreams-mt.so;/scratch/cen/numgeo/spack-lib/lin
> ux-debian8-x86_64/gcc-7.3.0/boost-1.
>
>
>
but that is different boos version from what you posted above, namely 
1.70.0 instead of 1.62. I guess that would also work if you install dealii 
+ 1.70 via Spack without manual labour. 
 
Regards,
Denis.

-- 
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/1186a04f-4975-45ba-84aa-4af560fd54cf%40googlegroups.com.

[deal.II] Re: Issue with boost serialization and spack?

[Denis Davydov]

Hi Konrad,

On Monday, September 30, 2019 at 3:55:20 PM UTC+2, Konrad Simon wrote:
>
> Thank you, Denis. I use a pretty stupid (but simple) workaround: I setup 
> and compile deal.ii myself since all dependencies are compiled and use the 
> cmake command used by spack. That works. And I do not get the serialization 
> error.
>


now that is strange. Are you sure you pick up the same boost?
Could you post the original error from CMake error logs that shows how 
serialization test fails?
 

>
> However, now my code runs on the machine I installed it on. But once I use 
> slurm to distribute the job across nodes I get "illegal instruction" erros. 
> Frustrating.
>

With HPC I used to have access to they did not use slurm, so I can't really 
comment here.
If that's during running quick tests or so, it could be related to a wrong 
MPIEXEC pickedup by deal.II config.
I wanted to fix that in Spack https://github.com/spack/spack/pull/11142 
but apparently this solution may not be fully functional for Slurm.

Denis.

-- 
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/b8a687fa-f8c8-4f72-b07b-ab60cd158835%40googlegroups.com.

[deal.II] Re: error during installation with spack on CentOS7

[Denis Davydov]

Hi Alberto,

Such issues should ideally be reported to Perl, because that's the issue 
with their package. Or at least to Spack in a hope that the community can 
come up with some patch to workaround the build issue in Perl.

For you to go on simply tell Spack to use Perl from system:

perl:
paths:
 perl@5.26.2%gcc@9.2.0: /usr

As for the Blas/Lapack, IMO there is no reason to use system provided one 
in your case. 
You get more control of threading, compiler flags, etc through Spack and it 
does not take ages to build either.

p.s. there are some examples of config files for Spack on various HPC 
systems, if that helps:

https://github.com/spack/spack-configs 
https://github.com/eth-cscs/production/tree/master/spack/daint 
https://ceed.exascaleproject.org/ceed-1.0/ 
https://gitlab.dkrz.de/m300488/icon-bootstrap/tree/master/config/sites


Denis.

On Tuesday, October 1, 2019 at 7:02:43 PM UTC+2, Alberto Salvadori wrote:
>
> Dear community
>
> I have been trying to install deal.ii on a linux machine equipped with 
> CentOS7. As very clearly explained in " 
> https://github.com/dealii/dealii/wiki/deal.II-in-Spack#check-before-build 
> "
> I have installed the latest version of gcc, openmpi, cmake.
>
> [deal.ii@localhost spack]$ gcc --version
>
> gcc (GCC) 9.2.0
>
> Copyright (C) 2019 Free Software Foundation, Inc.
>
> This is free software; see the source for copying conditions.  There is NO
>
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> [deal.ii@localhost spack]$ mpirun --version
>
> mpirun (Open MPI) 3.1.4
>
> [deal.ii@localhost spack]$ cmake --version
>
> cmake version 3.15.3
>
> Noticing the incompatibility with cmake, I run
>
> [deal.ii@localhost spack]$ spack install dealii^cmake@3.9.4
>
>
>
>
> but I got this error:
>
>
>
> *==>* libsigsegv is already installed in 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/libsigsegv-2.11-brkulrpubdu66nzym2zt2j6c3h6nw463
>
> *==>* m4 is already installed in 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/m4-1.4.18-23npyrcdfzqehgp4s2mhka4nknjjkbzt
>
> *==>* pkgconf is already installed in 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/pkgconf-1.6.1-qtpkfoaa5ae54s4icmqie5hbtz6murqx
>
> *==>* ncurses is already installed in 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/ncurses-6.1-awd5putjsuzsddipc35vxiupdjicseao
>
> *==>* readline is already installed in 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/readline-7.0-tftx53fdsvjjtfzsfadhzrplo7w2yf46
>
> *==>* gdbm is already installed in 
> /home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/gdbm-1.18.1-chqdjuttuqyeyrmsnm6yistdpigsguwq
>
> *==>* *Installing* *perl*
>
> *==>* Searching for binary cache of perl
>
> *==>* Warning: No Spack mirrors are currently configured
>
> *==>* No binary for perl found: installing from source
>
> *==>* Using cached archive: 
> /home/deal.ii/spack/var/spack/cache/perl/perl-5.26.2.tar.gz
>
> *==>* Using cached archive: 
> /home/deal.ii/spack/var/spack/cache/perl/cpanm-5.26.2.tar.gz
>
> *==>* Using cached archive: 
> /home/deal.ii/spack/var/spack/cache/perl/perl-5.26.1-guard_old_libcrypt_fix.patch
>
> *==>* Staging archive: 
> /tmp/deal.ii/spack-stage/perl-5.26.2-zoihbi4ixpd7iyaf5qrbvld62itpgde3/perl-5.26.2.tar.gz
>
> *==>* Created stage in 
> /tmp/deal.ii/spack-stage/perl-5.26.2-zoihbi4ixpd7iyaf5qrbvld62itpgde3
>
> *==>* Staging archive: 
> /tmp/deal.ii/spack-stage/resource-cpanm-zoihbi4ixpd7iyaf5qrbvld62itpgde3/App-cpanminus-1.7042.tar.gz
>
> *==>* Created stage in 
> /tmp/deal.ii/spack-stage/resource-cpanm-zoihbi4ixpd7iyaf5qrbvld62itpgde3
>
> *==>* Moving resource stage
>
> source : 
> /tmp/deal.ii/spack-stage/resource-cpanm-zoihbi4ixpd7iyaf5qrbvld62itpgde3/spack-src/
>
> destination : 
> /tmp/deal.ii/spack-stage/perl-5.26.2-zoihbi4ixpd7iyaf5qrbvld62itpgde3/spack-src/cpanm/cpanm
>
> *==>* Applied patch 
> https://src.fedoraproject.org/rpms/perl/raw/004cea3a67df42e92ffdf4e9ac36d47a3c6a05a4/f/perl-5.26.1-guard_old_libcrypt_fix.patch
>
> *==>* Building perl [Package]
>
> *==>* Executing phase: 'configure'
>
> *==>* Executing phase: 'build'
>
> *==>* Error: ProcessError: Command exited with status 2:
>
> 'make' '-j12'
>
>
> 17 errors found in build log:
>
>  5085
> LD_LIBRARY_PATH=/tmp/deal.ii/spack-stage/perl-5.26.2-zoihbi4ixpd7iyaf5qrbvld62itpgde3/spack-src
>  
> ./miniperl -Ilib make_ext.pl lib/auto/PerlIO/encoding/encoding.so  
> MAKE="make" LIBPERL_A=libperl.so LINKTYPE=dynamic
>
>  5086mv Base64.xsc Base64.c
>
>  5087cc -c   -D_REENTRANT -D_GNU_SOURCE 
> -DAPPLLIB_EXP="/home/deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/perl-5.26.2-zoihbi4ixpd7iyaf5qrbvld62itpgde3/lib/perl5"
>  
> -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/home/
>
>  
> deal.ii/spack/opt/spack/linux-centos7-ivybridge/gcc-9.2.0/gdbm-1.18.1-chqdjuttuqyeyrmsnm6yistdpigsguwq/include
> 

[deal.II] Re: Issue with boost serialization and spack?

[Denis Davydov]

p.s. long discussion on serialization bug in Boost is here 
https://github.com/boostorg/serialization/pull/79 

Frankly, I would not be surprized that 1.62 has issues as well...

On Saturday, September 28, 2019 at 8:02:19 PM UTC+2, Konrad Simon wrote:
>
> Dear deal.ii community,
>
> I am having a little problem and I was wondering if this issue is known. I 
> installed deal.ii on our cluster  and all dependencies build nicely with my 
> chosen compiler (gcc v7.3). BLAS and LAPACK are being built as well as 
> openmpi (the versions on the cluster are not suitable at the moment). 
> However, when building deal.ii I get the output below (I only paste the 
> relevant part). It also happens when I ask preck to build deal.ii with 
> (externally spack built) boost v1.62 and v1.68. 
>
> Could there be a configuration issue with boost in the spack build class 
> of deal.ii? When looking at it I see that some version dependent boost 
> patches are applied but I am not familiar with the details.
>
> Anyone knows this? Is there a workaround?
>
> Thanks and best regards,
> Konrad
>
> -- Include 
> /tmp/u290231/spack-stage/dealii-9.1.1-gfk33pgt5rojhujhmuruaahuuzyzq2zm/spack-src/cmake/configure/configure_2_boost.cmake
> -- Found Boost: 
> /scratch/cen/numgeo/spack-lib/linux-debian8-broadwell/gcc-7.3.0/boost-1.62.0/include
>  
> (found suitable version "1.62.0", minimum required is "1.59") found 
> components:  iostreams serialization system thread regex chrono date_time 
> atomic 
> --   BOOST_VERSION: 1.62.0
> --   BOOST_LIBRARIES: 
> /scratch/cen/numgeo/spack-lib/linux-debian8-broadwell/gcc-7.3.0/boost-1.62.0/lib/libboost_iostreams-mt.so;/scratch/cen/numgeo/spack-lib/linux-debian8-broadwell/gcc-7.3.0/boost-1.62.0/lib/libboost_serialization-mt.so;/scratch/cen/numgeo/spack-lib/linux-debian8-broadwell/gcc-7.3.0/boost-1.62.0/lib/libboost_system-mt.so;/scratch/cen/numgeo/spack-lib/linux-debian8-broadwell/gcc-7.3.0/boost-1.62.0/lib/libboost_thread-mt.so;/scratch/cen/numgeo/spack-lib/linux-debian8-broadwell/gcc-7.3.0/boost-1.62.0/lib/libboost_regex-mt.so;/scratch/cen/numgeo/spack-lib/linux-debian8-broadwell/gcc-7.3.0/boost-1.62.0/lib/libboost_chrono-mt.so;/scratch/cen/numgeo/spack-lib/linux-debian8-broadwell/gcc-7.3.0/boost-1.62.0/lib/libboost_date_time-mt.so;/scratch/cen/numgeo/spack-lib/linux-debian8-broadwell/gcc-7.3.0/boost-1.62.0/lib/libboost_atomic-mt.so
> --   BOOST_INCLUDE_DIRS: 
> /scratch/cen/numgeo/spack-lib/linux-debian8-broadwell/gcc-7.3.0/boost-1.62.0/include
> --   BOOST_USER_INCLUDE_DIRS: 
> /scratch/cen/numgeo/spack-lib/linux-debian8-broadwell/gcc-7.3.0/boost-1.62.0/include
> -- Found BOOST
> -- Performing Test BOOST_IOSTREAMS_USABLE
> -- Performing Test BOOST_IOSTREAMS_USABLE - Success
> -- Performing Test BOOST_SERIALIZATION_USABLE
> -- Performing Test BOOST_SERIALIZATION_USABLE - Failed
> -- The externally provided Boost.Serialization library failed to pass a 
> crucial test. 
> Therefore, the bundled boost package is used. 
> The configured testing project can be found at 
>
> /tmp/u290231/spack-stage/dealii-9.1.1-gfk33pgt5rojhujhmuruaahuuzyzq2zm/spack-build/cmake/configure/TestBoostBugWorkdir
> -- DEAL_II_WITH_BOOST has unmet external dependencies.
> CMake Error at cmake/macros/macro_configure_feature.cmake:112 (MESSAGE):
>   
>
>   Could not find the boost library!
>
>   The externally provided Boost.Serialization library failed to pass a
>   crucial test.Please ensure that a suitable boost library is installed on
>   your computer.
>
>   If the library is not at a default location, either provide some hints 
> for
>   autodetection,
>
>   $ BOOST_DIR="..." cmake <...>
>   $ cmake -DBOOST_DIR="..." <...>
>
>   or set the relevant variables by hand in ccmake.
>
>   Alternatively you may choose to compile the bundled library of boost by
>   setting DEAL_II_ALLOW_BUNDLED=on or DEAL_II_FORCE_BUNDLED_BOOST=on.
>
> Call Stack (most recent call first):
>   cmake/macros/macro_configure_feature.cmake:269 (FEATURE_ERROR_MESSAGE)
>   cmake/configure/configure_2_boost.cmake:237 (CONFIGURE_FEATURE)
>   cmake/macros/macro_verbose_include.cmake:19 (INCLUDE)
>   CMakeLists.txt:124 (VERBOSE_INCLUDE)
>

-- 
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/d905dde0-2828-4b45-a45c-81d7eb0f9f4e%40googlegroups.com.

[deal.II] Issue with boost serialization and spack?

[Denis Davydov]

Hi,

Boost serializstion was broken in several versions of boost, that’s why it’s 
blacklisted in Spack package for some and has a patch for others. It looks like 
your setup of compiler/platform reveal that it’s broken in another case as 
well. To be sure you can check CMake log in build folder where a small test is 
run to check serialization. If the output looks valid (it is indeed broken), I 
would try a different version of boost.

Denis.

-- 
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/35c66ce4-4725-442b-ad70-a4bafaef38f3%40googlegroups.com.

[deal.II] Soli mechanics C++/FEM developer position in Germany, Nürnberg (Siemens SISW / JobID 123744)

[Denis Davydov]

Dear all,

There is a job opening at SIEMENS that might be of interest to members of 
the deal.II community.
Good knowledge of solid mechanics and practical experience developing C++ 
code and/or contributing to open source FEM libraries like deal.II are 
desired. 
The applications review is already happening, so please don't postpone the 
application if you are interested.

https://jobs.siemens-info.com/jobs/123744 


Sincerely,
Denis Davydov

-- 
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/57cb9692-0f56-420d-87e0-dd2a6921048b%40googlegroups.com.

[deal.II] Re: L2 norm of distribution solution

[Denis Davydov]

Hi Jean,

Minor unrelated note to your snippet of manually written L2 norm: have a 
look at 
https://www.dealii.org/developer/doxygen/deal.II/namespaceUtilities_1_1MPI.html 
which has plenty of template wrappers for MPI functions that can make life 
much much easier, including sending objects that can be serialized
(which is not the case here, but still).

> If you think this is not obvious in the documentation, can 
you point out where you looked? It's something easily fixed. (Want to write 
your first pull request? ;-) ) 

+1

Regards,
Denis.

On Saturday, March 2, 2019 at 4:54:46 AM UTC+1, Jean Ragusa wrote:
>
> Hi,
>
> I have a solution vector with locally owned and locally relevant dofs. I 
> want to compute its L2-norm. Using the l2_norm() on it caused a Trilinos 
> error (I was going to compute the squared of the L2 norm, then do an MPI 
> Allreduce on the resulting values).
>
> So, I decided to code it "by hand" as follows: 
>
> double norm_squared = 0.;
> const unsigned int start_ = (dist_solution.local_range().first), end_ = 
> (dist_solution.local_range().second);
>
> for (unsigned int i = start_; i < end_; ++i)
>norm_squared += std::pow(dist_solution(i),2);
>
> double norm_global =0.;
> MPI_Allreduce(_squared, _global, 1, MPI_DOUBLE, MPI_SUM, 
> mpi_communicator);
> norm_global = std::sqrt(norm_global);
>
>
> Even though this works, I was wondering if there is a better way to do 
> this? 
>
> Cheers,
> --jean
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: command line compilation error on a linux machine using spack installation of deal.ii dev

[Denis Davydov]

Hi Nicola

On Monday, January 28, 2019 at 11:35:33 AM UTC+1, Nicola Giuliani wrote:
>
> Dear all,
>
> I have just updated my spack installation of deal.ii on Linux Mint (18) 
> machine. 
>

by updated you mean you pulled the recent version and installed the deal.II 
via Spack? 
What commit are you on?
My Ubuntu tester is on 09033e991ef390370955eebecb2c0f734994d16b (12.01.19), 
I quickly checked recently merged PRs in Spack and 
did not immediately noticed anything that could break CMake packages in 
general or deal.II in particular.
 

>
> When I try to compile my deal.ii based project I get puzzling errors. The 
> compiler has already compiled all the files of the project and put them 
> into a library, then It tries to compile the main file executing the 
> following line
>

so the deal.II re-installation was fine? Did you start from clean build 
folder for your downstream project?
Depending on what changed between you previous setup and the current one, 
you might get different versions/flavors of third-party-libraries, like 
OpenMPI, Trilinos, etc.
It is possible that CMake was confused between the two build of deal.II you 
use in the downstream project (old and new one).
 

> and It reports
>
> :0:11: error: expected identifier before numeric constant
> :0:11: error: expected unqualified-id before numeric constant
> :0:11: error: expected unqualified-id before numeric constant
>

I don't think I ever saw such errors ;-(

Hopefully we can get to the bottom of this.

Regards,
Denis.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Trouble Installing: "undefined symbol: cblas_ctrmv"

[Denis Davydov]

Hi Kyle

On Friday, January 25, 2019 at 9:11:35 AM UTC+1, ky...@math.uh.edu wrote:
>
> Hi Denis,
>
> I did see both of the issues raised on github before I posted, but it 
> wasn't really clear what the resolution was other than its a gsl dependency 
> problem. 
>

I would say from our side we tried to pick up `gslcblas` to fix part of the 
issue with Linux provided GSL
 

>
> nm -g /usr/lib64/libgslcblas.so
> nm -g /usr/lib64/libgsl.so
> both tell me there are no symbols, even without grepping for the one in 
> question.
>
> Does this mean that if I do need GSL I should install from source instead? 
> (as pointed out in the other response, I don't need GSL for the work i will 
> be doing).
>

Yes, I would say so. But given that you won't need this functionality, you 
can safely disable GSL as recommended by David. 
In recent years I tend to prefer build everything from sources 
using https://github.com/dealii/dealii/wiki/deal.II-in-Spack for all 
environments (macOS and HPC).

Regards,
Denis.
 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Trouble Installing: "undefined symbol: cblas_ctrmv"

[Denis Davydov]

Hi Kyle,

According to your config, deal.II picked up gslcblas.so: 

GSL_LIBRARIES = /usr/lib64/libgsl.so;/usr/lib64/libgslcblas.so

Could you check if it contains the missing symbol, something like:

$ nm -g 
~/spack/opt/spack/darwin-mojave-x86_64/clang-10.0.0-apple/gsl-2.5-3xp3xgxrby4oihswo2f7ve2hywzbxvjx/lib/libgslcblas.dylib
 
| grep cblas_ctrmv
000316c0 T _cblas_ctrmv

p.s. FYI https://github.com/dealii/dealii/issues/2881#issuecomment-235790839
and 
also https://github.com/JuliaMath/GSL.jl/issues/70#issuecomment-402674809 
Looks like this is really an issue with GSL as natively provided by Linux 
package manager.

Denis.


On Thursday, January 24, 2019 at 10:43:14 PM UTC+1, ky...@math.uh.edu wrote:
>
> Hi all,
>
> I'm having trouble installing deal.II. cmake seems to find gsl just fine, 
> but it looks like there is trouble when linking against it. As you can see 
> in the quicktests.log, the error it gives is that "symbol lookup error: 
> /lib64/libgsl.so.23: undefined symbol: cblas_ctrmv"
>
> I also see that a similar issue had bee reported here 
> https://github.com/dealii/dealii/issues/2757, but this was a couple years 
> ago and a patch was merged. 
>
> The logs you see are for installing the master branch from github, 
> although I got similar errors when trying to install version 8.5 as well.
>
> -Kyle Williams
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Trouble building from source on MacOS

[Denis Davydov]

On Monday, November 5, 2018 at 9:20:21 PM UTC, mrjonm...@gmail.com wrote:
>
> Thanks for the suggestion. I tried building with candi today, but it 
> failed somewhere during the p4est-2.0/FAST build from the look of it. I've 
> been using macports instead of homebrew, and I'm wondering if some of the 
> ports are causing issues. I might try removing all the ports and macports 
> this evening to see if that fixes it. 
>

Try https://github.com/dealii/dealii/wiki/deal.II-in-Spack 
that is what we use to deliver macOS binaries.
It won't assume that you have anything installed (won't use macports or 
homebrew).
It will also allow to you keep around multiple versions of Software without 
conflicts.

The only thing is that you shall either have `gfortran` installed (can also 
do via Spack) or it being in path and then tell spack to use clang + 
gfortran,
see https://github.com/dealii/dealii/wiki/deal.II-in-Spack#using-macos 

I use Spack for build deal.II for several years, probably sins Sierra. Now 
I am on Mojave.
 

>
> Also, I didn't install any of the packages listed as optional in the candi 
> instructions. Those were: wget, gnuplot, bash and modules. 
>

those (any many more) can also be installed via Spack.

Regards,
Denis.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Function to output stress and strain

[Denis Davydov]

Hi Shawn,

> 3 нояб. 2018 г., в 2:28, Yuxiang Wang  
> написал(а):
> 
> Hi Denis,
> 
> Thank you for the pointer! This is very helpful.
> 
> The below is my understanding (and please let me know if I am wrong):
> 
> 1. If we do the L2 projection over a domain of elements, then it smooths the 
> stress jumps in the sense of integration. The stress would be continuous over 
> the domain;

If you project on continuous FE space then yes, it will be continuous.

> 2. Or, if we do the L2 projection over single elements (or, we focus on 
> elements on the boundaries between the domains in #1), there will still be 
> jumps over the boundaries.

Correct. That’s because here projection for each element would be independent 
and therefore does not have to match over boundaries.

> This sometimes is desirable; we can then choose our own method to assign to 
> the node (e.g. peak stress).

Regards,
Denis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Error in installing deal.ii with spack on CentOs7

[Denis Davydov]

Hi Alberto,

I figured out what's happening. The issue you see is NOT related to what me 
and JP suggested.
It is a separate issues related to constraints on compilers from 
suite-sparse. I created a PR in spack to clarify this:
https://github.com/spack/spack/pull/9622/ 
Once it's merged, you would not see the "conretization" error, but you 
should see that you can't build the most recent suite-sparse with older GCC.
The end solution would be the same: 
(i) you need to choose suite-sparse@5.1.0 which can be built with GCC 4.8.5
(ii) you need to choose older version of PETSc which support older versions 
of suite-sparse.

Regards,
Denis.

On Monday, October 22, 2018 at 7:50:45 AM UTC+2, Alberto Salvadori wrote:
>
> Dear community
>
> I am installing deal.ii (latest release) on a CentOS7 equipped machine. 
> After typing
>
> spack install --test=root dealii
>
> I see this error:
>
> ==> Error: An unsatisfiable version constraint has been detected for spec:
>
> suite-sparse@5.3.0%gcc@4.8.5~cuda~openmp+pic~tbb 
> arch=linux-centos7-x86_64 
>
>
> while trying to concretize the partial spec:
>
> dealii@9.0.1%gcc@4.8.5+adol-c+arpack+assimp build_type=DebugRelease ~cuda 
> cuda_arch= 
> ~doc+gmsh+gsl+hdf5~int64+metis+mpi+nanoflann+netcdf+oce~optflags+p4est+petsc~python+scalapack+slepc+sundials+trilinos
>  arch=linux-centos7-x86_64 
> ^adol-c@2.6.4:
> ^arpack-ng+mpi
> ^mpi
> ^openblas@0.3.3%gcc@4.8.5 cpu_target= ~ilp64+pic+shared 
> threads=none ~virtual_machine arch=linux-centos7-x86_64 
> ^assimp
> 
> ^boost@1.59.0:1.63,1.65.1,1.67.0:+iostreams+serialization+system+thread
> ^bzip2
> ^diffutils
> ^zlib@1.2.11%gcc@4.8.5+optimize+pic+shared 
> arch=linux-centos7-x86_64 
> ^cmake@3.12.2%gcc@4.8.5~doc+ncurses+openssl+ownlibs~qt 
> arch=linux-centos7-x86_64 
> ^ncurses
> ^pkgconfig
> ^openssl
> ^perl@5.14.0:
> ^gdbm
> ^readline
> ^gmsh+netgen+oce+tetgen
> ^gmp
> ^autoconf
> ^m4@1.4.6:
> ^automake
> ^libtool@2.4.2:
> ^netgen
> ^oce
> ^tetgen
> ^hdf5@1.8.9:+hl+mpi
> ^intel-tbb@2019%gcc@4.8.5 cxxstd=default +shared+tm 
> arch=linux-centos7-x86_64 
> ^metis@5:~int64+real64
> ^muparser@2.2.5%gcc@4.8.5 arch=linux-centos7-x86_64 
> ^nanoflann
> ^netcdf+mpi
> ^p4est
> ^sundials~pthread
> ^trilinos+amesos+aztec+epetra+ifpack+ml+muelu+sacado+teuchos
> ^glm
> ^matio
>
>
> dealii requires suite-sparse version :5.1.0, but spec asked for 5.3.0
>
> I wonder which is the source of the error and which files ( 
> ~/.spack/linux/packages.yaml perhaps?)
> shall I edit to sort out the issue.
>
> Many thanks in advance
>
> Alberto
>
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Error in installing deal.ii with spack on CentOs7

[Denis Davydov]

On Tuesday, October 23, 2018 at 6:39:46 PM UTC+2, Denis Davydov wrote:
> 
> Unfortunately I can reproduce you error in a clean environment on my Ubuntu 
> machine. But I am glad that you solved the issue.

I meant “can NOT reproduce”, sorry for the typo.

Regards,
Denis
.



-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Error in installing deal.ii with spack on CentOs7

[Denis Davydov]

Hi Alberto,

Unfortunately I can reproduce you error in a clean environment on my Ubuntu 
machine. But I am glad that you solved the issue.

Regards,
Denis

> 23 окт. 2018 г., в 18:06, Alberto Salvadori  
> написал(а):
> 
> Hi Denis,
> thanks! Here is my history file.
> 
>90  cd Pubblici/
>91  mkdir spack
>94  cd spack/
>95  git clone https://github.com/spack/spack.git .
>96  git checkout develop
>97  git reset --hard e38f39e4eafeaa6daed580cece935141e5d8f04b
>98  spack install dealii
>99  cd ..
>   100  nano .spack/linux/packages.yaml 
>   101  cd Pubblici/spack/
>   102  spack install dealii
>   103  ls -lta
>   104  cd share/
>   105  ls
>   106  cd spack/
>   107  ls
>   108  cd 
> /home/alberto.salvadori/Pubblici/spack/opt/spack/linux-centos7-x86_64/gcc-4.8.5/dealii-9.0.1-jdludrcm25brf6vxyb5l6dqnmjigzvyq
>   109  ls -lta
>   110  ls share/
> 
> 
> You see that there are two calls "spack install dealii" since I had to edit 
> the file ".spack/linux/packages.yam" in order to install petsc 3.10
> Hope this helps
> 
> Alberto
> 
> Alberto Salvadori
>  Dipartimento di Ingegneria Civile, Architettura, Territorio, Ambiente e di 
> Matematica (DICATAM)
>  Universita` di Brescia, via Branze 43, 25123 Brescia
>  Italy
>  tel 030 3711239
>  fax 030 3711312
> 
> e-mail: 
>  alberto.salvad...@unibs.it
> web-pages:
>  http://m4lab.unibs.it/faculty.html
>  http://dicata.ing.unibs.it/salvadori
> 
> 
>> On Tue, Oct 23, 2018 at 9:02 AM Denis Davydov  wrote:
>> Alberto,
>> 
>> Did you reset Spack to the current recommended version, namely 
>> e38f39e4eafeaa6daed580cece935141e5d8f04b  (I edited the wiki 7 days ago)?
>> I double checked that 9.0.1 has no issues with concretization there with 
>> empty packages.yaml settings.
>> 
>> My guess would be that
>> (i) either you used older version where the conflict between PETSc and 
>> Trilinos is not resolved or
>> (ii) you have extra preferences in your packages.yaml that cause this 
>> conflict
>> 
>> Regards,
>> Denis.
>> 
>>> On Monday, October 22, 2018 at 8:20:03 AM UTC+2, Alberto Salvadori wrote:
>>> Thank you, Praveen.
>>> 
>>> While installing deal.ii all detailed instructions on the spack wiki page 
>>> have been followed. I cloned spack from git (I thus assume it is the latest 
>>> version) and made no modifications (yet :-) ) to the  
>>> “.spack/linux/packages.yaml” file. By the way, I did install deal.ii on 
>>> opensuse a couple of weeks ago without this issue.
>>> 
>>> Shall I attach my  “.spack/linux/packages.yaml”  here?
>>> 
>>> Alberto 
>>> 
>>> Alberto Salvadori
>>>  Dipartimento di Ingegneria Civile, Architettura, Territorio, Ambiente e di 
>>> Matematica (DICATAM)
>>>  Universita` di Brescia, via Branze 43, 25123 Brescia
>>>  Italy
>>>  tel 030 3711239
>>>  fax 030 3711312
>>> 
>>> e-mail: 
>>>  alberto@unibs.it
>>> web-pages:
>>>  http://m4lab.unibs.it/faculty.html
>>>  http://dicata.ing.unibs.it/salvadori
>>> 
>>> 
>>>> On Mon, Oct 22, 2018 at 8:08 AM Praveen C  wrote:
>>>> When I check spec on my opensuse machine, dealii@9.0.1 wants to use 
>>>> suite-sparse@5.3.0
>>>> 
>>>> Have you perhaps already set some versions in your 
>>>> “.spack/linux/packages.yaml” file ?
>>>> 
>>>> What does your file look like ?
>>>> 
>>>> Also, you may want to update your spack to see it that fixes it.
>>>> 
>>>> Thanks
>>>> praveen
>>>> 
>>>>> On 22-Oct-2018, at 11:20 AM, Alberto Salvadori  
>>>>> wrote:
>>>>> 
>>>>> Dear community
>>>>> 
>>>>> I am installing deal.ii (latest release) on a CentOS7 equipped machine. 
>>>>> After typing
>>>>> 
>>>>> spack install --test=root dealii
>>>>> 
>>>>> I see this error:
>>>>> 
>>>>> ==> Error: An unsatisfiable version constraint has been detected for spec:
>>>>> 
>>>>> suite-sparse@5.3.0%gcc@4.8.5~cuda~openmp+pic~tbb 
>>>>> arch=linux-centos7-x86_64 
>>>>> 
>>>>> 
>>>>> while trying to concretize the partial spec:
>>>>> 
>>>>> dealii@9.0.1%gcc@4.8.5+adol-c+arpack+assimp build_type=DebugRelease 
>

Re: [deal.II] Error in installing deal.ii with spack on CentOs7

[Denis Davydov]

Alberto,

Did you reset Spack to the current recommended version, 
namely e38f39e4eafeaa6daed580cece935141e5d8f04b  (I edited the wiki 7 days 
ago)?
I double checked that 9.0.1 has no issues with concretization there with 
empty packages.yaml settings.

My guess would be that
(i) either you used older version where the conflict between PETSc and 
Trilinos is not resolved or
(ii) you have extra preferences in your packages.yaml that cause this 
conflict

Regards,
Denis.

On Monday, October 22, 2018 at 8:20:03 AM UTC+2, Alberto Salvadori wrote:
>
> Thank you, Praveen.
>
> While installing deal.ii all detailed instructions on the spack wiki page 
> have been followed. I cloned spack from git (I thus assume it is the latest 
> version) and made no modifications (yet :-) ) to the 
>  “.spack/linux/packages.yaml” file. By the way, I did install deal.ii on 
> opensuse a couple of weeks ago without this issue.
>
> Shall I attach my  “.spack/linux/packages.yaml”  here?
>
> Alberto 
>
>
> *Alberto Salvadori* Dipartimento di Ingegneria Civile, Architettura, 
> Territorio, Ambiente e di Matematica (DICATAM)
>  Universita` di Brescia, via Branze 43, 25123 Brescia
>  Italy
>  tel 030 3711239
>  fax 030 3711312
>
> e-mail: 
>  alberto@unibs.it 
> web-pages:
>  http://m4lab.unibs.it/faculty.html
>  http://dicata.ing.unibs.it/salvadori
>
>
> On Mon, Oct 22, 2018 at 8:08 AM Praveen C > 
> wrote:
>
>> When I check spec on my opensuse machine, dealii@9.0.1 wants to use 
>> suite-sparse@5.3.0
>>
>> Have you perhaps already set some versions in your 
>> “.spack/linux/packages.yaml” file ?
>>
>> What does your file look like ?
>>
>> Also, you may want to update your spack to see it that fixes it.
>>
>> Thanks
>> praveen
>>
>> On 22-Oct-2018, at 11:20 AM, Alberto Salvadori > > wrote:
>>
>> Dear community
>>
>> I am installing deal.ii (latest release) on a CentOS7 equipped machine. 
>> After typing
>>
>> spack install --test=root dealii
>>
>> I see this error:
>>
>> ==> Error: An unsatisfiable version constraint has been detected for spec:
>>
>> suite-sparse@5.3.0%gcc@4.8.5~cuda~openmp+pic~tbb 
>> arch=linux-centos7-x86_64 
>>
>>
>> while trying to concretize the partial spec:
>>
>> dealii@9.0.1%gcc@4.8.5+adol-c+arpack+assimp build_type=DebugRelease 
>> ~cuda cuda_arch= 
>> ~doc+gmsh+gsl+hdf5~int64+metis+mpi+nanoflann+netcdf+oce~optflags+p4est+petsc~python+scalapack+slepc+sundials+trilinos
>>  arch=linux-centos7-x86_64 
>> ^adol-c@2.6.4:
>> ^arpack-ng+mpi
>> ^mpi
>> ^openblas@0.3.3%gcc@4.8.5 cpu_target= ~ilp64+pic+shared 
>> threads=none ~virtual_machine arch=linux-centos7-x86_64 
>> ^assimp
>> 
>> ^boost@1.59.0:1.63,1.65.1,1.67.0:+iostreams+serialization+system+thread
>> ^bzip2
>> ^diffutils
>> ^zlib@1.2.11%gcc@4.8.5+optimize+pic+shared 
>> arch=linux-centos7-x86_64 
>> ^cmake@3.12.2%gcc@4.8.5~doc+ncurses+openssl+ownlibs~qt 
>> arch=linux-centos7-x86_64 
>> ^ncurses
>> ^pkgconfig
>> ^openssl
>> ^perl@5.14.0:
>> ^gdbm
>> ^readline
>> ^gmsh+netgen+oce+tetgen
>> ^gmp
>> ^autoconf
>> ^m4@1.4.6:
>> ^automake
>> ^libtool@2.4.2:
>> ^netgen
>> ^oce
>> ^tetgen
>> ^hdf5@1.8.9:+hl+mpi
>> ^intel-tbb@2019%gcc@4.8.5 cxxstd=default +shared+tm 
>> arch=linux-centos7-x86_64 
>> ^metis@5:~int64+real64
>> ^muparser@2.2.5%gcc@4.8.5 arch=linux-centos7-x86_64 
>> ^nanoflann
>> ^netcdf+mpi
>> ^p4est
>> ^sundials~pthread
>> ^trilinos+amesos+aztec+epetra+ifpack+ml+muelu+sacado+teuchos
>> ^glm
>> ^matio
>>
>>
>> dealii requires suite-sparse version :5.1.0, but spec asked for 5.3.0
>>
>> I wonder which is the source of the error and which files ( 
>> ~/.spack/linux/packages.yaml perhaps?)
>> shall I edit to sort out the issue.
>>
>> Many thanks in advance
>>
>> Alberto
>>
>>
>>
>>
>>
>> Informativa sulla Privacy: http://www.unibs.it/node/8155
>>
>> -- 
>> 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+un...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> -- 
>> 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 

Re: [deal.II] Error in installing deal.ii with spack on CentOs7

[Denis Davydov]

Yes, JP is correct that it has to do with incompatible requirements on 
suitesparse from Trilinos and latest release of PETSc. 
To overcome this I recently disabled suitesparse by default in Trilinos, but it 
could be that the commit hash we recommend currently on wiki does not have 
this. I will check it later today and update wiki if needed.

Regards,
Denis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Question on resolving chains of constraints containing both periodic and hanging node constraints

[Denis Davydov]

Thanks for the MWE, Sambit.

I created a Github issue to track this 
further https://github.com/dealii/dealii/issues/7053 

Denis.

On Monday, August 13, 2018 at 12:01:07 AM UTC+2, Sambit Das wrote:
>
> Dear Prof. Bangerth,
>
> I have now reproduced the above issue in the attached minimal example.
>
> Below is the algorithm of the minimal example 
>
> 1) Create a hypercube (-20,20) with origin at the center
>
> 2) Set periodic boundary conditions on all faces of the hypercube
>
> 3) Refine mesh by first doing global refinement once to get 8 cells and 
> then refine 
> the cell containing the corner (-20,-20,-20) two times iteratively. 
> Finally I get 71 cells (see attached image)
> with hanging nodes on three faces.
>
> 4) Create constraint matrix with both hanging node and periodic 
> constraints, and call close().
>
> 5) Print the constraint equation (j,a_ij) for global dof id-52 on 
> processors for which global dof id-52 is relevant, when run on two mpi 
> tasks:
>
>$ mpirun -n 2 ./minimalExample
>
>number of elements: 71
>taskId: 1, globalDofId-i: 52, coordinates-i: -20 20 -10, globalDofId-j: 
> 16, coordinates-j: -20 -20 -10, scalarCoeff-aij: 1
>taskId: 0, globalDofId-i: 52, coordinates-i: -20 20 -10, globalDofId-j: 
> 32, coordinates-j: 20 -20 -10, scalarCoeff-aij: 1
>   
>Clearly "j" in the constraint equation is different across processors 
> for the same constrained global dof id.
>
> Thank you,
> Sambit
>
> On Friday, August 10, 2018 at 9:39:58 AM UTC-5, Sambit Das wrote:
>>
>> Dear Prof. Bangerth,
>>
>> Yes, they should really be the same. Or, more correctly, if two 
>>> processors 
>>> both store the constraints for a node, they better be the same. On the 
>>> other 
>>> hand, of course not every processor will know every constraint. 
>>>
>>
>> Thanks you for clarifying this.
>>
>>  Can you try to construct a minimal testcase for what you observe? 
>>
>>
>> Yes, I am going to construct a minimal test case .
>>
>> Best,
>> Sambit 
>>
>> On Thursday, August 9, 2018 at 11:33:13 PM UTC-5, Wolfgang Bangerth wrote:
>>>
>>>
>>> > I created a ConstraintMatrix with both periodic and hanging node 
>>> constraints, 
>>> > and called close(). 
>>> > 
>>> > Then I pickeda constrained degree of freedom, lets say with global dof 
>>> id = 
>>> > “i” and printed the constraint equation pairs (j,a_ij) corresponding 
>>> to “i” on 
>>> > the processor for which “i” is locally owned as well as the processors 
>>> for 
>>> > which “i” is a ghost. I expected the constraint equation to be the 
>>> same for 
>>> > owning processor and the ghost processor, howeverwe have encountered a 
>>> case 
>>> > where printing the constraint equation entries shows different “j” for 
>>> owning 
>>> > and ghost processorsalthough a_ij are same. When we printed the 
>>> coordinates of 
>>> > “j” which were different, we found that those two nodes to be periodic 
>>> images 
>>> > of each other. 
>>> > 
>>> > 
>>> > Should I except the constraint equation to be the same for the owning 
>>> > processor and the ghost processors? 
>>>
>>> Yes, they should really be the same. Or, more correctly, if two 
>>> processors 
>>> both store the constraints for a node, they better be the same. On the 
>>> other 
>>> hand, of course not every processor will know every constraint. 
>>>
>>> Can you try to construct a minimal testcase for what you observe? 
>>>
>>> Best 
>>>   Wolfgang 
>>>
>>>
>>> -- 
>>>  
>>> Wolfgang Bangerth  email: bang...@colostate.edu 
>>> www: 
>>> http://www.math.colostate.edu/~bangerth/ 
>>>
>>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Linear Elastic Fracture Mechanics

[Denis Davydov]

Hi Francesca,

As for the continuous enrichment part of X-FEM (i.e. crack-tip) you can 
look into FE_Enriched 
 class 
and the paper with implementation details. 
Note the key difference in point-of-view: FE_Enriched does cell-based 
enrichment, i.e. all nodes will be enriched the same way 
with given function(s). One can still mix things with FE_Nothing to have 
different enrichment with different parts of the domain to
get conforming FE space. This PR 
 from my student will make it 
easier to do. 
For the discontinuous part (Heaviside) FE_Enriched might be ok as well, but 
I guess in this case construction of quadrature rule and integration is the 
major PITA.

Regards,
Denis

On Wednesday, May 23, 2018 at 11:47:52 AM UTC+2, Francesca Fantoni wrote:
>
> Good morning everyone,
> I am currently working on crack tracking algorithms in the context of 
> Linear Elastic Fracture Mechanics for three dimensional problems.
> I was wondering if in deal.ii  there exists any code gallery related to 
> the implementation of quarter-point elements and the computation of SIFs 
> along the Crack front.
> Alternatively if there exists some code related to the use of X-FEM for 
> fracture mechanics.
> I am not able to find any code related to these problems...I found some 
> codes related to the use of the phase field method in fracture mechanics, 
> but we are interested in using a different approach to model the presence 
> of the crack.
> Could anyone kindly guide me?
> Thanks very much
> Francesca
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Mac OS X 10.13.4 Installation problem

[Denis Davydov]

Hi Jon,

Try this .dmg https://github.com/luca-heltai/dealii/releases/tag/v9.0.0-rc1 
If that won't work, you can try building with 
Spack https://github.com/dealii/dealii/wiki/deal.II-in-Spack that's what I 
use on macOS.
You would need to first compile gcc with it, see the wiki page.

Regards,
Denis.

On Thursday, May 10, 2018 at 8:22:58 PM UTC+2, mrjonm...@gmail.com wrote:
>
> Hi all,
> I want to be able to run step-40 on my Mac, but the installation using the 
> .dmg doesn't have PETSc and p4est turned on.
>
> I'm trying to build 8.5.1 starting with the following cmake command:
>
> *~/Library/dealii/sources/build*$ cmake 
> -DCMAKE_INSTALL_PREFIX=/Users/matthejl/Library/dealii 
> -DDEAL_II_WITH_PETSC=ON -DDEAL_II_WITH_P4EST=ON 
> -DPETSC_DIR=/Users/matthejl/Library/petsc/petsc-3.9.0/ 
> -DPETSC_ARCH=arch-darwin-c-debug 
> -DP4EST_DIR=/Users/matthejl/Library/p4est-2.0/local -DDEAL_II_WITH_HDF5=OFF 
> ../dealii-8.5.1/
>
>
> It seems to have a problem compiling the simple test program:
>
> CMake Error at cmake/setup_finalize.cmake:95 (MESSAGE):
>
>   
>
>
> Configuration error: Cannot compile a test program with the final set 
> of
>
> compiler and linker flags:
>
>   CXX flags (DEBUG): -pedantic -fPIC -Wall -Wextra -Wpointer-arith 
> -Wwrite-strings -Wsynth -Wsign-compare -Wswitch -Woverloaded-virtual 
> -Wno-long-long -Wno-implicit-fallthrough -Wno-deprecated-declarations 
> -Qunused-arguments -Wno-unsupported-friend -Wno-unused-parameter 
> -Wno-unused-variable -Wno-c99-extensions -Wno-variadic-macros 
> -Wno-c++11-extensions -Wno-undefined-var-template -openmp-simd -std=c++14 
> -ftemplate-depth=1024 -Wno-parentheses -Wno-unused-local-typedefs -Og -ggdb 
> -Wa,--compress-debug-sections
>
>   LD flags  (DEBUG): -Wl,-headerpad_max_install_names 
> -Wl,-flat_namespace -Wl,-commons,use_dylibs -ggdb
>
>   LIBRARIES (DEBUG): 
> /usr/lib/libbz2.dylib;/usr/lib/libz.dylib;/Users/matthejl/Library/petsc/petsc-3.9.0/arch-darwin-c-debug/lib/libpetsc.dylib;/Users/matthejl/Library/petsc/petsc-3.9.0/arch-darwin-c-debug/lib/libHYPRE.a;/usr/lib/liblapack.dylib;/usr/lib/libblas.dylib;/opt/local/lib/mpich-mp/libmpifort.dylib;/opt/local/lib/gcc5/libgcc_ext.10.5.dylib;/usr/lib/libc++.dylib;/opt/local/lib/mpich-mp/libmpicxx.dylib;/System/Library/Frameworks/System.framework;dl;/opt/local/lib/libboost_iostreams-mt.dylib;/opt/local/lib/libboost_serialization-mt.dylib;/opt/local/lib/libboost_system-mt.dylib;/opt/local/lib/libboost_thread-mt.dylib;/opt/local/lib/libboost_regex-mt.dylib;/opt/local/lib/libboost_chrono-mt.dylib;/opt/local/lib/libboost_date_time-mt.dylib;/opt/local/lib/libboost_atomic-mt.dylib;/Users/matthejl/Library/p4est-2.0/local/lib/libp4est.dylib;/Users/matthejl/Library/p4est-2.0/local/lib/libsc.dylib;/System/Library/Frameworks/Accelerate.framework;/opt/local/lib/libf77blas.a;/opt/local/lib/libatlas.a;m;/opt/local/lib/mpich-mp/libmpi.dylib;/opt/local/lib/mpich-mp/libpmpi.dylib;
>
> 
> Attached are my output and error logs for reference. 
> Thanks,
> Jon
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Mac testers wanted

[Denis Davydov]

Luca, 

the link does not seem to contain dmg. 
You probably wanted to give a link to your fork, i.e. 
https://github.com/luca-heltai/dealii/releases/tag/v9.0.0-rc1 

Cheers,
Denis

On Sunday, May 6, 2018 at 11:51:19 AM UTC+2, Luca Heltai wrote:
>
> Sorry. The address is the following:
>
> https://github.com/dealii/dealii/releases/v9.0.0-rc2
>
> Luca
>
> Il giorno 06 mag 2018, alle ore 11:30, luca.heltai  > ha scritto:
>
> Dear all, 
>
> I have just uploaded a new package for deal.II-9.0.0-rc2 here:
>
> https://github.com/dealii/dealii/releases/edit/v9.0.0-rc2
>
> This was compiled with Apple clang 9.1.0, and gfortran from gcc 7.3.
>
> Please test, and let me know if everything is ok.
>
> Best,
> Luca.
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: cmake . returns error on MAC OS XI Captain version 10.11.6 upon compiling dealii-8.5.0-brew.dmg

[Denis Davydov]

you can also try a pre-release package from this post: 

https://groups.google.com/forum/?fromgroups=#!topic/dealii/uvgXWCwAIlY 

On Friday, May 11, 2018 at 10:53:32 PM UTC+2, Wakil Sarfaraz wrote:
>
> Hi Denis,
> Xcode is installed on my machine. It is just that I deleted the dmg files 
> associated to previous versions of deal.ii and cmake, which was perfectly 
> working.
> When I downloaded the new versions today, it returned these errors.
>
> Best,
> Wakil 
>
> On Friday, May 11, 2018 at 9:04:17 PM UTC+1, Denis Davydov wrote:
>>
>> Hi,
>>
>> Make sure you have XCode installed as well as command line 
>> tools: xcode-select --install
>>
>> Regards,
>> Denis.
>>
>> On Friday, May 11, 2018 at 7:36:48 PM UTC+2, Wakil Sarfaraz wrote:
>>>
>>> Hi all,
>>> I have been away from deal.ii for almost two years.
>>> I have come back and wanted to install the most updated version which is 
>>> dealii-8.5.0-brew.dmg 
>>> <https://github.com/dealii/dealii/releases/download/v8.5.0/dealii-8.5.0-brew.dmg>
>>> When I attempted to cmake the step-1 of the examples, it returns error 
>>> containing the following texts:
>>>
>>> -- The C compiler identification is unknown
>>>
>>> -- The CXX compiler identification is unknown
>>>
>>> CMake Error at CMakeLists.txt:38 (PROJECT):
>>>
>>>   The CMAKE_C_COMPILER:
>>>
>>>
>>> 
>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
>>>
>>>
>>>   is not a full path to an existing compiler tool.
>>>
>>>
>>>   Tell CMake where to find the compiler by setting either the 
>>> environment
>>>
>>>   variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full 
>>> path to
>>>
>>>   the compiler, or to the compiler name if it is in the PATH.
>>>
>>>
>>>
>>> -- Check for working CXX compiler: 
>>> /Applications/deal.II-8.5-brew.app/Contents/Resources/brew/bin/mpicxx
>>>
>>> -- Check for working CXX compiler: 
>>> /Applications/deal.II-8.5-brew.app/Contents/Resources/brew/bin/mpicxx -- 
>>> broken
>>>
>>> CMake Error at 
>>> /Applications/CMake.app/Contents/share/cmake-3.11/Modules/CMakeTestCXXCompiler.cmake:45
>>>  
>>> (message):
>>>
>>>   The C++ compiler
>>>
>>>
>>> 
>>> "/Applications/deal.II-8.5-brew.app/Contents/Resources/brew/bin/mpicxx"
>>>
>>>
>>>   is not able to compile a simple test program.
>>>
>>>
>>>   It fails with the following output:
>>>
>>>
>>> Change Dir: 
>>> /Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/CMakeFiles/CMakeTmp
>>>
>>> 
>>>
>>> Run Build Command:"/usr/bin/make" "cmTC_a4024/fast"
>>>
>>> /Library/Developer/CommandLineTools/usr/bin/make -f 
>>> CMakeFiles/cmTC_a4024.dir/build.make CMakeFiles/cmTC_a4024.dir/build
>>>
>>> Building CXX object CMakeFiles/cmTC_a4024.dir/testCXXCompiler.cxx.o
>>>
>>> /Applications/deal.II-8.5-brew.app/Contents/Resources/brew/bin/mpicxx 
>>> -o CMakeFiles/cmTC_a4024.dir/testCXXCompiler.cxx.o -c 
>>> /Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
>>>
>>> make[1]: *** [CMakeFiles/cmTC_a4024.dir/testCXXCompiler.cxx.o] 
>>> Illegal instruction: 4
>>>
>>> make: *** [cmTC_a4024/fast] Error 2
>>>
>>> 
>>>
>>>
>>>   
>>>
>>>
>>>   CMake will not be able to correctly generate this project.
>>>
>>> Call Stack (most recent call first):
>>>
>>>   CMakeLists.txt:38 (PROJECT)
>>>
>>>
>>>
>>> -- Configuring incomplete, errors occurred!
>>>
>>> See also 
>>> "/Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/CMakeFiles/CMakeOutput.log".
>>>
>>> See also 
>>> "/Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/CMakeFiles/CMakeError.log".
>>>
>>> localhost:step-1 wakilsarfaraz$ 
>>>
>>> I will greatly appreciate your help on this.
>>>
>>> Regards,
>>>
>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: cmake . returns error on MAC OS XI Captain version 10.11.6 upon compiling dealii-8.5.0-brew.dmg

[Denis Davydov]

Hi Wakil,

so command line tools are installed, did you check?

CMake tells you the error: 

 The CMAKE_C_COMPILER:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.
xctoolchain/usr/bin/cc

  is not a full path to an existing compiler tool.

so see whether you have this or not. Perhaps something changes in between 
macOS versions, I won't be surprized. The dmg you download are built with 
specific version (probably Sierra or High Sierra) using Apple's clang. So 
if location of compiler changes between those versions, then there is a 
problem. 

Regards,

Denis

On Friday, May 11, 2018 at 10:53:32 PM UTC+2, Wakil Sarfaraz wrote:
>
> Hi Denis,
> Xcode is installed on my machine. It is just that I deleted the dmg files 
> associated to previous versions of deal.ii and cmake, which was perfectly 
> working.
> When I downloaded the new versions today, it returned these errors.
>
> Best,
> Wakil 
>
> On Friday, May 11, 2018 at 9:04:17 PM UTC+1, Denis Davydov wrote:
>>
>> Hi,
>>
>> Make sure you have XCode installed as well as command line 
>> tools: xcode-select --install
>>
>> Regards,
>> Denis.
>>
>> On Friday, May 11, 2018 at 7:36:48 PM UTC+2, Wakil Sarfaraz wrote:
>>>
>>> Hi all,
>>> I have been away from deal.ii for almost two years.
>>> I have come back and wanted to install the most updated version which is 
>>> dealii-8.5.0-brew.dmg 
>>> <https://github.com/dealii/dealii/releases/download/v8.5.0/dealii-8.5.0-brew.dmg>
>>> When I attempted to cmake the step-1 of the examples, it returns error 
>>> containing the following texts:
>>>
>>> -- The C compiler identification is unknown
>>>
>>> -- The CXX compiler identification is unknown
>>>
>>> CMake Error at CMakeLists.txt:38 (PROJECT):
>>>
>>>   The CMAKE_C_COMPILER:
>>>
>>>
>>> 
>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
>>>
>>>
>>>   is not a full path to an existing compiler tool.
>>>
>>>
>>>   Tell CMake where to find the compiler by setting either the 
>>> environment
>>>
>>>   variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full 
>>> path to
>>>
>>>   the compiler, or to the compiler name if it is in the PATH.
>>>
>>>
>>>
>>> -- Check for working CXX compiler: 
>>> /Applications/deal.II-8.5-brew.app/Contents/Resources/brew/bin/mpicxx
>>>
>>> -- Check for working CXX compiler: 
>>> /Applications/deal.II-8.5-brew.app/Contents/Resources/brew/bin/mpicxx -- 
>>> broken
>>>
>>> CMake Error at 
>>> /Applications/CMake.app/Contents/share/cmake-3.11/Modules/CMakeTestCXXCompiler.cmake:45
>>>  
>>> (message):
>>>
>>>   The C++ compiler
>>>
>>>
>>> 
>>> "/Applications/deal.II-8.5-brew.app/Contents/Resources/brew/bin/mpicxx"
>>>
>>>
>>>   is not able to compile a simple test program.
>>>
>>>
>>>   It fails with the following output:
>>>
>>>
>>> Change Dir: 
>>> /Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/CMakeFiles/CMakeTmp
>>>
>>> 
>>>
>>> Run Build Command:"/usr/bin/make" "cmTC_a4024/fast"
>>>
>>> /Library/Developer/CommandLineTools/usr/bin/make -f 
>>> CMakeFiles/cmTC_a4024.dir/build.make CMakeFiles/cmTC_a4024.dir/build
>>>
>>> Building CXX object CMakeFiles/cmTC_a4024.dir/testCXXCompiler.cxx.o
>>>
>>> /Applications/deal.II-8.5-brew.app/Contents/Resources/brew/bin/mpicxx 
>>> -o CMakeFiles/cmTC_a4024.dir/testCXXCompiler.cxx.o -c 
>>> /Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
>>>
>>> make[1]: *** [CMakeFiles/cmTC_a4024.dir/testCXXCompiler.cxx.o] 
>>> Illegal instruction: 4
>>>
>>> make: *** [cmTC_a4024/fast] Error 2
>>>
>>> 
>>>
>>>
>>>   
>>>
>>>
>>>   CMake will not be able to correctly generate this project.
>>>
>>> Call Stack (most recent call first):
>>>
>>>   CMakeLists.txt:38 (PROJECT)
>>>
>>>
>>>
>>> -- Configuring incomplete, errors occurred!
>>>
>>> See also 
>>> "/Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/CMakeFiles/CMakeOutput.log".
>>>
>>> See also 
>>> "/Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/CMakeFiles/CMakeError.log".
>>>
>>> localhost:step-1 wakilsarfaraz$ 
>>>
>>> I will greatly appreciate your help on this.
>>>
>>> Regards,
>>>
>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: cmake . returns error on MAC OS XI Captain version 10.11.6 upon compiling dealii-8.5.0-brew.dmg

[Denis Davydov]

Hi,

Make sure you have XCode installed as well as command line 
tools: xcode-select --install

Regards,
Denis.

On Friday, May 11, 2018 at 7:36:48 PM UTC+2, Wakil Sarfaraz wrote:
>
> Hi all,
> I have been away from deal.ii for almost two years.
> I have come back and wanted to install the most updated version which is 
> dealii-8.5.0-brew.dmg 
> 
> When I attempted to cmake the step-1 of the examples, it returns error 
> containing the following texts:
>
> -- The C compiler identification is unknown
>
> -- The CXX compiler identification is unknown
>
> CMake Error at CMakeLists.txt:38 (PROJECT):
>
>   The CMAKE_C_COMPILER:
>
>
> 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
>
>
>   is not a full path to an existing compiler tool.
>
>
>   Tell CMake where to find the compiler by setting either the environment
>
>   variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full 
> path to
>
>   the compiler, or to the compiler name if it is in the PATH.
>
>
>
> -- Check for working CXX compiler: 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/brew/bin/mpicxx
>
> -- Check for working CXX compiler: 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/brew/bin/mpicxx -- 
> broken
>
> CMake Error at 
> /Applications/CMake.app/Contents/share/cmake-3.11/Modules/CMakeTestCXXCompiler.cmake:45
>  
> (message):
>
>   The C++ compiler
>
>
> 
> "/Applications/deal.II-8.5-brew.app/Contents/Resources/brew/bin/mpicxx"
>
>
>   is not able to compile a simple test program.
>
>
>   It fails with the following output:
>
>
> Change Dir: 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/CMakeFiles/CMakeTmp
>
> 
>
> Run Build Command:"/usr/bin/make" "cmTC_a4024/fast"
>
> /Library/Developer/CommandLineTools/usr/bin/make -f 
> CMakeFiles/cmTC_a4024.dir/build.make CMakeFiles/cmTC_a4024.dir/build
>
> Building CXX object CMakeFiles/cmTC_a4024.dir/testCXXCompiler.cxx.o
>
> /Applications/deal.II-8.5-brew.app/Contents/Resources/brew/bin/mpicxx   
>   -o CMakeFiles/cmTC_a4024.dir/testCXXCompiler.cxx.o -c 
> /Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
>
> make[1]: *** [CMakeFiles/cmTC_a4024.dir/testCXXCompiler.cxx.o] 
> Illegal instruction: 4
>
> make: *** [cmTC_a4024/fast] Error 2
>
> 
>
>
>   
>
>
>   CMake will not be able to correctly generate this project.
>
> Call Stack (most recent call first):
>
>   CMakeLists.txt:38 (PROJECT)
>
>
>
> -- Configuring incomplete, errors occurred!
>
> See also 
> "/Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/CMakeFiles/CMakeOutput.log".
>
> See also 
> "/Applications/deal.II-8.5-brew.app/Contents/Resources/examples/step-1/CMakeFiles/CMakeError.log".
>
> localhost:step-1 wakilsarfaraz$ 
>
> I will greatly appreciate your help on this.
>
> Regards,
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Why fe.shape_value( const unsigned int i, const Point< dim > & p ) return a negative number?

[Denis Davydov]

Hi,

it's perfectly fine for a general FE shape functions to be negative at some 
points, that's clearly the case for quadratic
http://hplgit.github.io/INF5620/doc/pub/sphinx-fem/._main_fem003.html#fem-approx-fe-fig-p2
 

Denis.

On Saturday, May 5, 2018 at 3:11:24 AM UTC+2, Zhao Yidong wrote:
>
> Hi everyone!
> I use fe, which is FESystem class, but I find fe.shape_value( const 
> unsigned int i, const Point< dim > & p ) (the document is here: 
> https://www.dealii.org/8.5.0/doxygen/deal.II/classFE__Poly.html#a8c769a449d25d54e756fc67cca5dd30b)
>  
> sometimes returns a negative number which seems not right.
>
> The Point I send into the function locates in the reference space ( [-1, 
> 1]x[-1, 1] ), I also try the Point in the real space, but also get negative 
> numbers sometimes.
>
> Thanks any response!
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: New step tutorial elastic wave equation with PMLs, complex-valued algebra

[Denis Davydov]

> On 30 Apr 2018, at 04:54, Wolfgang Bangerth <bange...@colostate.edu> wrote:
> 
> On 04/28/2018 10:36 PM, Denis Davydov wrote:
>> As far as as recall there just a few things left related to complex numbers.
>> The biggest one is complex-valued Dirichlet constraints in ConstraintMatrix 
>> object
>> https://github.com/dealii/dealii/issues/1760
>> That's not possible yet. Otherwise all the solvers and linear algebra is 
>> ready. So you can certainly assemble system and solve it.
> 
> Denis -- out of curiosity, what solver are you using for complex-valued 
> linear systems? I don't think the deal.II SolverGMRES class works, and 
> obviously the other iterative solvers don't either. Nor does UMFPACK.

I would not be so sure about it, but I have not tried either.
I am quite certain complex-valued PETSc will work.

ps. I don’t use any of them, some time ago I invested a lot of efforts to push 
forward
complex-valued algebra in deal.II (which was also followed by others), but 
strangely enough I never used it. 

> 
> Best
> W.
> 
> -- 
> 
> Wolfgang Bangerth  email: bange...@colostate.edu
>   www: http://www.math.colostate.edu/~bangerth/
> 
> -- 
> 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 a topic in the 
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/dealii/N-V-8geRLrA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> dealii+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: New step tutorial elastic wave equation with PMLs, complex-valued algebra

[Denis Davydov]

Hi Daniel,

Thanks for willing to contribute the tutorial.

As far as as recall there just a few things left related to complex 
numbers. 
The biggest one is complex-valued Dirichlet constraints in ConstraintMatrix 
object
https://github.com/dealii/dealii/issues/1760 
That's not possible yet. Otherwise all the solvers and linear algebra is 
ready. So you can certainly assemble system and solve it.

Denis.

On Saturday, April 28, 2018 at 11:49:40 AM UTC+2, Daniel Garcia wrote:
>
> Hi,
>
> I'm a researcher at the CNRS (Paris). My nickname in GitHub is dangars (I 
> contributed with a couple of pull requests)
>
> I work in optomechanics/phononics. I've been using deal.ii for 6 months 
> and it works great! I developed a model of the elastic wave equation in 2D 
> that uses PMLs.
>
> I'm preparing a contribution of a new step tutorial of the elastic wave 
> equation with PMLs in 3D to GitHub/dealii. This will be useful for the 
> phononics and optomechanics communities.
>
> The separation real/imag works very well with PMLs.
>
> The elastic/PML matrix with real/imag separation is big. If I use complex 
> numbers the matrix will be compact and will fit in one line (much better 
> for a step tutorial)
>
> What is the status of complex valued calculations? Is it ready to solve a 
> differential equations? Is there a performance penalty with complex numbers 
> vs separate real/imag parts?
>
> According to this, it seems to be almost ready:
> https://github.com/dealii/dealii/projects/1
>
> Thanks,
> Daniel Garcia
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: error running after update

[Denis Davydov]

p.s. given recent updates to petsc/slepc 3.9 you would need to install a 
current development version of deal.II, i.e.
spack install dealii@develop
The soon-to-be-release 9.0 will support new petsc/slepc.

On Wednesday, April 25, 2018 at 12:04:06 AM UTC+2, Denis Davydov wrote:
>
> @Jane
>
> If you need to get it going soon, try following 
> https://github.com/dealii/dealii/wiki/deal.II-in-Spack 
> Roughly it's only 3 steps (assuming that you have XCode and command-line 
> tools):
> 1. install gcc with spack
> 2. configure gfortran to be used with clang 
> http://spack.readthedocs.io/en/latest/getting_started.html#mixed-toolchains 
>  
> 3. install dealii
>
> Let me know if you have issues, I am running this setup on the latest 
> XCode/ Apple's clang without issues.
>
> @Daniel
>
> It's used from the pre-build app by Luca
>
> Denis.
>
> On Tuesday, April 24, 2018 at 5:36:21 PM UTC+2, Daniel Arndt wrote:
>>
>> Jane,
>>
>> this looks like you are using a compiler (clang on macOS?) that doesn't 
>> define std::auto_ptr anymore and the used boost library doesn't detect this.
>> A recent developer version (there will soon be a release) should 
>> circumvent the problem.
>> How did you install deal.II? Are you using spack directly or a 
>> pre-compiled package?
>> If you are using spack directly you should just rerun it to get a recent 
>> developer version.
>>
>> Best,
>> Daniel
>>
>>
>> Am Dienstag, 24. April 2018 16:14:51 UTC+2 schrieb Jane Lee:
>>>
>>> Hi all,
>>> I'm unfortunately not very good with computers and the nitty gritty 
>>> details of the things that go on behind the program. 
>>> I'm running dealii-9.0 instead of 8.5.1 because i did a system update 
>>> and 8.5.1 wasn't working. 
>>> I stupidly did a minor update forgetting that i had issues after updates 
>>> previously, and the same code which i was running fine just before the 
>>> update and restart is now not working when 'make run' is done.
>>> The error is a bit too complicated for me to understand... 
>>> can anyone help? Am desperate to get things up and running
>>>
>>> In file included from 
>>> /Applications/deal.II-9.0-spack.app/Contents/Resources/include/deal.II/base/convergence_table.h:21:
>>>
>>> In file included from 
>>> /Applications/deal.II-9.0-spack.app/Contents/Resources/include/deal.II/base/table_handler.h:31:
>>>
>>> In file included from 
>>> /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/serialization/map.hpp:24:
>>>
>>> In file included from 
>>> /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/archive/detail/basic_iarchive.hpp:23:
>>>
>>> In file included from 
>>> /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/scoped_ptr.hpp:14:
>>>
>>> */Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/smart_ptr/scoped_ptr.hpp:74:31:
>>>  
>>> **error: *
>>>
>>> *  no template named 'auto_ptr' in namespace 'std'*
>>>
>>> explicit scoped_ptr( std::auto_ptr p ) BOOST_NOEXCEPT : px( 
>>> p.release() )
>>>
>>> * ~^*
>>>
>>> In file included from 
>>> /Users/janelee/Documents/fullmodel/full_solver/final/stokes.cc:7:
>>>
>>> In file included from 
>>> /Applications/deal.II-9.0-spack.app/Contents/Resources/include/deal.II/base/convergence_table.h:21:
>>>
>>> In file included from 
>>> /Applications/deal.II-9.0-spack.app/Contents/Resources/include/deal.II/base/table_handler.h:31:
>>>
>>> In file included from 
>>> /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/serialization/map.hpp:24:
>>>
>>> In file included from 
>>> /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/archive/detail/basic_iarchive.hpp:28:
>>>
>>> In file included from 
>>> /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/archive/detail/helper_collection.hpp:27:
>>>
>>> In file included from 
>>> /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/smart_ptr/shared_ptr.hpp:28:
>>>
>>> */Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/smart_ptr/detail/shared_count.hpp:402:33:
>>>  
>>> **error: *
>>>
>>> *  no template named '

[deal.II] Re: error running after update

[Denis Davydov]

@Jane

If you need to get it going soon, try 
following https://github.com/dealii/dealii/wiki/deal.II-in-Spack 
Roughly it's only 3 steps (assuming that you have XCode and command-line 
tools):
1. install gcc with spack
2. configure gfortran to be used with 
clang 
http://spack.readthedocs.io/en/latest/getting_started.html#mixed-toolchains 
 
3. install dealii

Let me know if you have issues, I am running this setup on the latest 
XCode/ Apple's clang without issues.

@Daniel

It's used from the pre-build app by Luca

Denis.

On Tuesday, April 24, 2018 at 5:36:21 PM UTC+2, Daniel Arndt wrote:
>
> Jane,
>
> this looks like you are using a compiler (clang on macOS?) that doesn't 
> define std::auto_ptr anymore and the used boost library doesn't detect this.
> A recent developer version (there will soon be a release) should 
> circumvent the problem.
> How did you install deal.II? Are you using spack directly or a 
> pre-compiled package?
> If you are using spack directly you should just rerun it to get a recent 
> developer version.
>
> Best,
> Daniel
>
>
> Am Dienstag, 24. April 2018 16:14:51 UTC+2 schrieb Jane Lee:
>>
>> Hi all,
>> I'm unfortunately not very good with computers and the nitty gritty 
>> details of the things that go on behind the program. 
>> I'm running dealii-9.0 instead of 8.5.1 because i did a system update and 
>> 8.5.1 wasn't working. 
>> I stupidly did a minor update forgetting that i had issues after updates 
>> previously, and the same code which i was running fine just before the 
>> update and restart is now not working when 'make run' is done.
>> The error is a bit too complicated for me to understand... 
>> can anyone help? Am desperate to get things up and running
>>
>> In file included from 
>> /Applications/deal.II-9.0-spack.app/Contents/Resources/include/deal.II/base/convergence_table.h:21:
>>
>> In file included from 
>> /Applications/deal.II-9.0-spack.app/Contents/Resources/include/deal.II/base/table_handler.h:31:
>>
>> In file included from 
>> /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/serialization/map.hpp:24:
>>
>> In file included from 
>> /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/archive/detail/basic_iarchive.hpp:23:
>>
>> In file included from 
>> /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/scoped_ptr.hpp:14:
>>
>> */Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/smart_ptr/scoped_ptr.hpp:74:31:
>>  
>> **error: *
>>
>> *  no template named 'auto_ptr' in namespace 'std'*
>>
>> explicit scoped_ptr( std::auto_ptr p ) BOOST_NOEXCEPT : px( 
>> p.release() )
>>
>> * ~^*
>>
>> In file included from 
>> /Users/janelee/Documents/fullmodel/full_solver/final/stokes.cc:7:
>>
>> In file included from 
>> /Applications/deal.II-9.0-spack.app/Contents/Resources/include/deal.II/base/convergence_table.h:21:
>>
>> In file included from 
>> /Applications/deal.II-9.0-spack.app/Contents/Resources/include/deal.II/base/table_handler.h:31:
>>
>> In file included from 
>> /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/serialization/map.hpp:24:
>>
>> In file included from 
>> /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/archive/detail/basic_iarchive.hpp:28:
>>
>> In file included from 
>> /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/archive/detail/helper_collection.hpp:27:
>>
>> In file included from 
>> /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/smart_ptr/shared_ptr.hpp:28:
>>
>> */Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/smart_ptr/detail/shared_count.hpp:402:33:
>>  
>> **error: *
>>
>> *  no template named 'auto_ptr' in namespace 'std'*
>>
>> explicit shared_count( std::auto_ptr & r ): pi_( new 
>> sp_counted_i...
>>
>> *   ~^*
>>
>> In file included from 
>> /Users/janelee/Documents/fullmodel/full_solver/final/stokes.cc:7:
>>
>> In file included from 
>> /Applications/deal.II-9.0-spack.app/Contents/Resources/include/deal.II/base/convergence_table.h:21:
>>
>> In file included from 
>> /Applications/deal.II-9.0-spack.app/Contents/Resources/include/deal.II/base/table_handler.h:31:
>>
>> In file included from 
>> /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/serialization/map.hpp:24:
>>
>> In file included from 
>> /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/archive/detail/basic_iarchive.hpp:28:
>>
>> In file included from 
>> /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/archive/detail/helper_collection.hpp:27:
>>
>> */Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/include/boost/smart_ptr/shared_ptr.hpp:255:65:
>>  
>> **error: *
>>
>> *  no member named 'auto_ptr' in namespace 

[deal.II] Re: multiply constrained dofs (hanging nodes+periodic) fails a simple test case

[Denis Davydov]

On Wednesday, April 11, 2018 at 7:00:18 PM UTC+2, Sambit Das wrote:
>
> Hi Denis,
>
>
>> I don't think that's the case. The domain is indeed periodic, but this is 
>> completely detached from location of support/nodal points. 
>> Same applies to geometry, you will have different coordinates of vertices 
>> across the PBC so
>>
>>
> I agree, the location of nodal points is detached from the periodicity of 
> the domain, but in this case the origin is at the center of the hypercube. 
> This artificially enforces that the nodal_coordinate.norm() is periodic. 
>

true, but I don't see why you would have the same norms if you distribute 
with constraints from hanging nodes only or constraints from hanging nodes+ 
PBC.
I think we can agree that the two ConstraintMatrix objects should be 
different as in the case of PBC you additionally need to make sure that FE 
space on the refined boundary matches that on the opposite, non-refined 
side. 

If you suspect that there is a bug in constraints, you could check this by 
simply choosing some more-or-less random vector, distribute and 
plot-over-line in Paraview / Visit. 
More cumbersome comparison would be to evaluate random field at the 
opposite points.
You can use FEField function and then choose   L/2-\delta  and -L/2+\delta 
  with \delta = 1e-8 or so for X coordinate and then 
whatever you want to Y/Z. This should give you the same value anywhere on 
the two periodically matching points for a random input vector after 
constraints are distributed.
 
Denis.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Visual Studio Code extension for syntax highlighting in parameter files

[Denis Davydov]

Hi all,

Looks like I have a new favourite editor, so I added a syntax highlighting 
plugin for *.prm* files
https://marketplace.visualstudio.com/items?itemName=davydden.dealii-prm  

Regards,
Denis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] GUI to debug MPI code in Visual Studio Code

[Denis Davydov]

Dear all,

I apologise for the off-topic, but since many of you use deal.II with MPI 
and consequently sometimes need to debug your programs, I cross-post the 
information below in our group.

Developers of Cpptools  plugin 
for Visual Studio Code[1] are considering 

 adding 
support of MPI debugging with GUI using lldb/gdb.
Before committing to do this work, they want to see enough interest from 
community who use MPI. 
If you are interested in having this feature and potentially would give it 
a try if it's available, 
please leave a comment or thumbs-up a feature request on this GitHub issue 
page https://github.com/Microsoft/vscode-cpptools/issues/1723 

p.s. I think that Visual Studio Code has potential for a good basic GUI to 
debug jobs with about 4-8 MPI cores, which is often enough to catch bugs.
The GUI already supports simultaneously attaching debuggers to processes 
(see https://code.visualstudio.com/updates/v1_20#_node-debugging ),
so it’s only a matter of using this feature in the official C++ plugin to 
provide support for MPI debugging.

Regards,
Denis.

[1] a *free* source code editor developed by Microsoft for Windows, Linux 
and macOS with support for debugging, embedded Git control, syntax 
highlighting, 
intelligent code completion, snippets, and code refactoring.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: increment Dirichlet boundary condition

[Denis Davydov]

Hi IIiya,

On Thursday, February 22, 2018 at 11:55:33 AM UTC+1, Bryukhanov Ilya wrote:
>
> Denis, thanks a lot for the answer!
>
> I think that on the first step I can use usual 
> "interpolate_boundary_values + apply_boundary_values" functions,
>

the outline I gave above is agnostic to "first step"/"other steps", you 
would call VectorTools::interpolate_boundary_values() regardless 
stage to get constraints into the ConstraintMatrix object. If you do 
Newton-Raphson and solve for increments, at the first non-linear step you 
should have all constraints (hanging nodes + non-zero Dirichlet for a given 
step in quasi-static(?) loading), and for consequent steps only hanging 
nodes plus zero Dirichlet. 

Please read this module:
https://www.dealii.org/developer/doxygen/deal.II/group__constraints.html

This code-gallery may help in figuring out how to do 
this: 
https://www.dealii.org/developer/doxygen/deal.II/code_gallery_Quasi_static_Finite_strain_Compressible_Elasticity.html
 

 

> that transform the global matrix: columns of the constrained nodes become 
> zero columns with diagonal non-zero entries.
>
> In a time loop I have to account boundary condition without modifing 
> global matrix. While looping over dirichlet constrained cells
> I call the function  
> "hanging_node_constraints.distribute_local_to_global(cell_rhs, 
> local_dof_indices, system_rhs, cell_matrix)"
> which modifies the system_rhs vector by adding columns from constrained 
> nodes, which are actually zero in global matrix.
>
 
Nope, if your "hanging_node_constraints" indeed contains only constraints 
from hanging nodes, you won't see any contribution to the RHS
from it as constraints are homogeneous (ie. you wont' have  u_{123} = 456 
from hanging nodes).
 

>  
> Also I need to add components to rhs vector from the force boundary 
> conditions.
>

that's a different story, just do integration over faces and distribute as 
usual.
 

>
> However, I have to somehow account Dirichlet boundary conditions as in 
> previous step I didn't use any boundary values. The function
>

use ConstraintMatrix which has non-zero Dirichlet BC constraints.
 

> "interpolate_boundary_values(dof_handler, boundary_id, DirichletHandler, 
> boundary_values)"
> gives me "boundary_values" variables that maps node numbers to dirichle 
> boundary. 
>
> But I don't know how should I use it. What should I do with that variable 
> to account boundary conditions together with "distribute_local_to_global"?
>
> Thanks a lot in advance. Sorry for my misunderstanding.
>

Regards,
Denis.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: increment Dirichlet boundary condition

[Denis Davydov]

Hi Iliya,

there are numerous things that are wrong

On Wednesday, February 21, 2018 at 5:32:55 PM UTC+1, Bryukhanov Ilya wrote:
>
> Denis, thanks a lot for your answer and links that you provided. 
>
> However, my solution becomes in a way that the displacement values on that 
> boundary abnormally grow
> even without assigning new boundary condition in a time loop. I attach 
> figures on the zero step (correct) and on the first step (wrong).
>
> I do the following these things on each iteration: 
> 1) recompute rhs vector - system_rhs (which is zero for my problem),
> 2) compute matrix terms that are on the dirichlet boundary:
> for (auto cell = dof_handler.begin_active(); cell!=dof_handler.end(); 
> ++cell) {
> cell_matrix = 0; cell_rhs = 0; fe_values.reinit(cell);
> for (unsigned int face_number=0; 
> face_number<GeometryInfo::faces_per_cell; ++face_number) {
> if (cell->face(face_number)->at_boundary()) {
> // boundary index
> int id = cell->face(face_number)->boundary_id();
> if (boundary_displacement.find(id) != 
> boundary_displacement.end()) {
> //compute cell_matrix
>
> Then call function
> hanging_node_constraints.distribute_local_to_global(cell_matrix, cell_rhs, 
> local_dof_indices, system_matrix, system_rhs);
>

^^ that should be hanging_node_constraints + Dirichlet 

>
> 3) Then  apply functions to account Dirichlet boundary condition:  
>  VectorTools::interpolate_boundary_values(dof_handler, boundary_id, 
> DirichletHandler, boundary_values);
>
^^ that you would use during your setup
 

> MatrixTools::apply_boundary_values (boundary_values,
> system_matrix,
> solution,
> system_rhs);
>

^^ this is already what constraints.distribute_local_to_global() does, so 
no need to do that.

Regards
Denis.
 

>
>
> Can you give some advice how to make it correct?
>
>
> <https://lh3.googleusercontent.com/-O_1geVdTAOc/Wo2eOCPcdWI/A44/s_OauNpGhwcv2d4h3nmBinL40UhP7-S7ACLcBGAs/s1600/iter0.jpg>
>  
> <https://lh3.googleusercontent.com/-wHZAFJbU0bI/Wo2egOHamAI/AAAAA5A/6QJqcgEqD8MiPR5DNLF34OWMF3qX9QZvQCLcBGAs/s1600/iter1.jpg>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tuesday, February 20, 2018 at 10:51:17 PM UTC+3, Denis Davydov wrote:
>>
>> Hi Ilya,
>>
>> I am not away of principally simple solution, the RHS simply contains 
>> your bilinear form times interpolated values at constrained DoFs. 
>> What you can do is to loop over a subset of cells (those which are at the 
>> boundary), still assemble the local matrix and do 
>> constraints.distribute_local_to_global() which takes global matrix and 
>> RHS.
>>
>> Or you can use constrained_linear_operator 
>> <https://www.dealii.org/developer/doxygen/deal.II/group__constraints.html#ga59c2f70370213d436cb9fade9d813478>,
>>  
>> see this 
>> <https://groups.google.com/d/msg/dealii/A8dQs5i2n8A/YotvqvGwEgAJ> forum 
>> discussion.
>>
>> Please also study this 
>> <https://groups.google.com/d/msg/dealii/xo3Fa_olNwM/ObOuJPP2JT0J> 
>> thread, which covers similar question.
>>
>> Regards,
>> Denis.
>>
>> On Tuesday, February 20, 2018 at 4:46:19 PM UTC+1, Bryukhanov Ilya wrote:
>>>
>>> Hi,
>>>
>>> I consider elastic problem and forces and displacements on boundaries 
>>> are changing with time. I don't want to compute FEM matrix
>>> on each step. How to correctly simulate the task? I know that there is a 
>>> simple solution, but my solution is incorrect :)
>>> I have two variables for the system_matrix and rhs_vector. I try to 
>>> recompute rhs_vector on each step  and dirichlet condition 
>>> is accounted by calling "intepolate_boundary values + 
>>> apply_boundary_values" on each step with system_matrix and rhs_vector 
>>> variables inside.
>>> I think that I should use initial matrix and the matrix which is 
>>> modified by Dirichlet procedure and assign latter to the initial matrix on 
>>> each step?
>>> Am I corrent or there is some other solution?
>>>   
>>>
>>>
>>>
>>>
>>>
>>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: increment Dirichlet boundary condition

[Denis Davydov]

Hi Ilya,

I am not away of principally simple solution, the RHS simply contains your 
bilinear form times interpolated values at constrained DoFs. 
What you can do is to loop over a subset of cells (those which are at the 
boundary), still assemble the local matrix and do 
constraints.distribute_local_to_global() which takes global matrix and RHS.

Or you can use constrained_linear_operator 
,
 
see this  
forum discussion.

Please also study this 
 thread, 
which covers similar question.

Regards,
Denis.

On Tuesday, February 20, 2018 at 4:46:19 PM UTC+1, Bryukhanov Ilya wrote:
>
> Hi,
>
> I consider elastic problem and forces and displacements on boundaries are 
> changing with time. I don't want to compute FEM matrix
> on each step. How to correctly simulate the task? I know that there is a 
> simple solution, but my solution is incorrect :)
> I have two variables for the system_matrix and rhs_vector. I try to 
> recompute rhs_vector on each step  and dirichlet condition 
> is accounted by calling "intepolate_boundary values + 
> apply_boundary_values" on each step with system_matrix and rhs_vector 
> variables inside.
> I think that I should use initial matrix and the matrix which is modified 
> by Dirichlet procedure and assign latter to the initial matrix on each step?
> Am I corrent or there is some other solution?
>   
>
>
>
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Error in installing deal.ii with spack on linux openSuse

[Denis Davydov]

Hi Alberto,

Just a quick explanation why this happens: 

this is a current limitation in how Spack tries to find a configuration of 
packages which satisfies input request.
At the point when you type:

spack install dealii

it does not yet know which version to use (you may have your custom 
settings for version / variants in .spack/packages.yaml),
and then, oddly enough, it first settles on Cmake version (latest stable is 
3.10) and then tries to use latest stable dealii 8.5.1
which has a declared requirement of Cmake lower or qual to 3.9.
As a consequence you got this unfriendly error.

Even simpler solution than what Bruno says is to be specific w.r.t. version

spack install dealii@8.5.1

then Spack will do its job finding the configuration which fits all the 
requirements.

Regards,
Denis.


On Monday, February 19, 2018 at 8:40:12 PM UTC+1, Alberto Salvadori wrote:
>
> Thank you!
>
> Alberto Salvadori
> Associate Professor 
> DICATAM, University of Brescia, Italy
>
>
> On 19 Feb 2018, at 16:06, Bruno Turcksin  > wrote:
>
> Alberto,
>
> On Monday, February 19, 2018 at 9:56:25 AM UTC-5, Alberto Salvadori wrote:
>>
>> dealii requires cmake version :3.9.99, but spec asked for 3.10.1
>>
> deal.II 8.5 does not support cmake 3.10 so you need to force spack to use 
> a lower version. Something like this should work spack dealii ^cmake@3.9.1
>
> Best,
>
> Bruno 
>
> -- 
> 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+un...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> Informativa sulla Privacy: http://www.unibs.it/node/8155
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Problem compiling deal_ii with PETSc

[Denis Davydov]

Hi,

You may want to try one of the source-based installers listed here 
https://www.dealii.org/download.html 

Denis.

On Wednesday, February 14, 2018 at 2:55:34 AM UTC+1, Daipayan Sarkar wrote:
>
> Hello All, 
>
> I am facing difficulty to link PETSc to dealii. Following are the steps 
> that I did:
>
> 1. Downloaded PETSc tar file (petsc-3.8.0). 
> 2. Then compiled PETSc from source using: 
>   ./configure --with-cc=gcc --with-cxx=g++ --with-fc=gfortran 
> --download-mpich --download-fblaslapack
> 3.make all test
> 4. Download dealii (ver 8.5.1)
> 5. Make the build directory inside dealii
> 6. cd build
> 7. Now for cmake to link to local PETSc installation, I implemented the 
> following:
> CC=../../petsc-3.8.3/arch-darwin-c-debug/mpicc 
> CXX=../../petsc-3.8.3/arch-darwin-c-debug/bin/mpic++ cmake 
> -DDEAL_II_WITH_MPI=ON -DDEAL_II_WITH_PETSC=ON 
> -DPETSC_DIR=/Users/dos/petsc-3.8.3/ 
> -DPETSC_ARCH=arch-darwin-c-debug -DCMAKE_INSTALL_PREFIX=./ ../
>
> At ~ 48% I get the following error message: 
>
> *error: **"PETSc was configured with MPICH but now appears to be 
> compiling using a non-MPICH mpi.h"*
>
>
> Any help or suggestion is much appreciated. Thanks, DS
>
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] ECCM 2018 - High Performance Geometric Multigrid Finite Element Methods

[Denis Davydov]

Dear all,

The deadline for abstract submission has passed, 
but it’s still possible to submit one online until Monday 05.02.

Regards 
Denis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: order of cells in two MatrixFree objects on the same Triangulation and Quadrature but different FE spaces

[Denis Davydov]

p.s. I can confirm that using reinit() which takes vectors of DoFHandlers 
and Constraints solved the problem.

@Martin: nevermind about documentation, there is also a paragraph above 
which discuss similar things. 
Maybe eventually we need to have another matrix-free tutorial to 
demonstrate all those options.

Regards,
Denis.

On Monday, January 29, 2018 at 5:13:58 PM UTC+1, Denis Davydov wrote:
>
> Hi Martin,
>
> Thanks for confirming that it's indeed possible.
>
> On Monday, January 29, 2018 at 4:34:07 PM UTC+1, Martin Kronbichler wrote:
>>
>> Dear Denis,
>>
>> p.s. the mapping is the same for both cases.
>>
>> On Monday, January 29, 2018 at 4:16:48 PM UTC+1, Denis Davydov wrote: 
>>>
>>> Dear all, 
>>>
>>> I am playing around with something in the following setup:
>>> 1. I have a single p::d::Tria
>>> 2. two different DoFHandler's using scalar FE_Q of different degrees
>>> 3. The same quadrature rule (QGauss) used for both cases
>>> 4. Two different MatrixFree objects
>>>
>>> I am not 100% sure, but it looks like the iteration over SIMD chunks of 
>>> cells via two different matrix-free
>>> objects actually leads to the different sequence of cells. I see that 
>>> when I try to calculate some integral quantities
>>> of my quadrature point data.
>>>
>>
>> I guess that's possible. Once there are different DoFHandler objects, the 
>> algorithm that collects cells and puts them into batches might change. The 
>> documentation does state the following (in FEEvaluation):
>> https://www.dealii.org/developer/doxygen/deal.II/classFEEvaluation.html
>> section on "Handling several integration tasks and data storage in 
>> quadrature points" towards the end of the general class documentation. It 
>> says "For the combination of different fields, including different solution 
>> vectors that come from different time steps, it is mandatory that all 
>> FEEvaluation 
>> <https://www.dealii.org/developer/doxygen/deal.II/classFEEvaluation.html> 
>> objects share the same MatrixFree 
>> <https://www.dealii.org/developer/doxygen/deal.II/classMatrixFree.html> 
>> object." 
>>
>> Did you expect anything in addition?
>>
>
> I guess i just missed this part. I always forget that FEEvaluation has 
> much more info than MatrixFree class.
>
> I suppose the right approach here is to use `reinit()` which takes a 
> vector of constraints and DoFHandlers and use it 
> in combination with different operators. I guess this might be the only 
> thing to mention in that paragraph.
>  
> Regards,
> Denis
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: order of cells in two MatrixFree objects on the same Triangulation and Quadrature but different FE spaces

[Denis Davydov]

Hi Martin,

Thanks for confirming that it's indeed possible.

On Monday, January 29, 2018 at 4:34:07 PM UTC+1, Martin Kronbichler wrote:
>
> Dear Denis,
>
> p.s. the mapping is the same for both cases.
>
> On Monday, January 29, 2018 at 4:16:48 PM UTC+1, Denis Davydov wrote: 
>>
>> Dear all, 
>>
>> I am playing around with something in the following setup:
>> 1. I have a single p::d::Tria
>> 2. two different DoFHandler's using scalar FE_Q of different degrees
>> 3. The same quadrature rule (QGauss) used for both cases
>> 4. Two different MatrixFree objects
>>
>> I am not 100% sure, but it looks like the iteration over SIMD chunks of 
>> cells via two different matrix-free
>> objects actually leads to the different sequence of cells. I see that 
>> when I try to calculate some integral quantities
>> of my quadrature point data.
>>
>
> I guess that's possible. Once there are different DoFHandler objects, the 
> algorithm that collects cells and puts them into batches might change. The 
> documentation does state the following (in FEEvaluation):
> https://www.dealii.org/developer/doxygen/deal.II/classFEEvaluation.html
> section on "Handling several integration tasks and data storage in 
> quadrature points" towards the end of the general class documentation. It 
> says "For the combination of different fields, including different solution 
> vectors that come from different time steps, it is mandatory that all 
> FEEvaluation 
> <https://www.dealii.org/developer/doxygen/deal.II/classFEEvaluation.html> 
> objects share the same MatrixFree 
> <https://www.dealii.org/developer/doxygen/deal.II/classMatrixFree.html> 
> object." 
>
> Did you expect anything in addition?
>

I guess i just missed this part. I always forget that FEEvaluation has much 
more info than MatrixFree class.

I suppose the right approach here is to use `reinit()` which takes a vector 
of constraints and DoFHandlers and use it 
in combination with different operators. I guess this might be the only 
thing to mention in that paragraph.
 
Regards,
Denis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: order of cells in two MatrixFree objects on the same Triangulation and Quadrature but different FE spaces

[Denis Davydov]

p.s. the mapping is the same for both cases.

On Monday, January 29, 2018 at 4:16:48 PM UTC+1, Denis Davydov wrote:
>
> Dear all,
>
> I am playing around with something in the following setup:
> 1. I have a single p::d::Tria
> 2. two different DoFHandler's using scalar FE_Q of different degrees
> 3. The same quadrature rule (QGauss) used for both cases
> 4. Two different MatrixFree objects
>
> I am not 100% sure, but it looks like the iteration over SIMD chunks of 
> cells via two different matrix-free
> objects actually leads to the different sequence of cells. I see that when 
> I try to calculate some integral quantities
> of my quadrature point data. Namely, i see the difference in the integral
>
> my_integral += quadrature_data(cell,q) * fe_eval.JxW(q);
>
> when I use two different MatrixFree objects to initialize FEEvaluation 
> (obviously with the same n_q_points_1d but different fe_degree).
> The order of difference is far beyond any numerical roundoff error.
>
>
> Is this something expected but not described, AFAICT, in documentation?
>
>
> Regards,
> Denis.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] order of cells in two MatrixFree objects on the same Triangulation and Quadrature but different FE spaces

[Denis Davydov]

Dear all,

I am playing around with something in the following setup:
1. I have a single p::d::Tria
2. two different DoFHandler's using scalar FE_Q of different degrees
3. The same quadrature rule (QGauss) used for both cases
4. Two different MatrixFree objects

I am not 100% sure, but it looks like the iteration over SIMD chunks of 
cells via two different matrix-free
objects actually leads to the different sequence of cells. I see that when 
I try to calculate some integral quantities
of my quadrature point data. Namely, i see the difference in the integral

my_integral += quadrature_data(cell,q) * fe_eval.JxW(q);

when I use two different MatrixFree objects to initialize FEEvaluation 
(obviously with the same n_q_points_1d but different fe_degree).
The order of difference is far beyond any numerical roundoff error.


Is this something expected but not described, AFAICT, in documentation?


Regards,
Denis.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: PetSc Hybrid MPI-OPENMP Parallelization with Spack Dealii

[Denis Davydov]

Hi,

On Wednesday, January 24, 2018 at 9:13:06 PM UTC+1, Sukhminder Singh wrote:
>
> I installed Spack package of Dealii on a machine with 32 cores (48 virtual 
> cores) and ran a petsc-parallel code. If I run using only one MPI process, 
> then I only get one core running for the solver part. Shouldn't it use all 
> the available cores within a node?  I think its installed with MPI only 
> support, right? Can I use hybrid MPI-OPENMPI parallelization with PetSc  
>
installed using Spack?
>

if you use PETSc, that's how it works, AFAIK PETSc does not support any 
hybrid parallelism.

Elsewhere, deal.II uses TBB (for example in assembly, see other tutorials), 
the number of threads is controlled via 
https://www.dealii.org/developer/doxygen/deal.II/classUtilities_1_1MPI_1_1MPI__InitFinalize.html
 

p.s. it has nothing to do with Spack, which is a package manager to help 
install things consistently. 

Regards,
Denis. 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Is deal.ii suitable for civil engineering problems?

[Denis Davydov]

Hi,

Deal.II has been used in numerous applications, including but not limited 
to solid mechanics,
see publication lists http://www.dealii.org/publications.html 
and also publications of my colleague 
Jean-Paul 
https://ltm-en.cms.rrze.uni-erlangen.de/person/pelteret-jean-paul-ph-d/
who is focused on solid mechanics and multi-physics problems.

On Monday, December 11, 2017 at 10:14:13 AM UTC+1, alan...@gmail.com wrote:
>
>
> I am taking the FEM course on coursera sponsored by u-mich. I just 
> installed deal.ii and successfully ran the first example. I am quite happy 
> with that, but before learning more, I want to make sure how suitable is 
> deal.ii for me (in the professional aspect, I am a civil engineer) and how 
> much I can achieve with it.
>
> a) Is it possible to include any material constitutive relation, for 
> example, Todeshini Stress-strain relationship (Figure b) ?
>

deal.II works with weak forms, so it's agnostic to the origin of PDE and 
thereby you can introduce whatever 
constitutive equation to close the system. But you would need to implement 
it yourself.

Cheers,
Denis
 

> [image: 
> http://www.mdpi.com/materials/materials-08-00435/article_deploy/html/images/materials-08-00435-g005-1024.png]
>
> 
>
>
> b) is it possible to work with frame/bar elements in 1D, 2D and 3D, not 
> only on compression or tension loads (which I know deall.ii is capable of), 
> but also being capable of describing the flexural behavior, this is, is 
> deal.ii capable of modeling a Bernoulli Beam 
> ? 
> c) is it possible to model shell elements in 2D and 3D (and as before), 
> not only for compression/tension (or plane stress/strain problems), but 
> also modeling it's bending behavior, like a bending plate.
>
> d) Is it possible to model hysteric behavior 
> ?
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: surprising results from DoFHandler.locally_owned_dofs() calls in the fully distributed triangulation

[Denis Davydov]

Hi,

On Friday, December 15, 2017 at 11:14:24 PM UTC+1, Marek Čapek wrote:
>
> Hello,
> I have downloaded and installed 8.5.1 version of dealii library
> using candi. I needed to use calls of
>
> const IndexSet 
> & 
> DoFHandler 
> < dim, 
> spacedim >::locally_owned_dofs ( 
> ) const
>
>
> And
>
> void DoFTools::extract_locally_relevant_dofs ( const DoFHandlerType &  
> *dof_handler*, 
>
>
> IndexSet  
> &  *dof_set*  
>
> ) 
>
>
>
>
>
> For setting up of ghosted vectors.
> May be I understand wrongly some design concepts, however it appears to me,
> that these functions do not work correctly.
> Namely, they both return IndexSet with size of the "complete universum" of 
> dofs,
>

You need to check documentation of IndexSet 
class https://www.dealii.org/developer/doxygen/deal.II/classIndexSet.html 
which is designed to represent a subset of the [0, size)
So both represent the subsets of the same set of all DoFs in your problem 
and their size() is the same,
however n_elements() will be different.

Cheers,
Denis.
 

> i.e. the indexsets are not distributed.
>
> My code is rather complicated, so I have prepared slight modification of 
> step-40,
> where the following printout shows the misbehaviour:
>
>
> pcout<<"this works 
>> correctly-"<>   std::vector n_dofs_per_core = 
>> dof_handler.n_locally_owned_dofs_per_processor();
>>
>> for(std::vector::iterator 
>> it=n_dofs_per_core.begin();it!=n_dofs_per_core.end();++it)
>>pcout<<"size of dofs per core according to 
>> dof_handler.n_locally_owned_dofs_per_processor() "<<*it<>
>>
>> pcout<<"this is 
>> strange-"<>
>>  std::vector   dof_per_core = 
>> dof_handler.locally_owned_dofs_per_processor();
>>
>> for( std::vector::iterator 
>> it=dof_per_core.begin();it!=dof_per_core.end();++it)
>>pcout<<"size of dofs pers core according to 
>> dof_handler.locally_owned_dofs_per_processor()  "<<(*it).size()<> 
>> pcout<<"---AND-"<> std::cout<<"number of  locally owned dofs  
>> "<> std::cout<<"number of locally relevant dofs  
>> "<>
>
>
>
> It appears to me, that the data structure with Dofs in in inconsistent 
> state. I have tried both Trilinos and
> Petsc backends.
> I am adding the complete modified step-40 to the attachment.
> Please take a look at it, or maybe correct my opinion.
>
> Thank You
>
> Marek C
>
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Cmake-MPI

[Denis Davydov]

Or use Spack which makes sure that only note instance of each dependency (such 
as MPI) is used to build deal.ii and all its dependencies: 
https://github.com/dealii/dealii/wiki/deal.II-in-Spack


Ps. As for the multiple MPI on the system, it’s perfectly valid idea as long as 
you know what you are doing, namely build a single stack of software with the 
same MPI. That actually applies to any dependency: you can have and try/compare 
as many as you want, but you need to use them consistently to build the stack. 
Most likely it’s not your intention here, but that’s what Spack makes easy as 
packages are never installed into the same prefix like /use/local

Regards,
Denis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] ECCM 2018 - High Performance Geometric Multigrid Finite Element Methods

[Denis Davydov]

Dear all,

within the *European Conference on Computational Mechanics ECCM 2018 *to be 
held in *Glasgow (UK) *on *July 11-15 2018* we are organizing a 
Mini-symposium on
*HIGH PERFORMANCE GEOMETRIC MULTIGRID FINITE ELEMENT METHODS* (A201).
Below you can find the abstract of the MS (also available at 
http://www.eccm-ecfd2018.org/admin/Files/FileAbstract/A201.pdf).
It is our pleasure to invite you to participate in our mini symposium.

The deadline for abstract submission is *January 31th, 2018 
<http://www.eccm-ecfd2018.org/frontal/Dates.asp>.*
All the details about registration, accommodation, conference venue, 
technical and social programs can be found at the conference website: 
http://www.eccm-ecfd2018.org.
We are looking forward to your contribution and to seeing you at the 
meeting.

Best regards,
Martin Kronbichler (TUM, Germany)
Denis Davydov (FAU, Germany)
Guido Kanschat (IWR, Germany)


MS A201 Abstract:

Geometric multigrid (GMG) schemes are among the most efficient methods to 
solve the systems of equations arising in the discretization of partial 
differential equations. Run time complexity for solving a linear system of 
n unknowns scales as O(n) for equations dominated by elliptic terms. This 
fast rate of convergence is achieved by combining simple smoothers that are 
effective for damping high frequencies on a hierarchy of meshes. Recent 
advances in multigrid methods are variants of the method that are also 
optimal for non-elliptic equations, the combination with sophisticated 
high-order discretizations and grid tools such as adaptivity, and 
high-performance implementations.
This Minisimposium aims to discuss the state of the art in geometric 
multgirid methods for finite element discretizations in computational 
solid, fluid and quantum mechanics as well as to provide an interactive 
forum to discuss recent advances and challenges. Particularly interesting 
topics are, amongst others, geometric multigrid for high-order continuous 
and discontinuous Galerkin schemes with fast matrix-free implementations, 
implementations for novel computer architectures such as GPUs, fully 
approximated storage schemes and multigrid methods for eigenproblems.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Spurious eigenvalues

[Denis Davydov]

On Friday, December 1, 2017 at 2:50:38 PM UTC+1, Timo Heister wrote:
>
> > They're always going to be there because we keep constrained nodes in 
> the 
> > linear system. 
>
> If we modify the way ConstraintMatrix operates, we could work around 
> this though: 
>

but there is really no need, is it? 
If you start with initial vector (or subspace, depending on the method) 
orthogonal to the constraints, you ain't gonna find converge to those 
eigenvalues anyway.

Cheers,
Denis 
 

> 1. Without rescaling those equations (as we do inside ConstraintMatrix 
> right now) the spurious EV would all be equal to 1 and so ignoring 
> them is easier. 
> 2. One could also zero out the constrained rows after the fact. 
> 3. Did we rip out the support for removing the constrained entries 
> from the matrix completely? 
>
> -- 
> Timo Heister 
> http://www.math.clemson.edu/~heister/ 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Spurious eigenvalues

[Denis Davydov]

Hi Bruno,

AFAIK, there is a simple solution: make initial vector (or subspace) 
perpendicular to those constrained entries. 
That is, if you do Lancoz, set random initial vector and then zero out 
constrained DoFs. 
Then being Krylov-based method it should form subspaces {x, Ax, A^2x,...} 
orthogonal to those constrained DoFs, so 
you should not get any issues.

Cheers,
Denis.

On Thursday, November 30, 2017 at 4:24:05 PM UTC+1, Bruno Turcksin wrote:
>
>
> Hi all,
>
> In step-36, there is an explanation on how Dirichlet boundary conditions 
> introduce spurious eigenvalues because some dofs are constrained. However, 
> there is no mention of hanging nodes. So I am wondering if I can treat them 
> as shown for the Dirichlet boundary, i.e, the only difference between a 
> hanging node and a Dirichlet is what happens in 
> ConstraintMatrix::distribute(). I also wonder if there is a way to avoid 
> having these spurious eigenvalues computed or if the only way to deal with 
> them is to redo the calculation after changing the entries in the matrix.
>
> Best,
>
> Bruno
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Isogeometric analysis

[Denis Davydov]

Hi Luca,

do you want to move some of those classes/functionality to deal.II? 
I think that would great.

Cheers,
Denis.

On Wednesday, November 22, 2017 at 9:52:38 AM UTC+1, Luca Heltai wrote:
>
> Dear Yaakov, 
>
> did you even try google? 
>
> :) 
>
> google search: dealii isogeometric analysis 
>
>
> https://www.google.it/search?q=dealii+isogeometric+analyis_rd=cr=0=vTkVWvurIcOUaPbVr6AO
>  
>
> gives you as a first result this repository: 
>
> https://github.com/mathLab/IGA-dealii 
>
> So far it supports single patch IGA, and it contains a version of step-41 
> that uses IGA, as well as a few other tools. 
>
> Best, 
> Luca. 
>
>
> > On 21 Nov 2017, at 22:15, fea...@gmail.com  wrote: 
> > 
> > Hi Bruno, 
> > 
> > As Isogometric Analysis is very popular in solid & fluid mechanics now. 
> I would know, does Deal.II 8.5.0 contain Isogometric Analysis library? 
> > 
> > Regards, 
> > Yaakov 
> > 
> > 
> > On Tuesday, November 21, 2017 at 8:35:38 PM UTC+1, Bruno Turcksin wrote: 
> > Yaakov, 
> > 
> > This is not my area of expertise but I guess you will want to take a 
> look at http://dealii.org/8.5.0/doxygen/deal.II/step_54.html 
> > 
> > Best, 
> > 
> > Bruno 
> > 
> > On Tuesday, November 21, 2017 at 12:17:25 PM UTC-5, fea...@gmail.com 
> wrote: 
> > Dear Deal.II Team & User, 
> > 
> > I would like to ask a question: 
> > 
> > Can I solve Isgometric Analysis problems (single or multipatchs)? 
> > 
> > Warm regards, 
> > Yaakov 
> > 
> > -- 
> > 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+un...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] New Mac OSX brew package

[Denis Davydov]

> On 9 Nov 2017, at 23:12, luca.heltai  wrote:
> 
> It does not compile, anyway…
> 
> :D 
> 
> Maybe Denis can help: I get the following when trying to compile pkg-config 
> using gcc installed with spack:

a lot of things break on macOS when compiling with GCC. 
For example CMake was a problem on Sierra 
https://github.com/spack/spack/issues/1847 
 

One can work-around such issue by either using system-provided tools or 
building some of those with Clang and the rest with GCC,
but frankly I don’t see a reason doing it on macOS. There’s more pain than gain.

Also compiler errors with templates are much better with Clang, so I kinda like 
it more ;-)

Cheers,
Denis.

> 
> In file included from 
> /System/Library/Frameworks/Security.framework/Headers/AuthSession.h:32:0,
> from 
> /System/Library/Frameworks/Security.framework/Headers/Security.h:43,
> from 
> /System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/CSIdentity.h:43,
> from 
> /System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/OSServices.h:27,
> from 
> /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/IconsCore.h:23,
> from 
> /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LaunchServices.h:22,
> from 
> /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:39,
> from gunicollate.c:30:
> /System/Library/Frameworks/Security.framework/Headers/Authorization.h:193:7: 
> error: variably modified ‘bytes’ at file scope
>  char bytes[kAuthorizationExternalFormLength];
>   ^
> make[6]: *** [libglib_2_0_la-gunicollate.lo] Error 1
> make[5]: *** [all-recursive] Error 1
> make[4]: *** [all] Error 2
> make[3]: *** [all-recursive] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> 
> L.
> 
>> On 9 Nov 2017, at 23:09, Timo Heister  wrote:
>> 
>>> I'm using clang+gfortran. I have not tried using gcc for everything, but I 
>>> could give it a shot if you think it would be worth it.
>> 
>> No, I was just curious. I don't have a strong preference for either.
>> 
>> -- 
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> 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 a topic in the Google 
> Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/dealii/DINdUMGsxoE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> dealii+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: New Mac OSX brew package

[Denis Davydov]

nice!

@Timo: If I am not mistaken, it's Apple's Clang 9.0.0 + gfortran 7.2.0.  

On Thursday, November 9, 2017 at 9:41:52 AM UTC+1, Luca Heltai wrote:
>
> Dear All, 
>
> I just finished uploading a new brew based package for deal.II with a 
> 9.0pre.1 version: 
>
> https://github.com/luca-heltai/dealii/releases/tag/v9.0.pre.1 
>
> It was compiled on a Mac OS X High Sierra: 10.13 (17A405), with Xcode 
> 9.0.1 (9A1004). 
>
> The application contains a full `spack` installation at 
>
> `/Applications/deal.II-9.0-spack/Contents/Resources/spack` 
>
> You’ll have access to all spack facilities (including modules) by adding 
>
> . 
> /Applications/deal.II-9.0-spack.app/Contents/Resources/share/deal.II/dealii.conf
>  
>
>
> to your ~/.profile file. 
>
> Summary.log: 
>
> ### 
> # 
> #  deal.II configuration: 
> #CMAKE_BUILD_TYPE:   DebugRelease 
> #BUILD_SHARED_LIBS:  ON 
> #CMAKE_INSTALL_PREFIX:   
> /Applications/deal.II-9.0-spack.app/Contents/Resources 
> #CMAKE_SOURCE_DIR:   /Users/heltai/dealii/dealii 
> #(version 9.0.0-pre, shortrev 88babf1a4d) 
> #CMAKE_BINARY_DIR:   
> /Users/heltai/dealii/dealii/build-9.0-spack 
> #CMAKE_CXX_COMPILER: AppleClang 9.0.0.938 on platform 
> Darwin x86_64 
> #   
>  /Applications/deal.II-9.0-spack.app/Contents/Resources/spack/view/bin/mpic++ 
>
> # 
> #  Configured Features (DEAL_II_ALLOW_BUNDLED = ON, 
> DEAL_II_ALLOW_AUTODETECTION = ON): 
> #  ( DEAL_II_WITH_64BIT_INDICES = OFF ) 
> #DEAL_II_WITH_ADOLC set up with external dependencies 
> #DEAL_II_WITH_ARPACK set up with external dependencies 
> #DEAL_II_WITH_ASSIMP set up with external dependencies 
> #DEAL_II_WITH_BOOST set up with external dependencies 
> #  ( DEAL_II_WITH_CUDA = OFF ) 
> #DEAL_II_WITH_CXX14 = ON 
> #DEAL_II_WITH_CXX17 = ON 
> #DEAL_II_WITH_GSL set up with external dependencies 
> #DEAL_II_WITH_HDF5 set up with external dependencies 
> #DEAL_II_WITH_LAPACK set up with external dependencies 
> #DEAL_II_WITH_METIS set up with external dependencies 
> #DEAL_II_WITH_MPI set up with external dependencies 
> #DEAL_II_WITH_MUPARSER set up with external dependencies 
> #DEAL_II_WITH_NANOFLANN set up with external dependencies 
> #DEAL_II_WITH_NETCDF set up with external dependencies 
> #DEAL_II_WITH_OPENCASCADE set up with external dependencies 
> #DEAL_II_WITH_P4EST set up with external dependencies 
> #DEAL_II_WITH_PETSC set up with external dependencies 
> #DEAL_II_WITH_SLEPC set up with external dependencies 
> #DEAL_II_WITH_SUNDIALS set up with external dependencies 
> #DEAL_II_WITH_THREADS set up with external dependencies 
> #DEAL_II_WITH_TRILINOS set up with external dependencies 
> #DEAL_II_WITH_UMFPACK set up with external dependencies 
> #DEAL_II_WITH_ZLIB set up with external dependencies 
> # 
> #  Component configuration: 
> #  ( DEAL_II_COMPONENT_DOCUMENTATION = OFF ) 
> #  ( DEAL_II_COMPONENT_EXAMPLES = OFF ) 
> #DEAL_II_COMPONENT_PACKAGE 
> #  ( DEAL_II_COMPONENT_PYTHON_BINDINGS = OFF ) 
> # 
> #  Detailed information (compiler flags, feature configuration) can be 
> found in detailed.log 
> # 
> #  Run  $ ninja info  to print a help message with a list of top level 
> targets 
> # 
> ### 
>
> And this is the output of spack find: 
>
> ==> 74 installed packages. 
> -- darwin-highsierra-x86_64 / clang@9.0.0-apple - 
> adol-c@develop  freetype@2.7.1lcms@2.8 
> nasm@2.11.06pkg-config@0.29.2 
> arpack-ng@3.5.0 gcc@7.2.0 libjpeg-turbo@1.5.0 
>  ncurses@6.0 python@2.7.14 
> assimp@4.0.1gdbm@1.13 libpng@1.6.29
> net...@4.4.1.1   readline@7.0 
> astyle@2.04 get...@0.19.8.1  
>  libsigsegv@2.11  netcdf-cxx@4.2  slepc@3.8.0 
> autoconf@2.69   ghostscript@9.21  libtiff@4.0.8   
>  netlib-scalapack@2.0.2  sqlite@3.20.0 
> automake@1.15.1 g...@0.9.7.1
> libtool@2.4.6ninja@1.8.2 suite-sparse@4.5.5 
> bison@3.0.4 gmp@6.1.2 libxml2@2.9.4   
>  numdiff@5.9.0   sundials@3.0.0 
> boost@1.63.0graphviz@2.38.0   m4@1.4.18   
>  oce@0.18.2  superlu-dist@5.2.2 
> bzip2@1.0.6 gsl@2.4   matio@1.5.9 
>  openblas@0.2.20 tar@1.29 
> cmake@3.9.4 hdf5@1.10.1   metis@5.1.0 
>  openmpi@3.0.0   tcl@8.6.6 
> dealii@develop  help2man@1.47.4   mpc@1.0.3   
>  openssl@1.0.2k  trilinos@12.12.1 
> doxygen@1.8.12  hwloc@1.11.8  mpfr@3.1.5   
> p4est@2.0   xz@5.2.3 
> 

Re: [deal.II] How to add addtional point to enrichment functions (FE_Enriched)

[Denis Davydov]

Hi Edith,

> On 2 Nov 2017, at 20:08, Edith Sotelo <sotelog.ed...@gmail.com> wrote:
> 
> Hey Denis,
> 
> I think I was not clear enough in describing what I want to do . I apologize, 
> that’s my bad. I hope the next lines explain it better
> 
> I want to implement Ni*F(x-xi) or   Ni*[F(x)-F(xi)]  for the enrichment part

(below I assume you have the same FE for enriched and non-enriched parts).

If you have a FE space spanned by { Ni(x), Ni(x) * F(x-xi) } then it 
essentially means you have a different enrichment function for each DoF.
You might as well write it as  {Ni(x), Ni(x) * Fi (x) }   where Fi(x) := F(x-xi)
That won’t work with FE_Enriched because a single function F(x) is used to 
enrich all DoFs on the element.
There is no mechanism to selectively pick up a single DoF. You would have to do 
this manually.

If you need to enrich only a hand-full of all DoFs (say 10 out of 10) each 
with a different function, 
then you can try to work out the chain-rule in your bilinear forms manually. 
That’s easy but tedious, see 
https://github.com/dealii/dealii/blob/master/tests/fe/fe_enriched_step-36b.cc#L455-L590
 
<https://github.com/dealii/dealii/blob/master/tests/fe/fe_enriched_step-36b.cc#L455-L590>
which implements PUM without FE_Enriched.
What is worse is managing FE_Collection and figuring out all the constraints to 
keep continuous FE space. 
On each element you would go  local_dof -> global_dof -> enrichment_function.
I guess it’s doable, but not trivial in implementation.


The second case you have a space spanned by { Ni(x), Ni(x) * [F(x) - F(xi)] } 
\equiv {Ni(x), Ni(x) * F(x) } is perfectly doable with FE_Enriched.

Regards,
Denis.


> 
> where:
> Ni is the i-th standard basis function,
> F is a enrichment function ,
> xi is the dof coordinate of the i-th standard basis function.
> 
> That’s why I think  I need to look for the corresponding xi point  during 
> assembly… 
> 
> Thank you for your patience.
> 
> 
> 
>> On Nov 2, 2017, at 10:56 AM, Denis Davydov <davyd...@gmail.com 
>> <mailto:davyd...@gmail.com>> wrote:
>> 
>> Hi Edith,
>> 
>>> On 2 Nov 2017, at 15:46, Edith Sotelo <sotelog.ed...@gmail.com 
>>> <mailto:sotelog.ed...@gmail.com>> wrote:
>>> 
>>> 
>>> Hi  Denis,
>>> Thank you for answering my (odd) questions...
>>> 
>>> I think I meant that I do not see how I could pass a point that is 
>>> calculated during assembly when constructing the enrichments functions. So 
>>> to pass the point during 
>> 
>> what do you **have to** calculate this point during assembly? If it’s just a 
>> support point of the FE basis or a vertex, surely you can get it prior to 
>> assembly.
>> You can also use pointers to a Point in your custom function and then 
>> modify the value outside.
>> 
>>> assembly I think I need to get to the enrichment functions that are already 
>>> in the “enrichments” vector,  and this is a protected  member of the 
>>> FE_Enriched class … so I was thinking to make it public…  maybe you have a 
>>> different suggestion...
>>> 
>>> I want to do this to try a couple of things..
>>> 
>>> * I want to test a function like this : Cos ( z) with  z=sqrt ( (x-xo)^2 + 
>>> (y-yo)^2), where  (xo, yo) is the point I need to pass..
>>> 
>>> * I would like to implement the  kronecker delta property: f(x)-f(xi) where 
>>> xi is the coordinate of the dof
>>> 
>>> 
>>>  and I was also thinking that I would probably need to work with DG 
>>> methods. But I can try the 1D test you suggested first to find out the 
>>> continuity of my functions
>>> 
>>> Thank you for your help.
>>> 
>>> Edith
>>> 
>>> 
>>>> On Nov 2, 2017, at 1:49 AM, Denis Davydov <davyd...@gmail.com 
>>>> <mailto:davyd...@gmail.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>> 2 нояб. 2017 г., в 2:50, Edith Sotelo <esot...@tamu.edu 
>>>> <mailto:esot...@tamu.edu>> написал(а):
>>>> 
>>>>> Hi Denis,
>>>>> Thank you for your answer but I still need to further understand some 
>>>>> things :  
>>>>> * I think I need to pass the point (xo) during assembly since it will 
>>>>> different for different cells ( dof coordinate or center of the cell), 
>>>> 
>>>> Unless you work with discontinuous Galerkin, then you need to be careful 
>>>> with how you use PUM.
>>>> 
>>>> If you take a global view of the shape functions

Re: [deal.II] How to add addtional point to enrichment functions (FE_Enriched)

[Denis Davydov]

Hi Edith,

> On 2 Nov 2017, at 15:46, Edith Sotelo <sotelog.ed...@gmail.com> wrote:
> 
> 
> Hi  Denis,
> Thank you for answering my (odd) questions...
> 
> I think I meant that I do not see how I could pass a point that is calculated 
> during assembly when constructing the enrichments functions. So to pass the 
> point during

what do you **have to** calculate this point during assembly? If it’s just a 
support point of the FE basis or a vertex, surely you can get it prior to 
assembly.
You can also use pointers to a Point in your custom function and then 
modify the value outside.

> assembly I think I need to get to the enrichment functions that are already 
> in the “enrichments” vector,  and this is a protected  member of the 
> FE_Enriched class … so I was thinking to make it public…  maybe you have a 
> different suggestion...
> 
> I want to do this to try a couple of things..
> 
> * I want to test a function like this : Cos ( z) with  z=sqrt ( (x-xo)^2 + 
> (y-yo)^2), where  (xo, yo) is the point I need to pass..
> 
> * I would like to implement the  kronecker delta property: f(x)-f(xi) where 
> xi is the coordinate of the dof
> 
> 
>  and I was also thinking that I would probably need to work with DG methods. 
> But I can try the 1D test you suggested first to find out the continuity of 
> my functions
> 
> Thank you for your help.
> 
> Edith
> 
> 
>> On Nov 2, 2017, at 1:49 AM, Denis Davydov <davyd...@gmail.com 
>> <mailto:davyd...@gmail.com>> wrote:
>> 
>> 
>> 
>> 2 нояб. 2017 г., в 2:50, Edith Sotelo <esot...@tamu.edu 
>> <mailto:esot...@tamu.edu>> написал(а):
>> 
>>> Hi Denis,
>>> Thank you for your answer but I still need to further understand some 
>>> things :  
>>> * I think I need to pass the point (xo) during assembly since it will 
>>> different for different cells ( dof coordinate or center of the cell), 
>> 
>> Unless you work with discontinuous Galerkin, then you need to be careful 
>> with how you use PUM.
>> 
>> If you take a global view of the shape functions and enrich each of them 
>> with a a given function, it will be extremely tedious to pull of. 
>> 
>> I don’t know what you are trying to do, but I suggest to draw a 1D sketch 
>> with a global view to linear shape-functions and the enriched functions 
>> (shape functions times enrichments), try to number them and see what 
>> constraints you should have on DoFs to make your FE space continuous.
>> 
>>> and I do not see how I can pass the point when declaring the function (ex. 
>>> Enrichment  (param1,param2, etc...) ) to create 
>> 
>> See below
>> 
>>> the  FE_Enriched constructor, maybe I am missing something here.
>>> 
>>> *  The thing is that  during assembly the functions are already 
>>> encapsulated  in the “enrichments” vector and if I even  create a member 
>>> function like Enrichment::get_point(Point & ) how do I apply it 
>>> to the functions that are already in the “enrichments” vector ? Maybe I can 
>>> make  the “enrichments” vector  public?...
>> 
>> Writing out of head (there could be typos): 
>> 
>> template 
>> class MyFavoriteEnrichment : public dealii::Function
>> {
>> public:
>>MyFavoriteEnrichment(const Point );
>> 
>> }
>> 
>> is what u need.
>> Look at implementation of any dealii’s functions.
>> 
>>> 
>>> Thank you for your help
>>> 
>>> Edith
>>> 
>>> 
>>> 
>>>> On Nov 1, 2017, at 5:29 PM, Denis Davydov <davyd...@gmail.com 
>>>> <mailto:davyd...@gmail.com>> wrote:
>>>> 
>>>> Hi Edith,
>>>> 
>>>> f(x-x0) is just your enrichment function derived from dealii::Function. So 
>>>> define a class which takes that extra parameter (or any number of them) 
>>>> and use it with FE_Enriched.
>>>> Assuming that your bilinear form needs gradients, then you would need to 
>>>> implement gradients of your custom function so that FE_Enriched can work 
>>>> out chain rule for you.
>>>> 
>>>> Cheers,
>>>> Denis.
>>>> 
>>>> On Wednesday, November 1, 2017 at 5:27:10 AM UTC+1, Edith Sotelo wrote:
>>>> Hello,
>>>> 
>>>> I would like to implement enrichment functions of this type: f(x-xo) where 
>>>> xo is a user defined point. It could be the center of the cell or the dof 
>>>> coordinate.
>>>> I would like a sugge

[deal.II] Re: Error when writing files using write_vtu_header

[Denis Davydov]

AFAIK there is no know problem. 
Make sure you write this only from a single MPI core, though.
Otherwise you will have multiple MPI cores trying to write into the same 
file.

Regards,
Denis.

On Tuesday, October 17, 2017 at 8:43:55 AM UTC+2, Maxi Miller wrote:
>
>
> Sometimes when running my program on a cluster with several nodes I get 
> the error
> ERROR: Uncaught exception in MPI_InitFinalize on proc 0. Skipping 
> MPI_Finalize() to avoid a deadlock.
>
>
> 
> Exception on processing:
>
> 
> An error occurred in line <5045> of file <~/Downloads/dealii/source/base/
> data_out_base.cc> in function
> void dealii::DataOutBase::write_vtu_header(std::ostream&, const dealii
> ::DataOutBase::VtkFlags&)
> The violated condition was:
> out
> Additional information:
> An input/output error has occurred. There are a number of reasons why 
> this may be happening, both for reading and writing operations.
>
> If this happens during an operation that tries to read data: First, you 
> may be trying to read from a file that doesn't exist or that is not 
> readable given its file permissions. Second, deal.II uses this error at 
> times if it tries to read information from a file but where the information 
> in the file does not correspond to the expected format. An example would be 
> a truncated file, or a mesh file that contains not only sections that 
> describe the vertices and cells, but also sections for additional data that 
> deal.II does not understand.
>
> If this happens during an operation that tries to write data: you may be 
> trying to write to a file to which file or directory permissions do not 
> allow you to write. A typical example is where you specify an output file 
> in a directory that does not exist.
> 
>
> Aborting!
> 
>
>
>
> Reproducing this error is difficult for me, after it does not emerge every 
> time, but rather sometimes, and not after a specific amount of steps. It 
> arises when trying to write files (method output_results). What could I do 
> to narrow the problem down? Or is there a known problem?
> Thank you!
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Error when applying initial values to MPI::Vector in multiple dimensions

[Denis Davydov]

interpoalate just evaluates the function at support points of FE basis 
(assuming that you have one with support points)
and sets those values to DoFs,
whereas project (as the name implies) does L2 projection. Thus as others have 
mentioned you are solving
Mx = U 
where M is the mass matrix.

Regards,
Denis.

> On 16 Oct 2017, at 21:44, 'Maxi Miller' via deal.II User Group 
> <dealii@googlegroups.com> wrote:
> 
> Yes, .interpolate() works fine. But what is the difference between 
> interpolate() and project()?
> 
> Am Montag, 16. Oktober 2017 08:54:02 UTC+2 schrieb Denis Davydov:
> Or you may want to use interpolate if this is enough
> https://www.dealii.org/developer/doxygen/deal.II/namespaceVectorTools.html#a05db6c8cebf924b417dd92f525efe3db
>  
> <https://www.dealii.org/developer/doxygen/deal.II/namespaceVectorTools.html#a05db6c8cebf924b417dd92f525efe3db>
> 
> Regards,
> Denis
> 
> On Friday, October 13, 2017 at 11:05:01 AM UTC+2, Maxi Miller wrote:
> I try to apply initial values to a vector defined as 
> LinearAlgebraTrilinos::MPI::Vector using 
> VectorTools::project (dof_handler, hanging_node_constraints,
>  QGauss(fe.degree+1),
>  InitialValues(),
>  local_solution);
> 
> 
> When initializing the variable fe (as FESystem) with one or two 
> components, it works fine. For more than two components I get the error
>  
> An error occurred in line <1366> of file 
> <~/Downloads/dealii/include/deal.II/numerics/vector_tools.templates.h> in 
> function 
> void dealii::VectorTools::{anonymous}::project(const 
> dealii::Mapping&, const dealii::DoFHandler&, const 
> dealii::ConstraintMatrix&, const dealii::Quadrature&, const 
> dealii::Function<dim, typename VectorType::value_type>&, VectorType&, bool, 
> const dealii
> ::Quadrature<(dim - 1)>&, bool) [with VectorType = 
> dealii::TrilinosWrappers::MPI::Vector; int dim = 2; typename 
> VectorType::value_type = double] 
> The violated condition was:  
> (dynamic_cast* > 
> (&(dof.get_triangulation()))==nullptr) 
> Additional information:  
> You are trying to use functionality in deal.II that is currently not 
> implemented. In many cases, this indicates that there simply didn't appear 
> much of a need for it, or that the author of the original code did not have 
> the time to implement a particular case. If you
>  hit this exception, it is therefore worth the time to look into the code to 
> find out whether you may be able to implement the missing functionality. If 
> you do, please consider providing a patch to the deal.II development sources 
> (see the deal.II website on how to contri
> bute). 
>  
> Stacktrace: 
> --- 
> #0  /opt/dealII/lib/libdeal_II.g.so.9.0.0-pre:  
> #1  /opt/dealII/lib/libdeal_II.g.so.9.0.0-pre: void 
> dealii::VectorTools::project<2, dealii::TrilinosWrappers::MPI::Vector, 
> 2>(dealii::DoFHandler<2, 2> const&, dealii::ConstraintMatrix const&, 
> dealii::Quadrature<2> const&, dealii::Function<2, 
> dealii::TrilinosWrappers::MPI
> ::Vector::value_type> const&, dealii::TrilinosWrappers::MPI::Vector&, bool, 
> dealii::Quadrature<(2)-(1)> const&, bool) 
> #2  ./main: Step15::MinimalSurfaceProblem<2>::run() 
> #3  ./main: main 
>  
>  
> [linux-lb8c:15830] *** Process received signal *** 
> [linux-lb8c:15830] Signal: Aborted (6) 
> [linux-lb8c:15830] Signal code:  (-6) 
> [linux-lb8c:15830] [ 0] /lib64/libpthread.so.0(+0x12270)[0x7f294a477270] 
> [linux-lb8c:15830] [ 1] /lib64/libc.so.6(gsignal+0x110)[0x7f2946c1f0d0] 
> [linux-lb8c:15830] [ 2] /lib64/libc.so.6(abort+0x151)[0x7f2946c206b1] 
> [linux-lb8c:15830] [ 3] 
> /opt/dealII/lib/libdeal_II.g.so.9.0.0-pre(+0x6b9e5d1)[0x7f295b49e5d1] 
> [linux-lb8c:15830] [ 4] 
> /opt/dealII/lib/libdeal_II.g.so.9.0.0-pre(_ZN6dealii18deal_II_exceptions9internals5abortERKNS_13ExceptionBaseE+0x1a)[0x7f295b49edaf]
>  
> [linux-lb8c:15830] [ 5] 
> /opt/dealII/lib/libdeal_II.g.so.9.0.0-pre(_ZN6dealii18deal_II_exceptions9internals11issue_errorINS_18StandardExceptions17ExcNotImplementedEEEvNS1_17ExceptionHandlingEPKciS7_S7_S7_T_+0x98)[0x7f2957373ea1]
>  
> [linux-lb8c:15830] [ 6] 
> /opt/dealII/lib/libdeal_II.g.so.9.0.0-pre(+0x3f38e23)[0x7f2958838e23] 
> [linux-lb8c:15830] [ 7] 
> /opt/dealII/lib/libdeal_II.g.so.9.0.0-pre(_ZN6dealii11VectorTools7projectILi2ENS_16TrilinosWrappers3MPI6VectorELi2EEEvRKNS_10DoFHandlerIXT_EXT1_EEERKNS_16ConstraintMatrixERKNS_10QuadratureIXT_EEERKNS_8FunctionIXT1_ENT0_10value_typeEEERSH_bRKNSC_IX
> miT_Li1b+0x2f)[0x7f295894906e] 
> [linux-lb8c:15830] [ 8] 
> ./

[deal.II] Re: Error when applying initial values to MPI::Vector in multiple dimensions

[Denis Davydov]

Or you may want to use interpolate if this is enough
https://www.dealii.org/developer/doxygen/deal.II/namespaceVectorTools.html#a05db6c8cebf924b417dd92f525efe3db

Regards,
Denis

On Friday, October 13, 2017 at 11:05:01 AM UTC+2, Maxi Miller wrote:
>
> I try to apply initial values to a vector defined as 
> *LinearAlgebraTrilinos::MPI::Vector 
> *using 
> VectorTools::project (dof_handler, hanging_node_constraints,
>  QGauss(fe.degree+1),
>  InitialValues(),
>  local_solution);
>
>
>
> When initializing the variable fe (as FESystem) with one or two 
> components, it works fine. For more than two components I get the error
>
>  
> An error occurred in line <1366> of file 
> <~/Downloads/dealii/include/deal.II/numerics/vector_tools.templates.h> in 
> function 
> void dealii::VectorTools::{anonymous}::project(const 
> dealii::Mapping&, const dealii::DoFHandler&, const 
> dealii::ConstraintMatrix&, const dealii::Quadrature&, const 
> dealii::Function&, VectorType&, bool, 
> const dealii
> ::Quadrature<(dim - 1)>&, bool) [with VectorType = 
> dealii::TrilinosWrappers::MPI::Vector; int dim = 2; typename 
> VectorType::value_type = double] 
> The violated condition was:  
> (dynamic_cast* > 
> (&(dof.get_triangulation()))==nullptr) 
> Additional information:  
> You are trying to use functionality in deal.II that is currently not 
> implemented. In many cases, this indicates that there simply didn't appear 
> much of a need for it, or that the author of the original code did not have 
> the time to implement a particular case. If you
>  hit this exception, it is therefore worth the time to look into the code to 
> find out whether you may be able to implement the missing functionality. If 
> you do, please consider providing a patch to the deal.II development sources 
> (see the deal.II website on how to contri
> bute). 
>  
> Stacktrace: 
> --- 
> #0  /opt/dealII/lib/libdeal_II.g.so.9.0.0-pre:  
> #1  /opt/dealII/lib/libdeal_II.g.so.9.0.0-pre: void 
> dealii::VectorTools::project<2, dealii::TrilinosWrappers::MPI::Vector, 
> 2>(dealii::DoFHandler<2, 2> const&, dealii::ConstraintMatrix const&, 
> dealii::Quadrature<2> const&, dealii::Function<2, 
> dealii::TrilinosWrappers::MPI
> ::Vector::value_type> const&, dealii::TrilinosWrappers::MPI::Vector&, bool, 
> dealii::Quadrature<(2)-(1)> const&, bool) 
> #2  ./main: Step15::MinimalSurfaceProblem<2>::run() 
> #3  ./main: main 
>  
>  
> [linux-lb8c:15830] *** Process received signal *** 
> [linux-lb8c:15830] Signal: Aborted (6) 
> [linux-lb8c:15830] Signal code:  (-6) 
> [linux-lb8c:15830] [ 0] /lib64/libpthread.so.0(+0x12270)[0x7f294a477270] 
> [linux-lb8c:15830] [ 1] /lib64/libc.so.6(gsignal+0x110)[0x7f2946c1f0d0] 
> [linux-lb8c:15830] [ 2] /lib64/libc.so.6(abort+0x151)[0x7f2946c206b1] 
> [linux-lb8c:15830] [ 3] 
> /opt/dealII/lib/libdeal_II.g.so.9.0.0-pre(+0x6b9e5d1)[0x7f295b49e5d1] 
> [linux-lb8c:15830] [ 4] 
> /opt/dealII/lib/libdeal_II.g.so.9.0.0-pre(_ZN6dealii18deal_II_exceptions9internals5abortERKNS_13ExceptionBaseE+0x1a)[0x7f295b49edaf]
>  
> [linux-lb8c:15830] [ 5] 
> /opt/dealII/lib/libdeal_II.g.so.9.0.0-pre(_ZN6dealii18deal_II_exceptions9internals11issue_errorINS_18StandardExceptions17ExcNotImplementedEEEvNS1_17ExceptionHandlingEPKciS7_S7_S7_T_+0x98)[0x7f2957373ea1]
>  
> [linux-lb8c:15830] [ 6] 
> /opt/dealII/lib/libdeal_II.g.so.9.0.0-pre(+0x3f38e23)[0x7f2958838e23] 
> [linux-lb8c:15830] [ 7] 
> /opt/dealII/lib/libdeal_II.g.so.9.0.0-pre(_ZN6dealii11VectorTools7projectILi2ENS_16TrilinosWrappers3MPI6VectorELi2EEEvRKNS_10DoFHandlerIXT_EXT1_EEERKNS_16ConstraintMatrixERKNS_10QuadratureIXT_EEERKNS_8FunctionIXT1_ENT0_10value_typeEEERSH_bRKNSC_IX
> miT_Li1b+0x2f)[0x7f295894906e] 
> [linux-lb8c:15830] [ 8] 
> ./main(_ZN6Step1521MinimalSurfaceProblemILi2EE3runEv+0xc08)[0x420d08] 
> [linux-lb8c:15830] [ 9] ./main(main+0x3c)[0x414ad0] 
> [linux-lb8c:15830] [10] 
> /lib64/libc.so.6(__libc_start_main+0xea)[0x7f2946c09f4a] 
> [linux-lb8c:15830] [11] ./main(_start+0x2a)[0x41477a] 
> [linux-lb8c:15830] *** End of error message *** 
> Abgebrochen (Speicherabzug geschrieben)
>
> when running in debug mode. It runs fine in release mode. Why does that 
> happen for more than two components, and how can I fix/circumvent that? Or 
> did I (again) forget something? 
>
> My minimal example is attached, the behaviour happens when setting 
> NUM_COMPONENTS via 
>
> #define NUM_COMPONENTS 100
>
> to a value larger than 2.
>
>
> Thank you!
>
>

-- 
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.

[deal.II] Re: Deal for Mac OS 10.13

[Denis Davydov]

Hi,

I successfully build deal.II with all dependencies on macOS High Sierra 
XCode 9 with Spack https://github.com/dealii/dealii/wiki/deal.II-in-Spack 
 (Clang 9.0 + gfortran from GCC 7.2.0)
BUT you would need to wait until this PR with minor fixes is merged: 
https://github.com/LLNL/spack/pull/5647 upstream.

Regards,
Denis.

On Tuesday, October 10, 2017 at 12:36:43 PM UTC+2, Deepak Kukrety wrote:
>
> Hi All
>
> Good day! 
>
> I am trying to install Deal.ii on an iMac. I recently upgraded to the 
> latest version of Mac OS, 10.13 and as far as I could understand the 
> version of Deal.ii presently available is not compatible with the latest 
> OS. Is there a workaround this situation or should I wait for a new Deal.ii 
> release. If so, when is the new inhaler likely to be available. 
>
> Thanks in advance
>
> Deepak 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Output the results at Gauss points

[Denis Davydov]

Hi,

Please search the forum, this question has been discussed numerous times in 
past, for example:
https://groups.google.com/forum/?fromgroups#!searchin/dealii/quadrature$20points|sort:relevance/dealii/FW9Jy5_CUGY/JK6OSFWrAQAJ
https://groups.google.com/forum/?fromgroups#!searchin/dealii/quadrature$20points|sort:relevance/dealii/pffybI-6kuY/bOetoHPcDwAJ

A quick note: displacements are given in the FE space already, so you 
should know how to output and visualize them.
Stresses are known at quadrature points, so you would need to either 
(approximately) project them to some FE space or 
output them as a collection of values of second order tensors at each point 
(you would need to dig into VTK to see what is the required format). 

Regards,
Denis.

On Tuesday, October 10, 2017 at 1:14:33 PM UTC+2, Ehsan wrote:
>
> Hello,
>
> Is there a way to output the results at Gauss points to visualize it in 
> VisIt or Paraview or Tecplot?
> (For example extract the displacement or stresses)
>
> Best regards.
> Ehsan
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Unit test in user project with .prm and .data input files to be read

[Denis Davydov]

Vinayak,

You are mixing several things, it seems.
What you should do in your unit test is something along the lines:
  
  ParameterHandler prm;
  MyLovelyParameters::declare_parameters(prm);

  // parameters
  std::ostringstream oss;
  oss << "set Something = 3"   << std::endl
  << "set LAMMPS input  = " << SOURCE_DIR << 
"/relative/path/to/input.xyz" << std::endl;

  prm.parse_input_from_string(oss.str().c_str());

  // use it to do the same as in main.cc
  // (depends on how things are implemented)

Obviously, you need to adjust this code to what you are actually doing.

The point is, dealII have functionality to run user tests in two ways:
1) take the main executable and pass .rpm file as an argument
This won't work when you need some auxiliary data which is a part of the 
test.
That is because you don't know the path from which the test will be 
executed.

2) compile .cc file and run it. In this case, you should populate whatever 
parameter 
within that .cc file. But this also requires that you separate your program 
into a library (say with a single class Problem) and
executable main.cc which actually creates an instance of that class and 
runs it.
So what you do here is essentially the same thing as your main.cc but you 
feed parameters NOT from the command line argument,
but create them yourself dynamically (SOURCE_DIR will be dynamic macro 
depending on where you actually configure/build).

Regards,
Denis

On Friday, October 6, 2017 at 4:18:24 PM UTC+2, Vinayak Gholap wrote:
>
> Hello Daniel,
>
> On Friday, October 6, 2017 at 3:09:33 PM UTC+2, Daniel Arndt wrote:
>>
>> Vinayak,
>>
>> Your error looks like you are trying to call read_input on your data file 
>> instead of the parameter file.
>> At least you seem to be able to find the correct path to your data file 
>> in the unit test and this is what this thread 
>> is about, isn't it?
>>
>> I tried to parse the .prm file but still the unit test fail. And yes I am 
> able to find the correct path to my data file but not able to run unit test 
> with it.
>
> Do you have a working setting (without the testsuite setup) for which you 
>> can treat your data file appropriately?
>> If this works, we can try to find out why it doesn't work using the 
>> testuite setting.
>>
>  
> Yes I have a working setting where I am able to read different data files 
> for different .prm files and they work as expected for all.
>
> Regards,
> Vinayak Gholap
>
>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Vector value problem with FE_Enriched

[Denis Davydov]

Hi Edith,

On Thursday, October 5, 2017 at 5:26:04 PM UTC+2, Edith Sotelo wrote:
>
> Hi deal ii community ,
>
> I  am trying to solve a similar problem as tutorial 29:  complex valued 
> -Helmoholtz equation but in this case each component of my 2D vector (real, 
> imaginary ) is a FE-Enriched Finite element.
> e.g. my constructor is of the form FEsystem  
> (fe_enriched,1,fe_enriched,1) and fe_enriched are FE_Enriched finite 
> elements.
>

instead of FESystem(fe_enriched,1,fe_enriched,1) you should rather do 
FESystem(fe_enriched,2)

otherwise deal.II won't know that the first and second FEs are the same and 
you need them for different components. 
The resulting space is the same, but in your version it will be slower to 
evaluate shape functions / solutions at the quadrature points.
 

>
>
> Question 1:
> My first test case seemed to work. My second one not so well. Either way I 
> would like to know if  this implementation is possible if not what 
> modifications are needed.
>

I have not used such things myself, but I see no reason why it won't work.
 

>
> Question 2:
> Related to the previous one. How to identiy the non-enriched/enriched 
> parts in the vector valued FE_Enriched elements. 
>

In the case above, you don't have a vector-valued FE_Enriched, you join 
together two scalar valued ones to get a vector-valued element.
Alternative is to take a vector-valued element and plug it into enrichment 
(see below)

>
> Previously Denis suggested system_to_base_index().first.first=0, but I 
> think in this case it does not apply any longer.
>

yes, that would probably not work anymore because you will be looking from 
the perspective of the outer FESystem.
btw, we updated the documentation of FE base class, see "Components and 
blocks" 
in https://www.dealii.org/developer/doxygen/deal.II/classFiniteElement.html

But if you do it the other way around (first build FESystem with two 
components and then use it in FEEnriched to extend the vector-valued space 
via enrichments) 
then you should be able to do the same tricks as before.

Regards,
Denis.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Unit test in user project with .prm and .data input files to be read

[Denis Davydov]

Hi Vinayak,

Indeed, something like

 SOURCE_DIR + "/relative/path/to/auxiliary_files.dat"

is what you need.

Regards,
Denis.

On Wednesday, October 4, 2017 at 8:37:23 PM UTC+2, Daniel Arndt wrote:
>
> Vinayak,
>
> you should be able to use the SOURCE_DIR preprocessor variable for this 
> purpose.
> Have a look at the test parameter_handler/parameter_handler_01 [1] for 
> example.
>
> Best,
> Daniel
>
> [1] 
> https://github.com/dealii/dealii/blob/2b9d1c13eea9cc28ad0b757c031d2e61bdb31fc1/tests/parameter_handler/parameter_handler_1.cc
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: about deal.II with CUDA C programming acceleration

[Denis Davydov]

Hi Chih-Che

> 21 сент. 2017 г., в 6:33, Chih-Che Chueh  написал(а):
> 
> Hi Wolfgang,
> 
> 
>> I think you are expecting too much of Bruno. He has a day job as well, for 
>> which he is paid. I think you will need to figure out the installation on 
>> your system yourself -- otherwise, Bruno (or any other among us) will be 
>> asked to do so for everyone else on the mailing list who wants to install 
>> CUDA.
> 
> 
> OK! I understand this now. 
> 
> Hi Bruno, Please ignore this request. Sorry about that.
> 
> 
>  
>> I'm going to add that installing a compiler will really only be the first 
>> step. After that, of course, comes the task of understanding how to program 
>> these graphics cards, and all of the other things that require interacting 
>> with the appropriate software levels. You will need to master all of these 
>> things at one point or other. You might as well learn how to install 
>> operating systems and compilers.
> 
> 
> Frankly speaking, all we need is write a simple, clear instruction on the 
> updating the newer version of GNU C like you in deal.II write this for p4est 
> (http://www.dealii.org/developer/external-libs/p4est.html) so that deal.II 
> users would follow easily and quickly. Is it possible for any one in deal.II 
> to have this kind of information? 

Compiling compilers is usually much more complicated than p4est. You can have a 
look at what Spack does in this Python class 
https://github.com/LLNL/spack/blob/develop/var/spack/repos/builtin/packages/gcc/package.py
But frankly I don’t think we need those instructions. In majority of cases 
users have a working compiler already. If not, you can use Spack to compile GCC 
and then the whole dealii, high level instructions are here 
https://github.com/dealii/dealii/wiki/deal.II-in-Spack
Note that you do NOT need admin rights to use it, it’s perfectly fine to do 
everything in your home folder. 

It was also mentioned above that there are newer versions of gcc available as 
Linux packages (for that u would need admin rights)

Regards,
Denis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: about deal.II with CUDA C programming acceleration

[Denis Davydov]

deal.II in Spack is being extended for 
CUDA https://github.com/LLNL/spack/pull/5402
Builds ok on Ubuntu PC with gcc 5.4.0.

Chih-Che, if you still have issues, you might want to try this out.

Regards,
Denis.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] EigenValue Problem

[Denis Davydov]

Jean-Paul is right. Most likely you don't adjust the  quadrature order which 
breaks LU factorization of the mass matrix, used by default for Generalized 
Hermitian Eigenvalue Problem. Essentially your mass matrix is not positive 
definite anymore.

Regards,
Denis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Linking error when compiling with Trilinos

[Denis Davydov]

You might want to try one of the source-based installers for deal.II, see 
*Source-based 
Installers* https://www.dealii.org/download.html

Regards,
Denis.

On Wednesday, September 13, 2017 at 10:58:10 AM UTC+2, Maxi Miller wrote:
>
> I set up a new dealII-installation on another computer, but when including 
> Trilinos, it fails with (from CMakeError.log):
>
> Performing C++ SOURCE FILE Test DEAL_II_HAVE_USABLE_FLAGS_DEBUG failed 
> with the following output:
> Change Dir: ~/Downloads/dealii/build/CMakeFiles/CMakeTmp
>
> Run Build Command:"/usr/bin/gmake" "cmTC_b88e6/fast"
> /usr/bin/gmake -f CMakeFiles/cmTC_b88e6.dir/build.make CMakeFiles/
> cmTC_b88e6.dir/build
> gmake[1]: Entering directory 
> `~/Downloads/dealii/build/CMakeFiles/CMakeTmp'
> Building CXX object CMakeFiles/cmTC_b88e6.dir/src.cxx.o
> ~/local_opt/openmpi/bin/mpic++-DDEAL_II_HAVE_USABLE_FLAGS_DEBUG 
> -pedantic -fPIC -Wall -Wextra -Wpointer-arith -Wwrite-strings -Wsynth 
> -Wsign-compare -Wswitch -Woverloaded-virtual -Wno-placement-new 
> -Wno-deprecated-declarations -Wno-literal-suffix -fopenmp-simd -std=c++14 
> -fPIC -march=native -fopenmp -Wno-parentheses -Wno-unused-local-typedefs 
> -Og -ggdb -Wa,--compress-debug-sections   -o 
> CMakeFiles/cmTC_b88e6.dir/src.cxx.o -c 
> ~/Downloads/dealii/build/CMakeFiles/CMakeTmp/src.cxx
> Linking CXX executable cmTC_b88e6
> ~/local_opt/cmake/bin/cmake -E cmake_link_script 
> CMakeFiles/cmTC_b88e6.dir/link.txt --verbose=1
> ~/local_opt/openmpi/bin/mpic++   -DDEAL_II_HAVE_USABLE_FLAGS_DEBUG 
> -pedantic -fPIC -Wall -Wextra -Wpointer-arith -Wwrite-strings -Wsynth 
> -Wsign-compare -Wswitch -Woverloaded-virtual -Wno-placement-new 
> -Wno-deprecated-declarations -Wno-literal-suffix -fopenmp-simd -std=c++14 
> -fPIC -march=native -fopenmp -Wno-parentheses -Wno-unused-local-typedefs 
> -Og -ggdb -Wa,--compress-debug-sections-rdynamic 
> CMakeFiles/cmTC_b88e6.dir/src.cxx.o  -o cmTC_b88e6 
>  -L~/local_opt/intel/tbb/lib/intel64/gcc4.7 
> -Wl,-rpath,~/local_opt/trilinos/lib:~/local_opt/boost/lib:~/local_opt/intel/tbb/lib/intel64/gcc4.7:~/local_opt/suitesparse/lib:~/local_opt/petsc/lib:~/local_opt/p4est/lib
>  
> -rdynamic -fuse-ld=gold -Wl,-rpath -Wl,~/local_opt/openmpi/lib 
> -Wl,--enable-new-dtags -ggdb /usr/lib64/libbz2.so /usr/lib64/libz.so 
> ~/local_opt/trilinos/lib/libpike-blackbox.so 
> ~/local_opt/trilinos/lib/libtrilinoscouplings.so 
> ~/local_opt/trilinos/lib/libpiro.so ~/local_opt/trilinos/lib/librol.so 
> ~/local_opt/trilinos/lib/libstokhos_muelu.so 
> ~/local_opt/trilinos/lib/libstokhos_ifpack2.so 
> ~/local_opt/trilinos/lib/libstokhos_amesos2.so 
> ~/local_opt/trilinos/lib/libstokhos_tpetra.so 
> ~/local_opt/trilinos/lib/libstokhos_sacado.so 
> ~/local_opt/trilinos/lib/libstokhos.so 
> ~/local_opt/trilinos/lib/libtempus.so 
> ~/local_opt/trilinos/lib/librythmos.so 
> ~/local_opt/trilinos/lib/libmuelu-adapters.so 
> ~/local_opt/trilinos/lib/libmuelu-interface.so 
> ~/local_opt/trilinos/lib/libmuelu.so ~/local_opt/trilinos/lib/libmoertel.so 
> ~/local_opt/trilinos/lib/liblocathyra.so 
> ~/local_opt/trilinos/lib/liblocaepetra.so 
> ~/local_opt/trilinos/lib/liblocalapack.so 
> ~/local_opt/trilinos/lib/libloca.so 
> ~/local_opt/trilinos/lib/libnoxepetra.so 
> ~/local_opt/trilinos/lib/libnoxlapack.so ~/local_opt/trilinos/lib/libnox.so 
> ~/local_opt/trilinos/lib/libphalanx.so 
> ~/local_opt/trilinos/lib/libstk_expreval.so 
> ~/local_opt/trilinos/lib/libstk_mesh_fixtures.so 
> ~/local_opt/trilinos/lib/libstk_tools_lib.so 
> ~/local_opt/trilinos/lib/libstk_transfer_impl.so 
> ~/local_opt/trilinos/lib/libstk_search_util_base.so 
> ~/local_opt/trilinos/lib/libstk_search.so 
> ~/local_opt/trilinos/lib/libstk_unit_main.so 
> ~/local_opt/trilinos/lib/libstk_unit_test_utils.so 
> ~/local_opt/trilinos/lib/libstk_io_util.so 
> ~/local_opt/trilinos/lib/libstk_io.so 
> ~/local_opt/trilinos/lib/libstk_mesh_base.so 
> ~/local_opt/trilinos/lib/libstk_topology.so 
> ~/local_opt/trilinos/lib/libstk_util_use_cases.so 
> ~/local_opt/trilinos/lib/libstk_util_registry.so 
> ~/local_opt/trilinos/lib/libstk_util_diag.so 
> ~/local_opt/trilinos/lib/libstk_util_env.so 
> ~/local_opt/trilinos/lib/libstk_util_parallel.so 
> ~/local_opt/trilinos/lib/libstk_util_util.so 
> ~/local_opt/trilinos/lib/libintrepid2.so 
> ~/local_opt/trilinos/lib/libintrepid.so ~/local_opt/trilinos/lib/libteko.so 
> ~/local_opt/trilinos/lib/libfei_trilinos.so 
> ~/local_opt/trilinos/lib/libfei_base.so 
> ~/local_opt/trilinos/lib/libstratimikos.so 
> ~/local_opt/trilinos/lib/libstratimikosbelos.so 
> ~/local_opt/trilinos/lib/libstratimikosaztecoo.so 
> ~/local_opt/trilinos/lib/libstratimikosamesos.so 
> ~/local_opt/trilinos/lib/libstratimikosml.so 
> ~/local_opt/trilinos/lib/libstratimikosifpack.so 
> ~/local_opt/trilinos/lib/libifpack2-adapters.so 
> ~/local_opt/trilinos/lib/libifpack2.so 
> ~/local_opt/trilinos/lib/libanasazitpetra.so 
> ~/local_opt/trilinos/lib/libModeLaplace.so 
> ~/local_opt/trilinos/lib/libanasaziepetra.so 
> 

Re: [deal.II] Re: about deal.II with CUDA C programming acceleration

[Denis Davydov]

> On 17 Sep 2017, at 01:00, Bruno Turcksin <bruno.turck...@gmail.com> wrote:
> 
> Denis,
> 
> 2017-09-16 18:30 GMT-04:00 Denis Davydov <davyd...@gmail.com 
> <mailto:davyd...@gmail.com>>:
> @Bruno I don't any experience with cuda, but do we need anything special but  
> $spack install cuda
> to use it?
> 
> I wouldn't use spack to install cuda  because there is nothing to compile. 
> You need binaries and you need drivers that depends on your kernel. If you 
> try to do something a little bit too exotic you get into

I though you could also get binaries (nvcc) and the rest by compiling CUDA, 
i.e. 
https://developer.nvidia.com/compute/cuda/8.0/Prod2/local_installers/cuda_8.0.61_375.26_linux-run
 
<https://developer.nvidia.com/compute/cuda/8.0/Prod2/local_installers/cuda_8.0.61_375.26_linux-run>
 
but of course one can also set it as an externally provided package.

> trouble when you upgrade your kernel or your drivers (I have been there...).
>  
> I guess one way is to use directly cuda compiler wrappers. It also looks like 
> openmpi can be compiled with cuda support (then maybe MPI wrappers can be 
> used directly?).
> cuda support in openmpi allows you to by-pass the cpu when you want to send a 
> MPI message from one GPU to another GPU. I don't think it changes the wrapper.

ok, thanks for explanation.

>  
> If you can roughly tell me how this shall work, I can try blindly extend 
> deal.II package in Spack for CUDA and wait for you to test.
> I'll try to do it myself. I'll you know if I hit a road block. 

great!

If you hit some issues using/building with CUDA, maybe create an issue/question 
on either
https://github.com/LLNL/spack/issues <https://github.com/LLNL/spack/issues> or
https://groups.google.com/forum/?fromgroups#!forum/spack 
<https://groups.google.com/forum/?fromgroups#!forum/spack> 
I am sure one of the sysadmins who use Spack to manager HPC cluster must be 
playing with CUDA as well.

Cheers,
Denis.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Workstream, number threads

[Denis Davydov]

A bit off topic: if one is not careful and mixes multithreaded Blas/Lapack 
+ multithreading via TBB in deal.II,
then calls to Lapack's invert() can take 1.371e+03s instead of 1.445e+00s 
;-)

p.s. threading in Spack's Openblas and friends is being reworked here 
https://github.com/LLNL/spack/pull/5340 

Regards,
Denis.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Workstream, number threads

[Denis Davydov]

On Thursday, December 29, 2016 at 11:43:15 AM UTC+1, Praveen C wrote:
>
> Hello Martin
>
> I am using openblas installed using spack. openmp seems to be disabled
>
> openblas@0.2.19%gcc@6~openmp+pic+shared arch=linux-opensuse20161217-x86_64
>
>
I think the problem was that Openblas by default builds with USE_THREAD=1 
which uses pthreads
thus you saw 1700% usage. 
I will fix this in Spack to have a finer control over threading.

Regards,
Denis.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Using deal.II logo in publication

[Denis Davydov]

FYI, this logo is done with a help of qualified (master degree) graphic 
designer.

On Monday, August 28, 2017 at 11:09:33 PM UTC+2, Timo Heister wrote:
>
> Personally, I prefer the colors and font I used. I like the green dot 
> though! 
>
> On Mon, Aug 28, 2017 at 5:05 PM, Denis Davydov <davy...@gmail.com 
> > wrote: 
> > Ok, here's my final suggestion for a logo. 
> > The writing is based on Courier IBM, changed to curves and further 
> tweaked. 
> > Three colours are print friendly. 
> > 
> > Regards, 
> > Denis. 
> > 
> > On Monday, August 28, 2017 at 5:59:16 PM UTC+2, Wolfgang Bangerth wrote: 
> >> 
> >> On 08/28/2017 09:35 AM, Matthias Maier wrote: 
> >> > As already mentioned off-list. 
> >> > 
> >> > We should switch to a font with a clear and open license anyway. 
> >> > 
> >> > Maybe the twentieth anniversary is a perfect opportunity to slightly 
> >> > change the logo (and colors)?:-) 
> >> 
> >> I think that proposing to use a different font is fair game while we 
> >> look at the logo. I don't have a particular preference though I think 
> an 
> >> upright and clean font looks best. 
> >> 
> >> Best 
> >>   W. 
> >> 
> >> -- 
> >> 
>  
> >> Wolfgang Bangerth  email: bang...@colostate.edu 
> >> www: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.math.colostate.edu_-7Ebangerth_=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=VHv-93Hk9mFM5V01nRU5p7S25EX9HhkM3KlYVPmn4KQ=75bPffEy-zAuROXcnVn9AgfRbahWA6ufCZwVAYRYGnE=
>  
> > 
> > -- 
> > The deal.II project is located at 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.dealii.org_=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=VHv-93Hk9mFM5V01nRU5p7S25EX9HhkM3KlYVPmn4KQ=nHyL_JGldywEA58_hIbBLxNM6fCBs3RSmiPyuY50-O4=
>  
> > For mailing list/forum options, see 
> > 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_forum_dealii-3Fhl-3Den=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=VHv-93Hk9mFM5V01nRU5p7S25EX9HhkM3KlYVPmn4KQ=4dx7varHluxvCKa9uz1-YUDfln0RJtImWN0d4LZvTX0=
>  
> > --- 
> > 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+un...@googlegroups.com . 
> > For more options, visit 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout=DwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=VHv-93Hk9mFM5V01nRU5p7S25EX9HhkM3KlYVPmn4KQ=BHhfVtF3RL6Xl_ss1wFpnd-bqYaX6IXDQF_RL32phBM=
>  
> . 
>
>
>
> -- 
> Timo Heister 
> http://www.math.clemson.edu/~heister/ 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Using deal.II logo in publication

[Denis Davydov]

I am fine with adjusting colours, but I like the IBM Courier font as it has 
relevant history behind. 
I believe it is this font which is currently used on a low resolution logo and 
to my knowledge this font is royalty free.
So i would stick with it.

> On 28 Aug 2017, at 17:35, Matthias Maier  wrote:
> 
> As already mentioned off-list.
> 
> We should switch to a font with a clear and open license anyway.
> 
> Maybe the twentieth anniversary is a perfect opportunity to slightly
> change the logo (and colors)? :-)
> 
> Best,
> Matthias
> 
> 
> On Mon, Aug 28, 2017, at 10:05 CDT, Jean-Paul Pelteret  
> wrote:
> 
>> Maybe, but its not our current logo but rather a new one? ;-)
>> 
>> On Monday, August 28, 2017 at 5:00:12 PM UTC+2, Timo Heister wrote:
>>> 
>>> My counter: 
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__files.gitter.im_dealii_itGp_logo.png=DwIFaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=w-OWsHSFKFvDnpVW9zIrDHHbhcbF69VVZ8_l2TDrs14=7eUaIGiXA633AbVNkMhhGfFdN0m9fwdDWm8xewuKO48=
>>> 
>>> nicer font and nicer colors in my opinion. 
>>> 
> 
> -- 
> 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 a topic in the Google 
> Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/dealii/VkYm3p1I6qQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> dealii+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Using deal.II logo in publication

[Denis Davydov]

What I apparently meant is that two sides of the quarter would not be the same 
and thus the logo will be "less" symmetric.
But you are right, one could always recreate the whole logo from a quarter.

Sent from iPhone, please excuse my brevity.

> 27 авг. 2017 г., в 10:43, Jean-Paul Pelteret <jppelte...@gmail.com> 
> написал(а):
> 
> Can't one just trace a quarter and mirror it?
> 
>> On Sunday, August 27, 2017 at 10:05:00 AM UTC+2, Denis Davydov wrote:
>> another take on tracing the lowres logo via Adobe Illustrator CS6. The main 
>> difference to TImo's is the shape of yellow rim,
>> which IMO is closer to the original raster logo.
>> 
>> But indeed, there is no hope to keep it symmetric based on lowres input, 
>> unless someones jus draws it from scratch :-)
>> 
>> Cheers,
>> Denis.
>> 
>>> On Saturday, August 26, 2017 at 2:03:29 AM UTC+2, Wolfgang Bangerth wrote:
>>> On 08/25/2017 02:14 PM, Timo Heister wrote: 
>>> > I did a quick vector-art sketch of the logo. Infinite resolution! It 
>>> > is not 100% symmetric because I traced the image you sent. Maybe a 
>>> > good starting point though? Maybe we can take the opportunity and 
>>> > tweak the shape/colors a bit? 
>>> 
>>> Nice job. I don't think the asymmetry is visible. Anyone with picture 
>>> editing capabilities out here on the mailing list who'd like to help out 
>>> with the logo? 
>>> 
>>> Cheers 
>>>   W. 
>>> 
>>> -- 
>>>  
>>> Wolfgang Bangerth  email: bang...@colostate.edu 
>>> www: http://www.math.colostate.edu/~bangerth/ 
> 
> -- 
> 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 a topic in the Google 
> Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/dealii/VkYm3p1I6qQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> dealii+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Using deal.II logo in publication

[Denis Davydov]

I tried that already, the problem is that the sides of the quarter would not 
have the symmetry to build the whole logo

Sent from iPhone, please excuse my brevity.

> 27 авг. 2017 г., в 10:43, Jean-Paul Pelteret <jppelte...@gmail.com> 
> написал(а):
> 
> Can't one just trace a quarter and mirror it?
> 
>> On Sunday, August 27, 2017 at 10:05:00 AM UTC+2, Denis Davydov wrote:
>> another take on tracing the lowres logo via Adobe Illustrator CS6. The main 
>> difference to TImo's is the shape of yellow rim,
>> which IMO is closer to the original raster logo.
>> 
>> But indeed, there is no hope to keep it symmetric based on lowres input, 
>> unless someones jus draws it from scratch :-)
>> 
>> Cheers,
>> Denis.
>> 
>>> On Saturday, August 26, 2017 at 2:03:29 AM UTC+2, Wolfgang Bangerth wrote:
>>> On 08/25/2017 02:14 PM, Timo Heister wrote: 
>>> > I did a quick vector-art sketch of the logo. Infinite resolution! It 
>>> > is not 100% symmetric because I traced the image you sent. Maybe a 
>>> > good starting point though? Maybe we can take the opportunity and 
>>> > tweak the shape/colors a bit? 
>>> 
>>> Nice job. I don't think the asymmetry is visible. Anyone with picture 
>>> editing capabilities out here on the mailing list who'd like to help out 
>>> with the logo? 
>>> 
>>> Cheers 
>>>   W. 
>>> 
>>> -- 
>>>  
>>> Wolfgang Bangerth  email: bang...@colostate.edu 
>>> www: http://www.math.colostate.edu/~bangerth/ 
> 
> -- 
> 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 a topic in the Google 
> Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/dealii/VkYm3p1I6qQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> dealii+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Using deal.II logo in publication

[Denis Davydov]

another take on tracing the lowres logo via Adobe Illustrator CS6. The main 
difference to TImo's is the shape of yellow rim,
which IMO is closer to the original raster logo.

But indeed, there is no hope to keep it symmetric based on lowres input, 
unless someones jus draws it from scratch :-)

Cheers,
Denis.

On Saturday, August 26, 2017 at 2:03:29 AM UTC+2, Wolfgang Bangerth wrote:
>
> On 08/25/2017 02:14 PM, Timo Heister wrote: 
> > I did a quick vector-art sketch of the logo. Infinite resolution! It 
> > is not 100% symmetric because I traced the image you sent. Maybe a 
> > good starting point though? Maybe we can take the opportunity and 
> > tweak the shape/colors a bit? 
>
> Nice job. I don't think the asymmetry is visible. Anyone with picture 
> editing capabilities out here on the mailing list who'd like to help out 
> with the logo? 
>
> Cheers 
>   W. 
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> www: http://www.math.colostate.edu/~bangerth/ 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Installation didn't give any errors but when I tried make test, it failed all tests

[Denis Davydov]

Hi Japan,

I am happy to hear that it worked and you resolved your problem!

Sincerely,
Denis.

> On 14 Aug 2017, at 04:13, Japan Patel  wrote:
> 
> Hey everyone,
> 
> Thanks Dr. Bangerth and thanks Denis!!
> 
> I was able to run step-1. I installed using spack. It took a while to 
> download all the packages and install them but it was worth it as I was able 
> to run an example problem which I wasn't able to before and all the packages 
> are already linked which would have been a huge hassle had I installed them 
> separately and then tried to link with dealii. Thank you so much for shipping 
> dealii in this format. I really appreciate it! 
> 
> I think I can follow Dr. Bangerth's online lectures now and learn how to use 
> dealii. 
> 
> Sincerely,
> Japan
> 
> On Sun, Aug 13, 2017 at 11:29 AM,  > wrote:
> Thanks. I was able to find the other thread regarding my problem and was able 
> to use the correct cmake flags to get dealii to install correctly. Thank you 
> for your help!
> 
> On Saturday, August 12, 2017 at 5:50:13 PM UTC-6, Wolfgang Bangerth wrote:
> On 08/12/2017 05:21 PM, drgeoff...@gmail.com <> wrote: 
> > I'm wondering if I could tag onto this message. I'm having a similar 
> > problem. 
> > Installed with no problems. However, when I run the tests, they all fail 
> > with 
> > the error: 
> > 
> > symbol lookup error: /usr/lib/libumfpack.so.3.1.0: undefined symbol: 
> > amd_realloc 
> 
> That seems like a separate issue unless you also get the error messages about 
> the CXXABI or GLIBCXX version mismatch. 
> 
> I think there was a question about your error on the mailing list a while 
> ago. 
> Can you try to search for it? 
> 
> Best 
>   W. 
> 
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu <> 
> www: http://www.math.colostate.edu/~bangerth/ 
>  
> 
> 
> 
> -- 
> 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 a topic in the Google 
> Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/dealii/N3WvNvLV3lg/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> dealii+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Installation didn't give any errors but when I tried make test, it failed all tests

[Denis Davydov]

Hi,

Usually, one compiles some MPI provider (i.e. Openmpi) and then use its 
compiler wrappers in majority of dealii' dependencies.

Alternativelt ou can give Spack 
https://github.com/dealii/dealii/wiki/deal.II-in-Spack a try which guarantees 
that the whole toolchain is consistent: a single version of a library is used 
in dependents and (by default) the same compiler is used to build everything.

Regards,
Denis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Status of support for complex equations?

[Denis Davydov]

Have a look at this issue which aggregates efforts in this 
direction: https://github.com/dealii/dealii/issues/2033
Essentially, the main missing piece is ConstraintMatrix 
https://github.com/dealii/dealii/issues/1760 
which Matthias wanted to do over the weekend in July 2016 :-) I think there 
is a prototype branch, 
so if you need to work with complex-valued algebra, you might want to look 
at this issue.

Cheers,
Denis.

On Wednesday, July 19, 2017 at 4:59:08 PM UTC+2, Maxi Miller wrote:
>
> Hei,
> I was wondering if dealII already natively supports equations containing 
> imaginary values, such as
>   
> 
> or if I still have to split them up, such as in example 29?
> Thank you!
>
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] segmentation fault when calling make_vectorized_array

[Denis Davydov]

Thanks a lot for your help, Martin!

Cheers,
Denis

> On 13 Jul 2017, at 11:02, Martin Kronbichler  
> wrote:
> 
> Hi Denis,
> 
>> While on the topic of alignment, do I need to be more careful about using
>> 
>> template 
>> struct QPData
>> {
>>Table<2, VectorizedArray > values;
>> }
>> QPData qp_data;
>> 
>> as a member variable in my class? 
> 
> Table is fine because it is based on AlignedVector, so it 
> will use the correct alignment internally.
> 
> Best,
> Martin
> 
> -- 
> 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 a topic in the Google 
> Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/dealii/xccZy4KU7Zc/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> dealii+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] segmentation fault when calling make_vectorized_array

[Denis Davydov]

Hi Martin,

> On 13 Jul 2017, at 09:13, Martin Kronbichler  
> wrote:
> 
>> 
>> no, it's just a member variable VectorizedArray: 
>> 
>> VectorizedArray a;
> 
> But then the class/struct that holds this member variable is not properly 
> aligned, you probably have it inside an std::vector or allocated it with 
> 'new'. You will need to put it into an AlignedVector or similar type.

this is a matrix-free level operator which lives in MGLevelObject.
Indeed, internally it stores objects in std::vector of shared pointers.

> Alternatively you need to wrap the member that is of type VectorizedArray 
> into an t.

This worked, thanks a lot!


While on the topic of alignment, do I need to be more careful about using

template 
struct QPData
{
   Table<2, VectorizedArray > values;
}
QPData qp_data;

as a member variable in my class? 

> 
>> 
>>   >│0x773913cb ::Operator()+35> 
>>   vmovaps %ymm0,0xe0(%rbx)
> 
> This is the offending instruction. The compiler tries to store to the address 
> given by an offset of 0xe0 (224 bytes) to the value in %rbx, using an 
> 'aligned' store operation (vmovAps) that assumes 32 byte alignment. If you 
> print the value of %rbx (in gdb with 'print $rbx'), I'm pretty sure you get 
> an address that is divisible by 16 but not by 32. It is a pity that the 
> compiler / API of the intrinsics forces the compiler to 

indeed:

(gdb) print $rbx
$1 = 22305328

Thanks a lot for detailed explanation.

Kind regards,
Denis.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] segmentation fault when calling make_vectorized_array

[Denis Davydov]

Hi Martin,

On Wednesday, July 12, 2017 at 6:05:30 PM UTC+2, Martin Kronbichler wrote:
>
> Hi Denis,
>
> what is a? Is it an element of an array? If yes, is the array of type 
> AlignedVector (or derived from that). 
>

no, it's just a member variable VectorizedArray: 

VectorizedArray a;

 

> You get this kind of error when there is a load or store to an address 
> that is not aligned by the size of the vectorized array, 32 bytes in your 
> case. The data types VectorizedArray make the compiler insert 'aligned 
> load/store' type of operations, which cannot always be guaranteed.
>
> Can you try to look at the problem in a debugger, e.g. gdb and post the 
> offending assembler line and a few before that to see the context?
>

here they are:

0x773913b1 ::Operator()+9> 
   mov%rdi,%rbx 
   │0x773913b4 ::Operator()+12>   callq  0x771d1f90 
<_ZN6dealii19MatrixFreeOperators4BaseILi3ENS_13LinearAlgebra11distributed6VectorIfEEEC2Ev@plt
   │0x773913b9 ::Operator()+17>   mov0x9ecd60(%rip),%rax# 0x77d7e120 
 
   │0x773913c0 ::Operator()+24>   lea0x10(%rax),%rax  
   │0x773913c4 ::Operator()+28>   mov%rax,(%rbx)  
   │0x773913c7 ::Operator()+31>   vxorps %xmm0,%xmm0,%xmm0
  >│0x773913cb ::Operator()+35>   vmovaps %ymm0,0xe0(%rbx)
   │0x773913d3 ::Operator()+43>   vmovaps 0x64ffc5(%rip),%ymm0# 0x779e13a0
   │0x773913db ::Operator()+51>   vmovaps %ymm0,0x100(%rbx)   
   │0x773913e3 ::Operator()+59>   mov-0x8(%rbp),%rbx 
   │0x773913e7 ::Operator()+63>   leaveq   
   │0x773913e8 ::Operator()+64>   retq

(I did a few replacement to ease the readability). Hopefully you can make 
sense out of it. 

Regards,
Denis. 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: CMake extra libraries?

[Denis Davydov]

On Friday, June 16, 2017 at 5:43:27 PM UTC+2, Wolfgang Bangerth wrote:
>
> On 06/15/2017 03:32 PM, Bruno Turcksin wrote: 
> > The problem is that 
> > Trilinos botched their TrilinosConfig.cmake. What we do is load the 
> > TrilinosConfig.cmake to get their flags but if they don't put them in, 
> > there is little we can do. 
>

What is done in both Spack 
(https://github.com/LLNL/spack/blob/develop/var/spack/repos/builtin/packages/trilinos/package.py#L578-L590)
 
and Homebrew 
(https://github.com/Homebrew/homebrew-science/blob/master/trilinos.rb#L286-L289)
 
is to manually remove PyTrilinos from COMPONENTS_LIST in 
/lib/cmake/Trilinos/TrilinosConfig.cmake
This issue is known to Trilinos for some time 
already https://github.com/trilinos/Trilinos/issues/866 , to my knowledge 
the first mentioning is May 2015
https://github.com/Homebrew/homebrew-science/issues/2148#issuecomment-103614509 
.

Regards,
Denis. 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: CMake extra libraries?

[Denis Davydov]

> On 15 Jun 2017, at 19:38, Victor Eijkhout  wrote:
> 
>  You seem to be saying that I need to add something to a file that is 
> generated by cmake.

Nope. You add things to **your** CMakeList.txt

> 
> And even then, it seems to be about a file deal.IIFeatureConfig.cmake which I 
> can't find anywhere.

You need to install the current development version of deal.II (from GitHub 
master branch).
Then in CMake of **your** project after deal.II is found you do

INCLUDE(${DEAL_II_FEATURE_CONFIG})

to have DEAL_II_TRILINOS_DIR available, which will point to the Trilinos used 
to build deal.II.

Then you use https://cmake.org/cmake/help/v3.0/command/find_package.html 
 to re-find the 
Trilinos with extra libraries you need for your project.
Something like

find_package(Trilinos COMPONENTS  HINTS 
${DEAL_II_TRILINOS_DIR})

alternatively you can do

  FIND_LIBRARY(Trilinos_extra
NAMES 
HINTS ${DEAL_II_TRILINOS_DIR}/lib
NO_DEFAULT_PATH
  )
  TARGET_LINK_LIBRARIES(${YOUR_TARGET_NAME}
  "${Trilinos_extra}"
)


> Victor
> 
> PS so there is no simple flag for "add these libraries”?

I don’t know a simpler way with CMake.


Regards,
Denis.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] CMake extra libraries?

[Denis Davydov]

U need to build with current master branch, look at commit message here 
https://github.com/dealii/dealii/pull/4437 essentially u would get the location 
of Trilinos used by deal.ii and link in extra libs

Regards,
Denis

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: state of dealii in complex arithmetics

[Denis Davydov]

On Tuesday, May 23, 2017 at 5:22:44 PM UTC+2, Juan Carlos Araujo Cabarcas 
wrote:
>
> Dear all,
>
> There are features in SLEPc 3.7 that I am interested in, and will try to 
> make a fresh re-installation soon.
>
> I have been using deal.II 8.3 with complex arithmetic’s from the branch: 
> git checkout branch_petscscalar_complex
> and I wonder about the state of that branch, or if it has been merged to 
> the master branch.
>

yes, everything in that branch is in the main repo from 8.4.2 or even 
earlier.
 

>
> Thanks in advance,
>
> Juan Carlos Araújo,
> Umeå Universitet
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Does dell.II support comformal mesh adaption.

[Denis Davydov]

Hi,


On Thursday, May 18, 2017 at 12:49:32 AM UTC+2, Peng Ding wrote:
>
> Dear sir:  
>I want to use the mesh adaptive capability of dell.II for my 
> incompressible flow FVM computation.  I want to know that does dell.II 
> suport conformal mesh adaption(do not have hanging node in the face).
>

that i snot possible. That being said, you really don't need to think to 
much about hanging nodes when using deal.II. 
The constraints are taken care off automatically when you do 
ConstraintMatrix::distributed_local_to_global()  for local vectors and 
matrices.

Regards,
Denis

>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] AssertDimension (partition_blocks[partition], task_info.n_blocks) when calling MatrixFree::reinit() for finest level in GMG

[Denis Davydov]

Correct!

> On 14 May 2017, at 10:50, Daniel Arndt  
> wrote:
> 
> Denis,
> 
> this is solved by https://github.com/dealii/dealii/pull/4376, isn't it?
> 
> -- 
> 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 a topic in the Google 
> Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/dealii/zSC33HFN9AA/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> dealii+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] AssertDimension (partition_blocks[partition], task_info.n_blocks) when calling MatrixFree::reinit() for finest level in GMG

[Denis Davydov]

Just to confirm my sanity, I can reproduce the error by loading in the 
p::d::Tria and setting up GMG objects.
Of course, that does not really help anyone to try this as the refinement 
history in p::d::Tria::save() is written as a binary file... :-(



On Saturday, May 6, 2017 at 8:00:36 AM UTC+2, Martin Kronbichler wrote:
>
> Hi Denis, 
>
> This is a bug somewhere in the initialization of the blocks. Could you 
> please send me the code to reproduce this behavior? 
>
> Best, 
> Martin 
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Parallel GridIn of large file - PETSC Error

[Denis Davydov]

p.s. could also be 
this https://groups.google.com/forum/#!topic/dealii/zSC33HFN9AA
 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Parallel GridIn of large file - PETSC Error

[Denis Davydov]

It could be whatever. PETSc intercepts error and always print such things 
even when it happens outside of PETSc, which I find very inconvenient.
Try compiling and running in Debug mode.

On Tuesday, May 9, 2017 at 12:40:22 PM UTC+2, Mathias Mentler wrote:
>
> Hi everybody, 
>
> I am currently trying to read in a large (~300MB) .msh mesh-file by using 
> the GridIn-workflow (described here 
> 
>  ). 
> My triangulation is of type parallel::distributed::Triangulation. I then 
> use four nodes (each with 64GB RAM and 40 processors) of a cluster, 
> accordingly spawn 160 processes and try to do my computations. However 
> while doing the ".read_msh()"-bit I get a PETSC-error I can't make sense 
> of. What I get from one process is:
>
> [0]PETSC ERROR: 
> 
> [0]PETSC ERROR: Caught signal number 15 Terminate: Some process (or the 
> batch system) has told this process to end
> [0]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger
> [0]PETSC ERROR: or see 
> http://www.mcs.anl.gov/petsc/documentation/faq.html#valgrind
> [0]PETSC ERROR: or try http://valgrind.org on GNU/linux and Apple Mac OS 
> X to find memory corruption errors
> [0]PETSC ERROR: configure using --with-debugging=yes, recompile, link, and 
> run
> [0]PETSC ERROR: to get more information on the crash.
> [0]PETSC ERROR: - Error Message 
> --
> [0]PETSC ERROR: Signal received
> [0]PETSC ERROR: See http://www.mcs.anl.gov/petsc/documentation/faq.html 
> for trouble shooting.
> [0]PETSC ERROR: Petsc Release Version 3.7.5, Jan, 01, 2017
> [0]PETSC ERROR: Configure options 
> --prefix=/home/woody/iwtm/iwtm002h/spack_dealii/spack/opt/spack/linux-centos7-x86_64/gcc-4.8.5/petsc-3.7.5-6itsodseoiu5dr5aizwji7ki42p7gg7y
>  
> --with-ssl=0 --with-x=0 --download-c2$
> [0]PETSC ERROR: #1 User provided function() line 0 in  unknown file
>
>
> Could there be a problem with the needed memory? From what I read in a 
> related 
> question 
> ,
>  
> each process holds the coarsest mesh and since I don't refine the mesh any 
> further, each process will hold the entire mesh/triangulation. 
>
>
> Regards,
>
> Mathias 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Trouble with integrating Trilinos with Deal II

[Denis Davydov]

To check that I installed 8.4.1 with Spack 
(see https://github.com/dealii/dealii/wiki/deal.II-in-Spack ) on our Centos 
7 cluster,
and step-32 links perfectly fine with 8.4.1 and Trilinos 12.10.1.

$ ldd step-32 | grep dealii
libdeal_II.g.so.8.4.1 => 
/spack/opt/spack/linux-centos7-x86_64/gcc-4.8.5/dealii-8.4.1-rcitxfsnmzirmrvdgyeau43zj5s33axb/lib/libdeal_II.g.so.8.4.1
 
(0x7fd205805000)
$ ldd step-32 | grep trilinos
libtrilinoscouplings.so.12 => 
/spack/opt/spack/linux-centos7-x86_64/gcc-4.8.5/trilinos-12.10.1-wg6gih3cwtvbqrb7l54yr7zrsdwdimud/lib/libtrilinoscouplings.so.12
 
(0x7f4316047000)


Something is wrong in how you build Trilinos, maybe try using available 
package manager (Spack / Candi ).

Regards,
Denis.

On Monday, May 8, 2017 at 6:09:26 PM UTC+2, Tim Miley wrote:
>
> I deleted and recreated the build directory, then ran the cmake again, and 
> then did make -j 20 and make install.
>
> No change.  The step-32 still fails to compile due to those apparently 
> missing trilinos wrappers.  I did try an older version of Trilinos this 
> time, 11.8.1, just in case there were issues with the newer version.
>
> I may try to download 8.5.0 and see if that works.
>
> On Monday, May 1, 2017 at 8:03:12 AM UTC-7, Tim Miley wrote:
>>
>> Hello.
>>
>>
>> I’m a system administrator trying to build Trilinos for inclusion into 
>> the Deal II software.  I asked this question on the Trilinos user group, 
>> but they told me to ask here.
>>
>>
>> I have built Trilinos 12.10.1 with Deal II 8.4.1.
>>
>>  
>>
>> I used these modules to build Trilinos and these cmake options:
>>
>> Modules used:
>>
>>   1) gnu/4.7.24) p4est/1.17) swig/3.0.12
>>
>>   2) openmpi/2.1.05) hdf5/1.8.18  8) cmake/3.4.1
>>
>>   3) superlu/5.1.26) parmetis/4.0.2
>>
>>  
>>
>> cmake ../trilinos-12.10.1-Source \
>>
>> -DTrilinos_ENABLE_Sacado=ON \
>>
>> -DTrilinos_ENABLE_Stratimikos=ON \
>>
>> -DTrilinos_ENABLE_MueLu=ON \
>>
>> -DCMAKE_BUILD_TYPE=RELEASE \
>>
>> -DBLAS_LIBRARY_NAMES:STRING="blas" \
>>
>> -DLAPACK_LIBRARY_NAMES:STRING="lapack" \
>>
>> -DCMAKE_VERBOSE_MAKEFILE=FALSE \
>>
>> -DTrilinos_VERBOSE_CONFIGURE=FALSE \
>>
>> -DTPL_ENABLE_MPI=ON \
>>
>> -DBUILD_SHARED_LIBS=ON \
>>
>> -DCMAKE_INSTALL_PREFIX=/gpfs3/applications/trilinos/12.10.1/$MODULES_MPINAME/$MODULES_MPIVER/$MODULES_CVEN/$MODULES_CVER
>>  
>> \
>>
>> -DTPL_ENABLE_MKL=OFF \
>>
>> -DTPL_ENABLE_BLAS=ON \
>>
>> -DTPL_ENABLE_LAPACK=ON \
>>
>> -DTPL_BLAS_LIBRARIES='blas' \
>>
>> -DTPL_LAPACK_LIBRARIES='lapack' \
>>
>> -DTPL_ENABLE_Matio=OFF \
>>
>> -DTrilinos_ENABLE_CXX11=ON \
>>
>> -DBUILD_SHARED_LIBS=OFF
>>
>>  
>>
>> I saw no notable errors, and the software installed without issues.  With 
>> Deal II, I used this:
>>
>>  
>>
>> Module used:
>>
>>   1) gnu/4.7.2  4) p4est/1.1  7) swig/3.0.12
>>
>>   2) openmpi/2.1.0  5) hdf5/1.8.188) cmake/3.4.1
>>
>>   3) superlu/5.1.2  6) parmetis/4.0.2 9) trilinos/12.10.1
>>
>>  
>>
>> cmake 
>> -DCMAKE_INSTALL_PREFIX=/gpfs3/applications/deal_II/8.4.1/$MODULES_MPINAME/$MODULES_MPIVER/$MODULES_CVEN/$MODULES_CVER
>>  
>> \
>>
>> -DDEAL_II_WITH_THREADS=OFF \
>>
>> -DDEAL_II_WITH_MPI=ON \
>>
>> -DDEAL_II_WITH_PETSC=OFF \
>>
>> -DDEAL_II_WITH_NETCDF=OFF \
>>
>> -DP4EST_DIR=/gpfs3/applications/p4est/1.1/$MODULES_MPINAME/$MODULES_MPIVER/$MODULES_CVEN/$MODULES_CVER
>>  
>> \
>>
>> -DHDF5_DIR=/gpfs3/applications/hdf5/1.8.18/$MODULES_MPINAME/$MODULES_MPIVER/$MODULES_CVEN/$MODULES_CVER
>>  
>> \
>>
>> -DTRILINOS_DIR=/gpfs3/applications/trilinos/12.10.1/$MODULES_MPINAME/$MODULES_MPIVER/$MODULES_CVEN/$MODULES_CVER
>>  
>> \
>>
>> -DDEAL_II_COMPONENT_PARAMETER_GUI=ON \
>>
>> -DDEAL_II_WITH_P4EST=ON \
>>
>> -DDEAL_II_WITH_TRILINOS=ON \
>>
>> -DTrilinos_INCLUDE_DIRS=/gpfs3/applications/trilinos/12.10.1/$MODULES_MPINAME/$MODULES_MPIVER/$MODULES_CVEN/$MODULES_CVER/include
>>  
>> \
>>
>> -DDEAL_II_WITH_CXX11=ON \
>>
>> ../dealii-8.4.1
>>
>>  
>>
>> However, I get this kind of error when trying to build one of the test 
>> files.  Specifically, Step-32.
>>
>>  
>>
>> Currently Loaded Modulefiles:
>>
>>   1) gnu/4.7.2  4) deal-ii/8.4.1  7) parmetis/4.0.2
>>
>>   2) openmpi/2.1.0  5) p4est/1.1  8) swig/3.0.12
>>
>>   3) trilinos/12.10.1   6) superlu/5.1.2  9) hdf5/1.8.18
>>
>> [xxx step-32]$ cmake .
>>
>> -- Autopilot invoked
>>
>> ###
>>
>> #
>>
>> #  Project  step-32  set up with  deal.II-8.4.1  found at
>>
>> #  /gpfs3/applications/deal_II/8.4.1/openmpi/2.1.0/gnu/4.7.2
>>
>> #
>>
>> #  CMAKE_BUILD_TYPE:  Debug
>>
>> #
>>
>> #  You can now run…
>>
>> -- Configuring done
>>
>> -- Generating done
>>
>> -- Build files have been written to: /home/xxx/step-32
>>
>>  
>>
>> [xxx step-32]$ make
>>
>> Scanning dependencies of target step-32
>>
>> Linking CXX executable step-32
>>
>> CMakeFiles/step-32.dir/step-32.cc.o: In function 
>> `Step32::BoussinesqFlowProblem<
>>
>> 2>::project_temperature_field()':
>>
>> /home/xxx/step-32/step-32.cc:1768: 

[deal.II] AssertDimension (partition_blocks[partition], task_info.n_blocks) when calling MatrixFree::reinit() for finest level in GMG

[Denis Davydov]

Dear all,

I am hitting  an AssertDimension (partition_blocks[partition], 
task_info.n_blocks); when initializing MatrixFree object for the finest 
level of the mesh.
This happens at 2nd h-adaptive step with 3 a-priori global refinements. 
The part of the code during setup of each level is rather standard GMG with 
Laplace operator:

typename MatrixFree::AdditionalData 
mg_additional_data;

mg_additional_data.tasks_parallel_scheme = MatrixFree::AdditionalData::partition_color;

mg_additional_data.level_mg_handler = level;

mg_additional_data.mapping_update_flags = update_gradients | 
update_JxW_values;

ConstraintMatrix level_constraints;

IndexSet relevant_dofs;

DoFTools::extract_locally_relevant_level_dofs(dof_handler, level,

  relevant_dofs);

level_constraints.reinit(relevant_dofs);

level_constraints.add_lines(mg_constrained_dofs.get_boundary_indices
(level));

level_constraints.close();


std::shared_ptr> mg_level_data(new 
MatrixFree());


mg_level_data->reinit (mapping, dof_handler, level_constraints, 
quadrature_formula,

   mg_additional_data);

backtrace from this reinit is: 

 matrix_free.h:1668
   1665 quad_hp.emplace_back (quad[q]);
   1666   internal_reinit(StaticMappingQ1::mapping, 
dof_handler,constraint,
   1667   locally_owned_set, quad_hp, additional_data);
-> 1668 }

 matrix_free.templates.h:166
   163// constraint_pool_data. It also reorders the way cells are 
gone through
   164// (to separate cells with overlap to other processors from 
others
   165// without).
-> 166initialize_indices (constraint, locally_owned_set);

 matrix_free.templates.h:689
   686  (size_info, task_info, renumbering, irregular_cells,
   687   dof_handlers.active_dof_handler == DoFHandlers::hp);
   688else
-> 689  dof_info[0].make_thread_graph_partition_color
   690  (size_info, task_info, renumbering, irregular_cells,
   691   dof_handlers.active_dof_handler == DoFHandlers::hp);

dof_info.templates.h:1011
   1008 break;
   1009   }
   1010 }
-> 1011   AssertDimension (partition_blocks[partition], 
task_info.n_blocks);

Any ideas?

Regards,
Denis.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: About constructor FE_Enriched

[Denis Davydov]

Hi,

On Friday, April 28, 2017 at 10:22:07 PM UTC+2, Edith Sotelo wrote:
>
> Hi.
> I want to use several enrichment and incorporate them through a loop in 
> the constructor. I came up with this piece of code (see below) . But  I had 
> to create a vector of FE_Enriched though I do not need
>
 

> a vector, I did this to overcome  the issue of the explicit initialization 
> of FE_Enriched object. I am wondering if you have any suggestion to 
> improve this parta and get rid of the FE_Enriched vector.
>
 

>
> template 
>
> Helmholtz_GFEM2d_2::Helmholtz_GFEM2d_2 ():
>
>
>   q(8),
>
>   k(20),
>
>   dof_handler (triangulation)
>
>
>
> {
>
>std::vector< std::function< const Function * (const typename 
> Triangulation ::cell_iterator &) >  > functions;
>
>
> for (unsigned int n = 0; n < q; ++n)
>
>   { std::cout<
> Enrichment enrich (k,n,q);
>
>
this object will die as soon as you exit the loop. You need to make sure 
it's alive during the whole usage of FE code. 
For example, use a std::vector>... 
and adjust your code below.
 

>
> functions.push_back([=] (const typename 
> Triangulation::cell_iterator &) -> const Function * {return & 
> enrich;});
>
>
>
>}
>
>FE_Q feq (1);
>
>fe_enriched_vector. push_back(FE_Enriched (, {}, {functions}) 
> );
>
>
either use std::shared_ptr or FECollection::push_back().
 

>
> }
>
>
Regards,
Denis.
 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Superlu_dist usage in dealii

[Denis Davydov]

> On 18 Apr 2017, at 21:39, Kartik Jujare  wrote:
> 
> Thank you Uwe and Dennis dor your additions
> 
> However Dennis, I have a supplementary question. How does one make you of the 
> arguments inside the program specifically inside solve function?

currently you can’t, it is **command-line only**. 
One would need to add a wrapper for the direct solver, similar to 
SolverDirectMUMPS:
https://www.dealii.org/developer/doxygen/deal.II/classPETScWrappers_1_1SparseDirectMUMPS.html
 


you can give it a try and contribute this feature to the library.

Regards,
Denis.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Superlu_dist usage in dealii

[Denis Davydov]

for completeness, you can also use superlu_dist from PETSc using 
command-line argument, along the lines:

-pc_type lu -pc_factor_mat_solver_package superlu_dist

On Monday, April 17, 2017 at 1:08:29 PM UTC+2, Kartik Jujare wrote:
>
> Hello,
>
> Can anyone please provide an implementation example on how to proceed 
> using superlu_dist in a dealii solve function? 
>
> Thanks and regards,
> Kartik 
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: fe_enriched and step-47

[Denis Davydov]

> On 12 Apr 2017, at 14:54, Sean McGovern  wrote:
> 
> 
>> Would the general point be that if one can go to higher resolutions with 
>> distributed parallelism that the enhanced accuracy of the enrichment 
>> functions can be compensated for?
> 
> Sorry, i did not get what you mean.
> 
> Regards,
> Denis.
> 
> 
> Hi Denis, 
> Thanks for your prompt answers.
> I was shooting for a very generic question about the tradeoffs of a 
> high-resolution parallel approach, vs the more subtle XFEM on a coarser grid. 
> So, for example,  consider an immiscible two-phase flow where the boundary 
> between the two fluids is defined by a level set function (like in the code 
> gallery's two_phase_flow). One way to represent the interface accurately 
> would be to use very high-resolution so that the location of the material 
> discontinuity, and its effect on, say, pressure, is highly localized.  
> Another might be to essentially smooth out the pressure over the intersected 
> cells (with material discontinuity) through the use of enrichment functions 
> (if I understand XFEM well).
> 
> I wonder if this is a reasonable way to view the tradeoffs around interface 
> representation (handling internal discontinuities)?
> Since from an implementation point of view, I currently see a choice point 
> between pursuing XFEM(with hp::DoFHandler) or high-res (p::d::tria). 

Now I see your point, thanks for explanation. But I don’t know an answer ;-)

Cheers,
Denis.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Crack propagation

[Denis Davydov]

That’s not the right way to do it, you should have something along the lines:

unsigned int number_of_values () const
{  
return 1 + ;
}

virtual void pack_values(std::vector ) const
{
values[0] = psi;
values[1] = B[0][0];
values[2] = B[0][1];
...
}

and same for unpack but other way around (setting internal data from an input 
vector).


The point is that we can not guess what type of data users are storing. But we 
don’t really need to.
We only need to know how many independent scalar fields would the data 
correspond do.
That’s what is returned by number_of_values(). The same resasons pack_values() 
are NOT called pack_scalars() etc

Regards,
Denis.

> On 10 Apr 2017, at 11:30, 'Seyed Ali Mohseni' via deal.II User Group 
> <dealii@googlegroups.com> wrote:
> 
> Dear Denis Davydov,
> 
> I am trying to implement the pack_values() and unpack_values() functions for 
> a FullMatrix, but the function itself in quadrature_point_data.h is 
> defined using a vector of double values only. Nevertheless, my initial 
> approach would be the following:
> 
> struct MyQData: public TransferableQuadraturePointData
> {
>   double psi;
>   FullMatrix B;
> 
>   unsigned int number_of_values () const
>   {
>   return 2;
>   }
> 
>   virtual void pack_values (std::vector ) const
>   {
>   Assert(scalars.size()==1, ExcInternalError());
>   scalars[0] = psi;
>   }
> 
>   virtual void pack_values (std::vector<FullMatrix> ) 
> const
>   {
>   Assert(scalars.size()==1, ExcInternalError());
>   matrices[0] = B;
>   }
> 
>   virtual void unpack_values (const std::vector )
>   {
>   Assert(scalars.size() ==1, ExcInternalError());
>   psi = scalars[0];
>   }
> 
>   virtual void unpack_values (const std::vector<FullMatrix> 
> )
>   {
>   Assert(matrices.size() ==1, ExcInternalError());
>   B = matrices[0];
>   }
> };
> 
> Is the above correct? Will it work during refinement? I checked it without 
> refinement and it seems to give me correct values at each Gauss point after 
> data storage.
> 
> 
> Note that this may not be what you want in the context of crack propagation 
> because what we do to transfer is assume that the quadrature data is 
> continuous across the element (thus the name 
> ContinuousQuadratureDataTransfer).
> 
> Yes, but what choice do I have? Is there another computationally efficient 
> approach? 
> This means probably that the PointHistory function data storage based on 
> step-18 has the same drawback for discontinuous problems, am I right?  
> 
> I would be gladly willing to implement the 
> DiscontinuousQuadratureDataTransfer function, if it is somehow possible to 
> accomplish in deal.II. I am pretty sure it will be beneficial for others also 
> in many ways. ;) 
> 
> Kind regards,
> S. A. Mohseni
> 
> -- 
> The deal.II project is located at http://www.dealii.org/ 
> <http://www.dealii.org/>
> For mailing list/forum options, see 
> https://groups.google.com/d/forum/dealii?hl=en 
> <https://groups.google.com/d/forum/dealii?hl=en>
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/dealii/rgv4YGx5VJE/unsubscribe 
> <https://groups.google.com/d/topic/dealii/rgv4YGx5VJE/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to 
> dealii+unsubscr...@googlegroups.com 
> <mailto:dealii+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: fe_enriched and step-47

[Denis Davydov]

Hi

On Sunday, April 9, 2017 at 10:20:13 AM UTC+2, Simon Sticko wrote:
>
> Hi.
> Regarding this:
>
> > On Thursday, April 6, 2017 at 1:51:41 PM UTC+2, Denis Davydov wrote:
> > 
> > The issue with integrating and quadrature would still remain.
>
>
> I've been implementing an algorithm to generate bulk and surface 
> quadrature given a level set function as boundary description. It's mainly 
> an implementation of this algorithm: dx.doi.org/10.1137/140966290. 
> I'm hoping to finish this within the coming weeks and contribute with this 
> to dealii.
>

that would be very nice! I look forward to your pull request (PR).

ps. You can also create a work-in-progress (WIP) pull-request so that 
others may provide feedback straight-away.
Or one may split it into two or more PRs. For example I don't think there 
is any functionality in deal.II to work with level sets.
If you use/implement this as a part of your work, you may also first create 
a PR with this part only.

Regards,
Denis.

-- 
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.
For more options, visit https://groups.google.com/d/optout.