[deal.II] Creating a FESystem with bulk and surface FE spaces

2021-03-28 Thread manuel.q...@gmail.com
Hello, 

I need to solve a system of many PDEs (currently 18). The actual number 
changes since the PDEs are defined by a truncated infinite sum and some 
recursive equations. Anyway, the first two equations are defined on a 2D or 
3D domain (call it Omega) and the rest is only defined on the boundary of 
Omega. My first idea was to create a FESystem object and attach to it 2 FE 
spaces defined on Omega and 16 FE spaces defined on the boundary. That is, 
I tried these options 

   - FESystem<1, 2> fe(FE_Q<2, 2>(degree), 2, FE_Q<1, 2>(degree), 16)
   - FESystem<2, 2> fe(FE_Q<2, 2>(degree), 2, FE_Q<1, 2>(degree), 16)

However, that produced compilation errors. What I understand is that the 
FESystem must be created by either FE spaces defined in Omega or FE spaces 
defined in the manifold, but not a combination. As a way around I tried (a 
very ugly hack) where I defined all FE spaces in Omega and then add 
constraints to all DoFs associated with the internal nodes for the 
variables that are defined on the manifold. This sounds like a tremendous 
waste of resources since most of the equations in my system live in the 
manifold, so I end up constraining most of the DoFs. And even worse, it 
produced a matrix that seems to be sometimes singular and sometimes 
non-singular. That is, I can solve the system and get accurate results (I 
have the exact solution) for some grids but in other grids the matrix is 
singular so I get NaNs. I suspect this problem is a consequence of 
constraining most of my DoFs. FYI, the solver that I am using is the MUMPS 
implementation in PETSc. 

I wonder if there is a proper or standard way to construct systems that are 
defined by some equations in a domain and some in a manifold of the domain. 
I definitely don't think constraining most of my DoFs is the way to go. 

Thanks and all the best, 

Manuel Quezada 



-- 
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/92fb368a-b689-48a8-982d-b97bd6946e4bn%40googlegroups.com.


[deal.II] PETSc Vector set deprecated

2021-03-28 Thread Zachary 42!
Hello,

I am building PETSc vectors with the set operation and I see it’s deprecated.  
The documentation suggests to use “import( )” but I don’t see how to use it.

How can I use import( ) as a replacement for set( ) as the documentation 
suggests?  Please provide an example. 

Thank you,

Zachary

-- 
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/8CBCFFAA-05DE-42F3-A65A-0A5842736424%40gmail.com.


[deal.II] Boost serialization linking error

2021-03-28 Thread Paras Kumar
Dear All,

I am trying to install deal.ii-9.0.1 using spack v.15 on our HPC cluster 
(Centos 7 OS). The installation works fine. Most of my code compiles 
without any issues, but when compiling targets using Boost serilization 
functionalities, I get the following linking errors:

iwtm020h@emmy1:/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build$ make 
VERBOSE=1
/home/woody/iwtm/iwtm020h/spack-install/dealii901-spackv15-gcc/spack/opt/spack/linux-centos7-ivybridge/gcc-7.3.0/cmake-3.17.3-yp7x4tfykdwkolbguxb2nbd46ktt5e6h/bin/cmake
 
-S/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac 
-B/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build --check-build-system 
CMakeFiles/Makefile.cmake 0
/home/woody/iwtm/iwtm020h/spack-install/dealii901-spackv15-gcc/spack/opt/spack/linux-centos7-ivybridge/gcc-7.3.0/cmake-3.17.3-yp7x4tfykdwkolbguxb2nbd46ktt5e6h/bin/cmake
 
-E cmake_progress_start 
/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build/CMakeFiles 
/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build/CMakeFiles/progress.marks
make  -f CMakeFiles/Makefile2 all
make[1]: Entering directory 
`/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build'
make  -f CMakeFiles/mncfrac.dir/build.make CMakeFiles/mncfrac.dir/depend
make[2]: Entering directory 
`/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build'
cd /home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build && 
/home/woody/iwtm/iwtm020h/spack-install/dealii901-spackv15-gcc/spack/opt/spack/linux-centos7-ivybridge/gcc-7.3.0/cmake-3.17.3-yp7x4tfykdwkolbguxb2nbd46ktt5e6h/bin/cmake
 
-E cmake_depends "Unix Makefiles" 
/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac 
/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac 
/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build 
/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build 
/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build/CMakeFiles/mncfrac.dir/DependInfo.cmake
 
