Re: [deal.II] Linking error when compiling examples: undefined reference to 'boost::archive::archive_exception::archive_exception(boost::archive::archive_exception const&)'
Laryssa: The problem was that I had extracted the boost headers locally and had not built/installed it. David Wells (thanks David!) reported the issue here: https://github.com/dealii/dealii/issues/14925. Since then, I have been trying to link one of my projects against deal.ii (copy with bundled boost) and I get this error: c++: error: unrecognized command line option ‘-fopenmp-simd’ This is an unrelated problem you want to address. How did that flag end up on your command line? If the compiler doesn't understand the flag, then deal.II should not have added it. Do you have it set via an environment variable? [ 40%] Building CXX object CMakeFiles/fchep.dir/src/IonicModels/vanderPolDuffing.cpp.o In file included from /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/support/tag_of.hpp:14:0, from /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/support/category_of.hpp:11, from /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/adapted/struct/detail/extension.hpp:14, from /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/adapted/struct/adapt_struct.hpp:22, from /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/adapted/std_pair.hpp:14, from /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/include/std_pair.hpp:11, from /nas/longleaf/home/laryssa/fch-ep/src/Datafile.h:11, from /nas/longleaf/home/laryssa/fch-ep/src/Datafile.cpp:8: /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/support/detail/is_mpl_sequence.hpp:12:69:fatal error: boost/fusion/support/detail/is_native_fusion_sequence.hpp: No such file or directory #include ^ compilation terminated. Shouldn't fusion be available once I use the bundled version of boost? I am not sure what to get out of this error message. This is a problem. The bundled version of boost is not complete -- boost is just too large for us to include everything. It only includes those parts we actually need in boost. But that also means that you are left high and dry if you are using other parts of boost in your own code. Are you? If you are, then the only option is to use the version of boost that comes with your system. Of course, in that case you have to not only install the boost headers in your system, but also the corresponding libraries. 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/5b88563a-03ef-0f34-448d-0affa3f32cf8%40colostate.edu.
[deal.II] Re: Building with TRILINOS and SEACUS
Hi all, I was able to build dealii with Trilinous by first building trillions-release-13-4-1 instead of the latest Trilinos version. On Saturday, March 18, 2023 at 5:01:22 PM UTC-4 Kaushik Das wrote: > Hello all, > I built Trilinos from source on a RedHat 7.9 enterprise server and then > tried to building deallii with Trilinos support but I keep getting errors > like this one below: > > -- Enabled Kokkos devices: SERIAL > -- Found EPETRA_CONFIG_H > -- TRILINOS_LIBRARY_ROL::all_libs not found! The call was: > -- FIND_LIBRARY(TRILINOS_LIBRARY_ROL::all_libs NAMES ROL::all_libs > HINTS NO_DEFAULT_PATH NO_CMAKE_ENVIRONMENT_PATH NO_CMAKE_PATH > NO_SYSTEM_ENVIRONMENT_PATH NO_CMAKE_SYSTEM_PATH NO_CMAKE_FIND_ROOT_PATH) > -- TRILINOS_LIBRARY_Tempus::all_libs not found! The call was: > -- FIND_LIBRARY(TRILINOS_LIBRARY_Tempus::all_libs NAMES > Tempus::all_libs HINTS NO_DEFAULT_PATH NO_CMAKE_ENVIRONMENT_PATH > NO_CMAKE_PATH NO_SYSTEM_ENVIRONMENT_PATH NO_CMAKE_SYSTEM_PATH > NO_CMAKE_FIND_ROOT_PATH) > > ... (similar errors) > > _CMAKE_FIND_ROOT_PATH) > -- TRILINOS_LIBRARY_KokkosCore::all_libs not found! The call was: > -- FIND_LIBRARY(TRILINOS_LIBRARY_KokkosCore::all_libs NAMES > KokkosCore::all_libs HINTS NO_DEFAULT_PATH NO_CMAKE_ENVIRONMENT_PATH > NO_CMAKE_PATH NO_SYSTEM_ENVIRONMENT_PATH NO_CMAKE_SYSTEM_PATH > NO_CMAKE_FIND_ROOT_PATH) > -- TRILINOS_LIBRARY_Gtest::all_libs not found! The call was: > -- FIND_LIBRARY(TRILINOS_LIBRARY_Gtest::all_libs NAMES Gtest::all_libs > HINTS NO_DEFAULT_PATH NO_CMAKE_ENVIRONMENT_PATH NO_CMAKE_PATH > NO_SYSTEM_ENVIRONMENT_PATH NO_CMAKE_SYSTEM_PATH NO_CMAKE_FIND_ROOT_PATH) > -- TRILINOS_VERSION: 14.1 > -- TRILINOS_LIBRARIES: *** Required variable > "TRILINOS_LIBRARY_ROL::all_libs" set to NOTFOUND *** > -- TRILINOS_LIBRARIES: *** Required variable > "TRILINOS_LIBRARY_Tempus::all_libs" set to NOTFOUND *** > -- TRILINOS_LIBRARIES: *** Required variable > "TRILINOS_LIBRARY_MueLu::all_libs" set to NOTFOUND *** > > > But I do have those libraries built and installed in the default location > > $ ls -l /usr/local/lib/libkokkosalgorithms.so* > lrwxrwxrwx. 1 root root25 Mar 18 12:24 > /usr/local/lib/libkokkosalgorithms.so -> libkokkosalgorithms.so.14 > lrwxrwxrwx. 1 root root27 Mar 18 12:24 > /usr/local/lib/libkokkosalgorithms.so.14 -> libkokkosalgorithms.so.14.1 > -rwxr-xr-x. 1 root root 15288 Mar 18 12:02 > /usr/local/lib/libkokkosalgorithms.so.14.1 > > $ ls -l /usr/local/lib/librol* > lrwxrwxrwx. 1 root root12 Mar 18 12:24 /usr/local/lib/librol.so -> > librol.so.14 > lrwxrwxrwx. 1 root root14 Mar 18 12:24 /usr/local/lib/librol.so.14 -> > librol.so.14.1 > -rwxr-xr-x. 1 root root 19560 Mar 18 12:24 /usr/local/lib/librol.so.14.1 > > $ ls -l /usr/local/lib/*empus* > lrwxrwxrwx. 1 root root 15 Mar 18 12:24 /usr/local/lib/libtempus.so > -> libtempus.so.14 > lrwxrwxrwx. 1 root root 17 Mar 18 12:24 > /usr/local/lib/libtempus.so.14 -> libtempus.so.14.1 > -rwxr-xr-x. 1 root root 7116480 Mar 18 12:23 > /usr/local/lib/libtempus.so.14.1 > > > > -- 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/7e21555f-152c-4ed3-828f-5e1dc95595c7n%40googlegroups.com.
Re: [deal.II] Marking cells at interface between subdomains
Jose, I am working on a problem with several subdomains. At the interface between them a boundary integral is to be evaluated. I am identifying the interface by comparing the material_id of neighboring cells (or their active_fe_index as I am using a different FESystem per subdomain). In order to speed up the search during assembly, a Vector is previously filled with 1.0 at the cells where the material_id/active_fe_index differ. This approach works in serial but in parallel the material_id() call of a neighbor cell outside the locally owned subdomain always returns 0 (An assertion is missing here). As such, not only the interface between subdomains is marked but also the interface between locally owned subdomains, as shown in the attached picture If I understand you right, then you want to have the correct material_id set also on ghost cells? If so, take a look at this function: https://dealii.org/developer/doxygen/deal.II/namespaceGridTools.html#a9565dbf2f8e45fee28e40806870e2c98 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/ae02e863-ffb4-5b4b-6a13-61fbb6b31157%40colostate.edu.
Re: [deal.II] Higher order Tetrahedron support for gmsh
On 3/21/23 11:41, Kumar Saurabh wrote: Is there any documentation that I can take a look at to understand the order of the vertices in second order tetrahedron. I mean how the mapping is done to the reference element for second order tetrahedron. You mean what the order of nodes is that gmsh uses? The place for that would be the gmsh documentation. 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/f746c012-bd9a-ef0f-0487-a481bf81eadd%40colostate.edu.
Re: [deal.II] Linking error when compiling examples: undefined reference to 'boost::archive::archive_exception::archive_exception(boost::archive::archive_exception const&)'
Laryssa, The bundled boost package only includes the files that are used within deal.II. If you want to use additional boost features, you should build boost yourself (and tell deal.II where to find it). Best, Daniel On Tue, Mar 21, 2023 at 1:19 PM Laryssa Abdala wrote: > > Great, that solved the problem. Thank you. > The problem was that I had extracted the boost headers locally and had not > built/installed it. David Wells (thanks David!) reported the issue here: > https://github.com/dealii/dealii/issues/14925. Since then, I have been > trying to link one of my projects against deal.ii (copy with bundled boost) > and I get this error: > > c++: error: unrecognized command line option ‘-fopenmp-simd’ > make[2]: *** [Tests/CodimHeatEquation/CMakeFiles/demo.dir/demo.cc.o] Error > 1 > make[1]: *** [Tests/CodimHeatEquation/CMakeFiles/demo.dir/all] Error 2 > make[1]: *** Waiting for unfinished jobs > [ 6%] Building CXX object CMakeFiles/fchep.dir/src/Datafile.cpp.o > [ 13%] Building CXX object CMakeFiles/fchep.dir/src/EPSolver.cpp.o > [ 13%] Building CXX object > CMakeFiles/fchep.dir/src/IonicModels/FentonKarma4v.cpp.o > [ 16%] Building CXX object > CMakeFiles/fchep.dir/src/IonicModels/IonicModel.cpp.o > [ 20%] Building CXX object > CMakeFiles/fchep.dir/src/IonicModels/MinimalModel.cpp.o > [ 23%] Building CXX object > CMakeFiles/fchep.dir/src/IonicModels/NashPanfilov.cpp.o > [ 26%] Building CXX object > CMakeFiles/fchep.dir/src/IonicModels/Passive.cpp.o > [ 30%] Building CXX object > CMakeFiles/fchep.dir/src/IonicModels/Ryzhii.cpp.o > [ 40%] Building CXX object CMakeFiles/fchep.dir/src/Timer.cpp.o > [ 40%] Building CXX object CMakeFiles/fchep.dir/src/TimeData.cpp.o > [ 40%] Building CXX object > CMakeFiles/fchep.dir/src/IonicModels/vanderPolDuffing.cpp.o > In file included from > /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/support/tag_of.hpp:14:0, > from > /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/support/category_of.hpp:11, > from > /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/adapted/struct/detail/extension.hpp:14, > from > /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/adapted/struct/adapt_struct.hpp:22, > from > /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/adapted/std_pair.hpp:14, > from > /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/include/std_pair.hpp:11, > from /nas/longleaf/home/laryssa/fch-ep/src/Datafile.h:11, > from /nas/longleaf/home/laryssa/fch-ep/src/Datafile.cpp:8: > > /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/support/detail/is_mpl_sequence.hpp:12:69: > fatal error: boost/fusion/support/detail/is_native_fusion_sequence.hpp: No > such file or directory > #include > ^ > compilation terminated. > > Shouldn't fusion be available once I use the bundled version of boost? I > am not sure what to get out of this error message. > > Thanks again, > Laryssa > > > On Monday, March 20, 2023 at 1:51:24 PM UTC-4 Wolfgang Bangerth wrote: > >> On 3/19/23 15:47, Laryssa Abdala wrote: >> > >> > I've tried using different versions of boost, but have not been >> > successful with any. I've attached the detailed.log if anyone could >> help >> > me. >> >> Laryssa, I don't know specifically what causes this error, but you can >> almost certainly avoid it if you use the bundled version of deal.II. I >> believe that you can achieve that by passing >> -DEAL_II_FORCE_BUNDLED_BOOST=ON >> to cmake when you configure. In the output, cmake currently reports >> (based on the file you had attached) this: >> # DEAL_II_WITH_BOOST set up with external dependencies >> With the flag above, it should then say that it is using the 'bundled' >> version of BOOST instead. >> >> 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 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/261cbc2d-7920-4000-8cc3-154d148b32a4n%40googlegroups.com >
[deal.II] Re: Marking cells at interface between subdomains
Hi Peter, Thanks a lot for the suggestion. With it I think I managed to achieved the desired effect. First, I populated a LinearAlgebra::distributed::Vector with the material ids and called the update_ghost_values() method afterwards. In a second active_cell_iterator I used said vector and the global_active_cell_index() of each cell pair for the boolean comparison of the material id. I could not do a visual verification due to the assertion data_vector.size() == triangulation->n_active_cells() inside the add_data_vector() method with DataVectorType::type_cell_data as third argument, i.e., data_out.add_data_vector( cell_is_at_interface, "cell_is_at_interface", dealii::DataOut_DoFData, dim, dim>::DataVectorType::type_cell_data); The assertion does not hold for a distributed vector as n_global_active_cells > n_active_cells. Maybe this is not the correct method for LinearAlgebra::distributed::Vector? Nevertheless, I instead counted the amount of times the boolean comparison was true and it coincides with what it is expected from the amount of global refinements of the unit square (with 3 global refinements there are a total of 16 cells at the interface) and I checked the x-coordinate of the cells' center to verify that it is indeed at the interface. It seems that when working in parallel out of the methods CellAccessor::material_id(), CellAccessor::active_fe_index() and CellAccessor::global_active_cell_index(), only the latter returns the correct value when called from a neighbor cell outside the locally owned subdomain. I could observe this when printing the global_active_cell_index, active_fe_index and the material_id pairs each the the boolean comparison was true. Here are the results in serial Global active cell index pair ( 5, 16) with active_fe_index pair ( 1, 2) and material_id pair ( 1, 2) Global active cell index pair ( 7, 18) with active_fe_index pair ( 1, 2) and material_id pair ( 1, 2) Global active cell index pair (13, 24) with active_fe_index pair ( 1, 2) and material_id pair ( 1, 2) Global active cell index pair (15, 26) with active_fe_index pair ( 1, 2) and material_id pair ( 1, 2) Global active cell index pair (16, 5) with active_fe_index pair ( 2, 1) and material_id pair ( 2, 1) Global active cell index pair (18, 7) with active_fe_index pair ( 2, 1) and material_id pair ( 2, 1) Global active cell index pair (24, 13) with active_fe_index pair ( 2, 1) and material_id pair ( 2, 1) Global active cell index pair (26, 15) with active_fe_index pair ( 2, 1) and material_id pair ( 2, 1) Global active cell index pair (37, 48) with active_fe_index pair ( 1, 2) and material_id pair ( 1, 2) Global active cell index pair (39, 50) with active_fe_index pair ( 1, 2) and material_id pair ( 1, 2) Global active cell index pair (45, 56) with active_fe_index pair ( 1, 2) and material_id pair ( 1, 2) Global active cell index pair (47, 58) with active_fe_index pair ( 1, 2) and material_id pair ( 1, 2) Global active cell index pair (48, 37) with active_fe_index pair ( 2, 1) and material_id pair ( 2, 1) Global active cell index pair (50, 39) with active_fe_index pair ( 2, 1) and material_id pair ( 2, 1) Global active cell index pair (56, 45) with active_fe_index pair ( 2, 1) and material_id pair ( 2, 1) Global active cell index pair (58, 47) with active_fe_index pair ( 2, 1) and material_id pair ( 2, 1) and in parallel (-np 3) Global active cell index pair (24, 13) with active_fe_index pair ( 2, 0) and material_id pair ( 2, 0) Global active cell index pair (26, 15) with active_fe_index pair ( 2, 0) and material_id pair ( 2, 0) Global active cell index pair (37, 48) with active_fe_index pair ( 1, 0) and material_id pair ( 1, 0) Global active cell index pair (45, 56) with active_fe_index pair ( 1, 2) and material_id pair ( 1, 2) Global active cell index pair (47, 58) with active_fe_index pair ( 1, 2) and material_id pair ( 1, 2) Global active cell index pair (48, 37) with active_fe_index pair ( 2, 0) and material_id pair ( 2, 0) Global active cell index pair (50, 39) with active_fe_index pair ( 2, 0) and material_id pair ( 2, 0) Global active cell index pair (56, 45) with active_fe_index pair ( 2, 1) and material_id pair ( 2, 1) Global active cell index pair (58, 47) with active_fe_index pair ( 2, 1) and material_id pair ( 2, 1) Global active cell index pair ( 5, 16) with active_fe_index pair ( 1, 2) and material_id pair ( 1, 2) Global active cell index pair ( 7, 18) with active_fe_index pair ( 1, 2) and material_id pair ( 1, 2) Global active cell index pair (13, 24) with active_fe_index pair ( 1, 0) and material_id pair ( 1, 0) Global active cell index pair (15, 26) with active_fe_index pair ( 1, 0) and material_id pair ( 1, 0) Global active cell index pair (16, 5) with
Re: [deal.II] Higher order Tetrahedron support for gmsh
Hi Dr. Bangerth, Thanks for your message. Is there any documentation that I can take a look at to understand the order of the vertices in second order tetrahedron. I mean how the mapping is done to the reference element for second order tetrahedron. I just want to use volumetric integration for assembly with Dirichlet boundary computation. Thanks, Kumar Saurabh On Monday, March 20, 2023 at 1:28:32 PM UTC-7 Wolfgang Bangerth wrote: > On 3/20/23 12:26, Kumar Saurabh wrote: > > > > I wanted to check if deal.ii has a support for second order tetrahedron > > meshes. I tried to load the file from GMSH and it gave the error for > > unsupported element type. > > > > Is it that deal.ii do not support second order tetrahedron from GMSH or > > do not support second order tetrahedron at all? > > Kumar, > for triangles and tetrahedra, mappings are generally implemented by > relying in MappingFE. As a consequence, if there is a Lagrange element > of polynomial degree p, there is a corresponding mapping of polynomial > degree p. Right now, FE_SimplexP is available up to polynomial degree > p=2, so quadratic elements should be ok. > > Whether or not GridIn can read such meshes is a different question. If > you get an error, then the answer is apparently no. But that shouldn't > be too hard to fix, and we would be quite happy to accept a patch (and > point you in the right direction regarding what needs to be > implemented). My suspicion is that it would not take more then 100 lines > of code to read these meshes. > > The bigger problem with quadratic meshes (which also exists for the case > of quadratic quadrilaterals/hexahedra) is that we do not currently have > a good way to translate the information encoded by mid-edge nodes into a > mapping. If we can read such meshes for quadrilaterals, I suspect that > we just ignore the mid-edge nodes and rely on the user's ability to > provide a mapping that restores this kind of information. > > 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 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/7b08cce9-2693-4373-920d-771f2411b0a9n%40googlegroups.com.
Re: [deal.II] Linking error when compiling examples: undefined reference to 'boost::archive::archive_exception::archive_exception(boost::archive::archive_exception const&)'
Great, that solved the problem. Thank you. The problem was that I had extracted the boost headers locally and had not built/installed it. David Wells (thanks David!) reported the issue here: https://github.com/dealii/dealii/issues/14925. Since then, I have been trying to link one of my projects against deal.ii (copy with bundled boost) and I get this error: c++: error: unrecognized command line option ‘-fopenmp-simd’ make[2]: *** [Tests/CodimHeatEquation/CMakeFiles/demo.dir/demo.cc.o] Error 1 make[1]: *** [Tests/CodimHeatEquation/CMakeFiles/demo.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs [ 6%] Building CXX object CMakeFiles/fchep.dir/src/Datafile.cpp.o [ 13%] Building CXX object CMakeFiles/fchep.dir/src/EPSolver.cpp.o [ 13%] Building CXX object CMakeFiles/fchep.dir/src/IonicModels/FentonKarma4v.cpp.o [ 16%] Building CXX object CMakeFiles/fchep.dir/src/IonicModels/IonicModel.cpp.o [ 20%] Building CXX object CMakeFiles/fchep.dir/src/IonicModels/MinimalModel.cpp.o [ 23%] Building CXX object CMakeFiles/fchep.dir/src/IonicModels/NashPanfilov.cpp.o [ 26%] Building CXX object CMakeFiles/fchep.dir/src/IonicModels/Passive.cpp.o [ 30%] Building CXX object CMakeFiles/fchep.dir/src/IonicModels/Ryzhii.cpp.o [ 40%] Building CXX object CMakeFiles/fchep.dir/src/Timer.cpp.o [ 40%] Building CXX object CMakeFiles/fchep.dir/src/TimeData.cpp.o [ 40%] Building CXX object CMakeFiles/fchep.dir/src/IonicModels/vanderPolDuffing.cpp.o In file included from /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/support/tag_of.hpp:14:0, from /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/support/category_of.hpp:11, from /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/adapted/struct/detail/extension.hpp:14, from /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/adapted/struct/adapt_struct.hpp:22, from /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/adapted/std_pair.hpp:14, from /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/include/std_pair.hpp:11, from /nas/longleaf/home/laryssa/fch-ep/src/Datafile.h:11, from /nas/longleaf/home/laryssa/fch-ep/src/Datafile.cpp:8: /nas/longleaf/home/laryssa/dogwood/sfw/dealii/install-dbg/include/deal.II/bundled/boost/fusion/support/detail/is_mpl_sequence.hpp:12:69: fatal error: boost/fusion/support/detail/is_native_fusion_sequence.hpp: No such file or directory #include ^ compilation terminated. Shouldn't fusion be available once I use the bundled version of boost? I am not sure what to get out of this error message. Thanks again, Laryssa On Monday, March 20, 2023 at 1:51:24 PM UTC-4 Wolfgang Bangerth wrote: > On 3/19/23 15:47, Laryssa Abdala wrote: > > > > I've tried using different versions of boost, but have not been > > successful with any. I've attached the detailed.log if anyone could help > > me. > > Laryssa, I don't know specifically what causes this error, but you can > almost certainly avoid it if you use the bundled version of deal.II. I > believe that you can achieve that by passing > -DEAL_II_FORCE_BUNDLED_BOOST=ON > to cmake when you configure. In the output, cmake currently reports > (based on the file you had attached) this: > # DEAL_II_WITH_BOOST set up with external dependencies > With the flag above, it should then say that it is using the 'bundled' > version of BOOST instead. > > 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 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/261cbc2d-7920-4000-8cc3-154d148b32a4n%40googlegroups.com.
[deal.II] deal.II Newsletter #246
Hello everyone! This is deal.II newsletter #246. It automatically reports recently merged features and discussions about the deal.II finite element library. ## Below you find a list of recently proposed or merged features: #14929: TrilinosWrappers::PreconditionBase deprecate AdditionalData and minor cleanup (proposed by sebproell) https://github.com/dealii/dealii/pull/14929 #14928: Add an empty() function to ArrayView (proposed by bergbauer) https://github.com/dealii/dealii/pull/14928 #14927: Introduce quadrature_points_indices() function for FEPointEvaluation (proposed by bergbauer) https://github.com/dealii/dealii/pull/14927 #14926: FEPointEvaluation: Remove unit_points member, access them through MappingInfo instead (proposed by bergbauer) https://github.com/dealii/dealii/pull/14926 #14924: Fix namespacing in the ExodusII error macro. (proposed by drwells; merged) https://github.com/dealii/dealii/pull/14924 #14923: Remove obsolete CMake test for `MPI_SEEK_SET` (proposed by sloede; merged) https://github.com/dealii/dealii/pull/14923 #14921: Use header for C++20 feature checks (proposed by masterleinad; merged) https://github.com/dealii/dealii/pull/14921 #14920: Move check about FECollection size to DoFHandler. (proposed by marcfehling) https://github.com/dealii/dealii/pull/14920 #14919: Simplify Trilinos solver's AdditionalData (proposed by sebproell; merged) https://github.com/dealii/dealii/pull/14919 #14918: [C++17] Use std::array instead of a C-style array. (proposed by bangerth) https://github.com/dealii/dealii/pull/14918 #14917: Update documentation of Quadrature. (proposed by bangerth; merged) https://github.com/dealii/dealii/pull/14917 #14916: Update description of UpdateFlags::update_quadrature_points. (proposed by bangerth; merged) https://github.com/dealii/dealii/pull/14916 #14915: Add a compatibility type for C++20's std::type_identity. (proposed by bangerth) https://github.com/dealii/dealii/pull/14915 #14914: Remove dummy changelog entry (proposed by peterrum; merged) https://github.com/dealii/dealii/pull/14914 #14913: SolverFGMRES: refactor orthogonalization (proposed by peterrum) https://github.com/dealii/dealii/pull/14913 #14912: Fix formatting (proposed by peterrum; merged) https://github.com/dealii/dealii/pull/14912 #14911: Fix a grammar mistake. (proposed by bangerth; merged) https://github.com/dealii/dealii/pull/14911 #14910: Make it more obvious that evaluation points are not quadrature points. (proposed by bangerth; merged) https://github.com/dealii/dealii/pull/14910 #14909: Update documentation for DataPostprocessor. (proposed by bangerth; merged) https://github.com/dealii/dealii/pull/14909 #14908: Do not ask for things we don't actually need. (proposed by bangerth; merged) https://github.com/dealii/dealii/pull/14908 #14907: Add test to ensure consistent constraints in parallel (proposed by kronbichler) https://github.com/dealii/dealii/pull/14907 #14906: Add a link to the documentation. (proposed by bangerth; merged) https://github.com/dealii/dealii/pull/14906 #14905: Add consistent strategy to merge constraints in parallel (proposed by bergbauer) https://github.com/dealii/dealii/pull/14905 #14904: Add instantiation to for off-diagonal contributions to DiagonalMatrix (proposed by bergbauer; merged) https://github.com/dealii/dealii/pull/14904 #14903: Select correct code path for neighbor elements in FEEvaluation (proposed by bergbauer; merged) https://github.com/dealii/dealii/pull/14903 #14902: Jenkins: enable and update arm MacOS build (proposed by tjhei; merged) https://github.com/dealii/dealii/pull/14902 #14901: Remove DoFInfo::dimension (proposed by peterrum; merged) https://github.com/dealii/dealii/pull/14901 #14900: Different documentation updates in `matrix_free` (proposed by peterrum; merged) https://github.com/dealii/dealii/pull/14900 #14899: Do not allow assigning to rvalue references of Tensor. (proposed by bangerth; merged) https://github.com/dealii/dealii/pull/14899 #14898: Limit friend declarations for DofHandler and Triangulation to the same template arguments (proposed by masterleinad; merged) https://github.com/dealii/dealii/pull/14898 #14897: Fix concepts support for TpetraWrappers::Vector (proposed by masterleinad; merged) https://github.com/dealii/dealii/pull/14897 #14896: Doxygen: fix missing related link in ArrayView (proposed by sebproell; merged) https://github.com/dealii/dealii/pull/14896 #14895: Fix concepts support for clang++ (proposed by masterleinad; merged) https://github.com/dealii/dealii/pull/14895 #14894: FEEvaluation: use EvaluationFlags in documentation (proposed by peterrum; merged) https://github.com/dealii/dealii/pull/14894 #14892: Use VectorizedArrayTrait (proposed by peterrum; merged) https://github.com/dealii/dealii/pull/14892 #14890: CellWiseInverse: extend comments (proposed by peterrum; merged) https://github.com/dealii/dealii/pull/14890 #14889: Clean up
[deal.II] Re: Marking cells at interface between subdomains
Hi Jose, not sure. You could use Triangulation::global_active_cell_index_partitioner() to initialize a distributed vector, access it via CellAccessor::global_active_cell_index(), and update the ghost values. Peter On Tuesday, March 21, 2023 at 10:47:14 AM UTC+1 jose.a...@gmail.com wrote: > Hello dealii community, > > I am working on a problem with several subdomains. At the interface > between them a boundary integral is to be evaluated. I am identifying the > interface by comparing the material_id of neighboring cells (or their > active_fe_index as I am using a different FESystem per subdomain). In order > to speed up the search during assembly, a Vector is previously > filled with 1.0 at the cells where the material_id/active_fe_index differ. > This approach works in serial but in parallel the material_id() call of a > neighbor cell outside the locally owned subdomain always returns 0 (An > assertion is missing here). As such, not only the interface between > subdomains is marked but also the interface between locally owned > subdomains, as shown in the attached picture > > My question is, if there is an equivalent to locally owned and relevant > dofs for the case of cells, i.e., locally owned and relevant cells such > that the material_id/active_fe_index of the neighboring cell outside the > locally owned subdomain can be read? Alternatively, is there a built-in > method/member which can be used for my purpose or someone has already done > it through another approach? > > Attached is also the MWE used to obtain the attached screenshot. > > Cheers, > Jose > -- 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/ea5b77e3-50f4-48bb-8269-238e4712a62en%40googlegroups.com.
[deal.II] Marking cells at interface between subdomains
Hello dealii community,
I am working on a problem with several subdomains. At the interface between
them a boundary integral is to be evaluated. I am identifying the interface
by comparing the material_id of neighboring cells (or their active_fe_index
as I am using a different FESystem per subdomain). In order to speed up the
search during assembly, a Vector is previously filled with 1.0 at
the cells where the material_id/active_fe_index differ. This approach works
in serial but in parallel the material_id() call of a neighbor cell outside
the locally owned subdomain always returns 0 (An assertion is missing
here). As such, not only the interface between subdomains is marked but
also the interface between locally owned subdomains, as shown in the
attached picture
My question is, if there is an equivalent to locally owned and relevant
dofs for the case of cells, i.e., locally owned and relevant cells such
that the material_id/active_fe_index of the neighboring cell outside the
locally owned subdomain can be read? Alternatively, is there a built-in
method/member which can be used for my purpose or someone has already done
it through another approach?
Attached is also the MWE used to obtain the attached screenshot.
Cheers,
Jose
--
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/2fed0564-bd7c-451e-af9f-f9e0d16bacc0n%40googlegroups.com.
#include
#include
#include
#include
#include
#include
#include
namespace Tests
{
template
class MarkInterface
{
public:
MarkInterface();
void run();
private:
dealii::ConditionalOStreampcout;
dealii::parallel::distributed::Triangulation
triangulation;
dealii::DoFHandler dof_handler;
dealii::Vector locally_owned_subdomain;
dealii::Vector material_id;
dealii::Vector active_fe_index;
dealii::Vector cell_is_at_interface;
const double edge_length;
void make_grid();
void mark_grid();
void output();
};
template
MarkInterface::MarkInterface()
:
pcout(
std::cout,
dealii::Utilities::MPI::this_mpi_process(MPI_COMM_WORLD) == 0),
triangulation(MPI_COMM_WORLD),
dof_handler(triangulation),
edge_length(1.0)
{}
template
void MarkInterface::run()
{
make_grid();
mark_grid();
output();
}
template
void MarkInterface::make_grid()
{
// Grid
dealii::GridGenerator::hyper_cube(
triangulation,
0,
edge_length,
false);
triangulation.refine_global(5);
// Subdomains
for (const auto _cell : triangulation.active_cell_iterators())
if (active_cell->is_locally_owned())
{
if (std::fabs(active_cell->center()[0]) < edge_length/2.0)
active_cell->set_material_id(1);
else
active_cell->set_material_id(2);
}
// Match active FE index to material index
for (const auto _cell : dof_handler.active_cell_iterators())
if (active_cell->is_locally_owned())
active_cell->set_active_fe_index(active_cell->material_id());
}
template
void MarkInterface::mark_grid()
{
cell_is_at_interface.reinit(triangulation.n_active_cells());
locally_owned_subdomain.reinit(triangulation.n_active_cells());
material_id.reinit(triangulation.n_active_cells());
active_fe_index.reinit(triangulation.n_active_cells());
cell_is_at_interface= -1.0;
locally_owned_subdomain = -1.0;
material_id = -1.0;
active_fe_index = -1.0;
for (const auto _cell :
dof_handler.active_cell_iterators())
{
if (active_cell->is_locally_owned())
{
locally_owned_subdomain(active_cell->active_cell_index()) =
triangulation.locally_owned_subdomain();
material_id(active_cell->active_cell_index()) =
active_cell->material_id();
active_fe_index(active_cell->active_cell_index()) =
active_cell->active_fe_index();
for (const auto _index : active_cell->face_indices())
{
if (!active_cell->face(face_index)->at_boundary() &&
active_cell->active_fe_index() !=
active_cell->neighbor(face_index)->active_fe_index())
{
cell_is_at_interface(active_cell->active_cell_index()) = 1.0;
break;
}
}
}
}
}
template
void MarkInterface::output()
{
dealii::DataOut data_out;
data_out.attach_dof_handler(dof_handler);
data_out.add_data_vector(locally_owned_subdomain,
"locally_owned_subdomain");