--color=
make[2]: Leaving directory 
`/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build'
make  -f CMakeFiles/mncfrac.dir/build.make CMakeFiles/mncfrac.dir/build
make[2]: Entering directory 
`/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build'
make[2]: Nothing to be done for `CMakeFiles/mncfrac.dir/build'.
make[2]: Leaving directory 
`/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build'
[ 54%] Built target mncfrac
make  -f CMakeFiles/mncfracture.dir/build.make 
CMakeFiles/mncfracture.dir/depend
make[2]: Entering directory 
`/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build'
cd /home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build && 
/home/woody/iwtm/iwtm020h/spack-install/dealii901-spackv15-gcc/spack/opt/spack/linux-centos7-ivybridge/gcc-7.3.0/cmake-3.17.3-yp7x4tfykdwkolbguxb2nbd46ktt5e6h/bin/cmake
 
-E cmake_depends "Unix Makefiles" 
/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac 
/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac 
/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build 
/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build 
/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build/CMakeFiles/mncfracture.dir/DependInfo.cmake
 
--color=
make[2]: Leaving directory 
`/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build'
make  -f CMakeFiles/mncfracture.dir/build.make 
CMakeFiles/mncfracture.dir/build
make[2]: Entering directory 
`/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build'
make[2]: Nothing to be done for `CMakeFiles/mncfracture.dir/build'.
make[2]: Leaving directory 
`/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build'
[ 63%] Built target mncfracture
make  -f variants/CMakeFiles/cookmembranedistributed.dir/build.make 
variants/CMakeFiles/cookmembranedistributed.dir/depend
make[2]: Entering directory 
`/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build'
cd /home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build && 
/home/woody/iwtm/iwtm020h/spack-install/dealii901-spackv15-gcc/spack/opt/spack/linux-centos7-ivybridge/gcc-7.3.0/cmake-3.17.3-yp7x4tfykdwkolbguxb2nbd46ktt5e6h/bin/cmake
 
-E cmake_depends "Unix Makefiles" 
/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac 
/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/variants 
/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build 
/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build/variants 
/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build/variants/CMakeFiles/cookmembranedistributed.dir/DependInfo.cmake
 
--color=
make[2]: Leaving directory 
`/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build'
make  -f variants/CMakeFiles/cookmembranedistributed.dir/build.make 
variants/CMakeFiles/cookmembranedistributed.dir/build
make[2]: Entering directory 
`/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build'
[ 68%] Linking CXX executable cookmembranedistributed
cd /home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build/variants && 
/home/woody/iwtm/iwtm020h/spack-install/dealii901-spackv15-gcc/spack/opt/spack/linux-centos7-ivybridge/gcc-7.3.0/cmake-3.17.3-yp7x4tfykdwkolbguxb2nbd46ktt5e6h/bin/cmake
 
-E cmake_link_script CMakeFiles/cookmembranedistributed.dir/link.txt 
--verbose=1
/home/woody/iwtm/iwtm020h/spack-install/deal

Re: [deal.II] Boost serialization linking error

2021-03-28 Thread Wolfgang Bangerth



Paras:
deal.II 9.0.1 is nearly 3 years old and it's unlikely that anyone will spend 
the time to figure out in detail what the issue is. I would suggest upgrading 
to a more recent version and seeing whether the problem persists.


That said, this...


cd /home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build/variants


and this...

/home/woody/iwtm/iwtm020h/spack-install/dealii901-spackv15-gcc/spack/opt/spack/linux-centos7-ivybridge/gcc-7.3.0/cmake-3.17.3-yp7x4tfykdwkolbguxb2nbd46ktt5e6h/bin/cmake 


and this...


-E cmake_link_script CMakeFiles/cookmembranedistributed.dir/link.txt --verbose=1
/home/woody/iwtm/iwtm020h/spack-install/dealii901-spackv15-gcc/spack/opt/spack/linux-centos7-ivybridge/gcc-7.3.0/openmpi-3.1.6-6d7xi6tah53fltt3wtens3wt6zoaysr7/bin/mpic++ 
-rdynamic  -rdynamic -fuse-ld=gold -ggdb 
CMakeFiles/cookmembranedistributed.dir/cook_membrane_distributed/CookMembraneDistributed.cc.o 
CMakeFiles/cookmembranedistributed.dir/cook_membrane_distributed/CookMembraneDistributedMain.cc.o 
-o cookmembranedistributed 
-Wl,-rpath,/home/woody/iwtm/iwtm020h/trial-code/MNC-Frac/_build 
/home/woody/iwtm/iwtm020h/spack-install/dealii901-spackv15-gcc/spack/opt/spack/linux-centos7-ivybridge/gcc-7.3.0/dealii-9.0.1-dealii-901-dev-mzkyyfiqp2zxw4ip4cuyx7ok6ym57bp7/lib/libdeal_II.g.so.9.0.1 
../libmncfrac.so 
/home/woody/iwtm/iwtm020h/spack-install/dealii901-spackv15-gcc/spack/opt/spack/linux-centos7-ivybridge/gcc-7.3.0/dealii-9.0.1-dealii-901-dev-mzkyyfiqp2zxw4ip4cuyx7ok6ym57bp7/lib/libdeal_II.g.so.9.0.1 
-ltbb_debug -lboost_iostreams-mt -lboost_serialization-mt -lboost_system-mt 
-lboost_thread-mt -lboost_regex-mt -lboost_chrono-mt -lboost_date_time-mt 
-lboost_atomic-mt -lmuelu-adapters -lmuelu-interface -lmuelu -lifpack2 
-lanasazitpetra -lModeLaplace -lanasaziepetra -lanasazi -lmapvarlib -lsuplib 
-lsuplib_c -lsuplib_cpp -lsupes -laprepro_lib -lio_info_lib -lIonit -lIotr 
-lIohb -lIogs -lIogn -lIovs -lIoexo_fac -lIopx -lIofx -lIoex -lIoss -lnemesis 
-lexoIIv2for32 -lexodus_for -lexodus -lamesos2 -lbelosxpetra -lbelostpetra 
-lbelosepetra -lbelos -lml -lifpack -lzoltan2 -lamesos -lgaleri-xpetra 
-lgaleri-epetra -laztecoo -lxpetra-sup -lxpetra -ltrilinosss -ltpetraext 
-ltpetrainout -ltpetra -lkokkostsqr -ltpetraclassiclinalg 
-ltpetraclassicnodeapi -ltpetraclassic -lepetraext -ltriutils -lzoltan 
-lepetra -lsacado -lkokkoskernels -lteuchoskokkoscomm -lteuchoskokkoscompat 
-lteuchosremainder -lteuchosnumerics -lteuchoscomm -lteuchosparameterlist 
-lteuchosparser -lteuchoscore -lkokkosalgorithms -lkokkoscontainers 
-lkokkoscore -lgtest -lmatio -ldmumps -lmumps_common -lpord -lumfpack 
-lcholmod -lccolamd -lcolamd -lcamd -lsuitesparseconfig -lamd -lrt -ladolc 
-lparpack -larpack -lassimp -lgsl -lgslcblas -lmuparser -lnetcdf_c++ -lnetcdf 
-lTKBO -lTKBool -lTKBRep -lTKernel -lTKFeat -lTKFillet -lTKG2d -lTKG3d 
-lTKGeomAlgo -lTKGeomBase -lTKHLR -lTKIGES -lTKMath -lTKMesh -lTKOffset 
-lTKPrim -lTKShHealing -lTKSTEP -lTKSTEPAttr -lTKSTEPBase -lTKSTEP209 -lTKSTL 
-lTKTopAlgo -lTKXSBase -lp4est -lsc -lscalapack -lslepc -lpetsc -lHYPRE 
-lsuperlu_dist -lopenblas -lhdf5hl_fortran -lhdf5_hl -lhdf5_fortran -lhdf5 
-lparmetis -lmetis -lz -lmpi_usempif08 -lmpi_usempi_ignore_tkr -lmpi_mpifh 
-lmpi -lgfortran -lm -lpthread -lquadmath -ldl -lsundials_idas 
-lsundials_arkode -lsundials_kinsol -lsundials_nvecserial -lsundials_nvecparallel


...are the commands that trigger the error. You can execute them by hand on 
the command line, and test your hypothesis about the order of libraries by 
switching what needs to be switched.


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 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/86dedcca-b197-1bef-acce-bd26840b2879%40colostate.edu.


Re: [deal.II] PETSc Vector set deprecated

2021-03-28 Thread Wolfgang Bangerth




I am building PETSc vectors with the set operation and I see it’s deprecated.  
The documentation suggests to use “import( )” but I don’t see how to use it.

How can I use import( ) as a replacement for set( ) as the documentation 
suggests?  Please provide an example.


I don't know the answer, but maybe David Wells does given that the deprecation 
was added in

  https://github.com/dealii/dealii/pull/10398

For sure, you could simply write into the vector elements one by one. That 
doesn't require 'import()' at all.


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 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/547b180f-8666-a20d-1922-d95b7425f237%40colostate.edu.