Re: [deal.II] using VectorTools::project_boundary_values_curl_conforming_l2 with FEsystem fe(FE_Nedelec<3>(0), 2)

Abbas, There was a seemingly related issue fixed in deal.II 9.2, see https://github.com/dealii/dealii/issues/8974 and https://github.com/dealii/dealii/pull/9000. Are you using the latest release and testing in Debug mode? Do you have a minimal example reproducing the issue to share? Best, Daniel

Re: [deal.II] The periodic boundary condition for an RVE analysis

Farzin, std::vector::cell_iterator>> periodicity_vector; should be std::vector::cell_iterator>> periodicity_vector; In general, I would recommend looking into step-45 ( https://www.dealii.org/current/doxygen/deal.II/step_45.html) for an example using periodic boundary conditions. Best, Daniel

Re: [deal.II] Accessing cell data from its ID

Corbin, if you only ever need the DoF mapping periodic DoFTools::make_periodicity_constrainst ( https://www.dealii.org/current/doxygen/deal.II/namespaceDoFTools.html#a03324e6e060c6a55191b2c60ad871eab) sound like the right tool for you to use. Just create a separate AffineConstraints object to be

Re: [deal.II] Unable to collect periodic faces

Vachan, Maybe the boundary information is not transferred to the deal.II Triangulation when calling GridIn::read_msh. I would recommend checking the triangulation after reading it in and modify the boundary indicators manually if necessary. Best, Daniel Am Di., 20. Apr. 2021 um 03:37 Uhr

Re: [deal.II] Setting manifold for a truncated cone mesh

Vachan, the source code to GridGenerator::truncated_cone() related to manifold_is, boundary_ids and manifolds looks like // Set boundary ids at -half_length to 1 and at half_length to 2. Set the // manifold id on hull faces (i.e., faces not on either end) to 0. for (const auto :

Re: [deal.II] Setting manifold for a truncated cone mesh

Vachan, that should work. There is nothing special about using GridGenerator to create geometries that can not be achieved by reading in a custom mesh and setting the boundary ids, manifold ids and manifold. Best, Daniel Am Di., 6. Apr. 2021 um 07:42 Uhr schrieb vachanpo...@gmail.com <

Re: [deal.II] Doubt in collect_periodic_faces() documentation

Vachan, "dimension" actually doesn't appear in the function signature at all so it seems reasonable to just replace it with "direction" in its documentation. Best, Daniel Am Sa., 27. März 2021 um 00:00 Uhr schrieb vachanpo...@gmail.com < vachanpotluri1...@gmail.com>: > Dr. Arndt, > > Thank you

Re: [deal.II] Doubt in collect_periodic_faces() documentation

Vachan, `dimension` is understood in the sense of dimension in which to apply periodicity: x-direction (0) means identifying faces with id 0 and 1, y-direction (1) means identifying faces with id 2 and 3, z-direction (2) means identifying faces with id 4 and 5, Best, Daniel Am Fr., 26. März

Re: [deal.II] The periodic boundary condition for an RVE analysis

Farzin, it appears what you want to do is almost what DoFTools::make_periodicity_constraints( https://www.dealii.org/current/doxygen/deal.II/namespaceDoFTools.html#a929249499b1e5624728d212e90a8e037) gives you. You "only" have to apply the additional displacement +H(\chi_+-\chi_-). You can check

Re: [deal.II] Issue with GridIn::read_msh

Krishan, Do you have minimal input file to share that shows your problem? Best, Daniel Am Di., 2. März 2021 um 10:12 Uhr schrieb krishan...@gmail.com < krishanu.se...@gmail.com>: > Hi Luca, > > Thanks for the response. I recreated the mesh to make sure that there is > no two physical tag for

Re: [deal.II] Visualizing higher-order cells in 3D (step-67)

David, For me the most likely suspect without looking into the code at all is a missing update_ghost_values. Best, Daniel Am Di., 9. Feb. 2021 um 17:04 Uhr schrieb Alexander : > David > i believe that in order to proceed, one will have to simplify this further. > > What is the minimum number

Re: [deal.II] Multiple material IDs

Corbin, if you have a maximal range for either of the two material ranges you could just compute a single material ID by material_id = material_id1 * max_material_id2 + material_id2 material_id2 = material_id % max_material_id2 material_id1 = material_id / max_material_id2 Best, Daniel Am

Re: [deal.II] Re: Multilevel DoFRenumbering for a distributed Triangulation

Hey Julius, I don't think there are any but it should not be that difficult to implement one yourself. The implementation f these functions is not that complicated. Of course, we are happy for any patches in that direction. ;-) Best, Daniel Am Fr., 5. Feb. 2021 um 14:20 Uhr schrieb

Re: [deal.II] Re: How to construct p::d::Triangulation from a locally refined Triangulation?

Ce, There is also save_refine_flags and load_refine_flags but you need to make sure

Re: [deal.II] New Build Error? Usable debug flags failed

Zachary, are you using CMake 3.19 by any chance? We have had some problems with that recently but a recent develop version should work. Best, Daniel Am Fr., 18. Dez. 2020 um 11:00 Uhr schrieb Zachary 42! < zacharyloui...@gmail.com>: > Hello, > > I recently tried to build deal.II locally

Re: [deal.II] Using external libraries with deal.II

Animesh, Assuming that the packages export CMake configurations you can just do a standard find_package(Spectra REQUIRED) target_link_libraries(my_project Spectra::Spectra) in the CMakeLists.txt for your project. Best, Daniel Am Do., 17. Dez. 2020 um 14:19 Uhr schrieb Animesh Rastogi IIT

Re: [deal.II] Re: Periodic boundary conditions : Error using GridTools::collect_periodic_facepairs

Aaditya, the documentation says "[...] More precisely, faces with coordinates only differing in the direction component are identified." Hence, it is crucial to choose this correctly. For a cube with standard coloring faces 2 and 3 share the x-coordinates so direction must be 1. Best, Daniel

Re: [deal.II] Refinement on a parallel distributed triangulation with periodic BC

Maurice, make_periodicity_constraints loops (recursively) over all faces referenced in a PeriodicFacePair and applies constraints. You could copy the implementation in https://www.dealii.org/developer/doxygen/deal.II/dof__tools__constraints_8cc_source.html#l02269 and modify accordingly or set up

Re: [deal.II] Adding new obj target

Zachary, You also need to make sure that CMake actually sees that your new source directory. In particular, you should add a line saying ADD_SUBDIRECTORY(Test) to source/CMakeLists.txt. Best, Daniel Am Mo., 9. Nov. 2020 um 11:35 Uhr schrieb Zachary 42! < zacharyloui...@gmail.com>: > Hi

Re: [deal.II] Re: CTest Build Error

Zachary, Did you actually build deal.II, i.e did you run make? Best, Daniel Am Do., 29. Okt. 2020 um 10:39 Uhr schrieb Zachary Streeter < zacharyloui...@gmail.com>: > I'v tried on various computers so I think I'm missing a step. > > 1) $ cmake .. > 2) $ make setup_tests > and everything works,

Re: [deal.II] Periodic BC in parallel distributed homogenization problem

Maurice, Is there any reason that you don't use DoFTools::make_periodicity_constraints() as shown in https://www.dealii.org/current/doxygen/deal.II/step_45.html? Best, Daniel Am Mi., 21. Okt. 2020 um 11:16 Uhr schrieb 'maurice rohracker' via deal.II User Group : > Dear all, > > > For a

Re: [deal.II] Re: APPLY BOUNDARY CONDTION ON INTERNAL FACE

Xiang, deal.II doesn't have functionality to create separate cells sharing a face but only to join them. Hence, whatever input you provide to Triangulation::create_triangulation() must have these faces already. GridIn should work for that if the faces are disjoint in the input file. Best, Daniel

Re: [deal.II] Re: APPLY BOUNDARY CONDTION ON INTERNAL FACE

Xiang, Adding to Bruno's response: If the interface you want to apply Dirichlet boundary conditions to stays the same through the whole simulation, then treating the corresponding faces as disjoint while creating your mesh might be a better option. Setting constraints yourself requires you to

Re: [deal.II] Tools for parallel debugging

Konrad, have a look at https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#how-do-i-debug-mpi-programs. For me, the "mpiexec -np n gdb ./executable" approach normally works fairly well. Best, Daniel Am So., 11. Okt. 2020 um 09:56 Uhr schrieb Konrad Simon < ksimon1...@gmail.com>: >

Re: [deal.II] Making a pair of extracted data and cast into a set

Behrooz, Can you elaborate some more on what you are trying to achieve? The (pseudo-)code you posted looks OK apart from vertices being declared in the innermost loop. You probably want it to be outside the loop over the vertices of a face. The API for Point can be found at

Re: [deal.II] PETSC issue while trying to run step-18

https://dealii.org/developer/readme.html#configuration-options says to call cmake with -DPETSC_DIR=/path/to/petsc -DPETSC_ARCH=architecture. I normally just set the environment variable PETSC_DIR and configure deal.II with -DDEAL_II_WITH_PETSC=ON Best, Daniel Am Di., 22. Sept. 2020 um 12:29 Uhr

Re: [deal.II] Using DataOut when dim != spacedim

Malhar, the template arguments for DataOut are dim and DoFHandlerType where DoFHandlerType defaults to DoFHandler since you are using a DoFHandler<2, 3> object you need to specify the second template argument explicitly, i.e. DataOut<2, DoFHandler<2,3>> data_out; You could have a look at

Re: [deal.II] HOW TO OUTPUT SYSTEM MATRIX IN A FILE

Of course, there is also PETScWrappers::MatrixBase::print( https://www.dealii.org/current/doxygen/deal.II/classPETScWrappers_1_1MatrixBase.html#a7515e640202d1ad50bd9baa13c404cb1) that should work. Best, Daniel Am Mi., 29. Juli 2020 um 12:59 Uhr schrieb Wolfgang Bangerth <

Re: [deal.II] Point receivers

Yuesu, Have a look at FEFieldFunction ( https://www.dealii.org/current/doxygen/deal.II/classFunctions_1_1FEFieldFunction.html) for the case that the interpolation points don't coincide with support points for nodal elements. Otherwise, you can use DoFTools::map_dofs_to_support_points (

Re: [deal.II] Re: Memory loss in system solver

Alberto, Have you tried running valgrind (in parallel) on your code? Admittedly, I expect quite a bit of false-positives from the MPI library but it should still help. Best, Daniel Am Fr., 24. Juli 2020 um 12:07 Uhr schrieb Alberto Salvadori < alberto.salvad...@unibs.it>: > Dear community, > >

Re: [deal.II] Cannot find local compiled petsc library

Yuesun, Apparently, CMake was able to find the file petscvariables, but not the include directories or the library. Can you search for "libpetsc.so" yourself? Our CMake find module tries to find this library in {PETSC_DIR}/lib or {PETSC_DIR}/lib64. See if you can adjust PETSC_DIR accordingly.

Re: [deal.II] Accessing nodal values of a FEM solution

> > We need to update function v based on solution u in the following loop. > > for ( x in vector_of_nodal_points ) > v(x) = f(x, u(x)) > > where v(x) and u(x) are the nodal point value for functions v and u, > respectively, and f() is some function depending on function u as well as > the

Re: [deal.II] Location for Boundary Condition Application

McKenzie, I'm interested in applying a non-homogeneous Dirichlet boundary condition > to a specific edge. However, I'm unsure how to identify or specify a > particular edge or face to add the boundary condition to. Could you help > clear this up for me? What do you know about that particular

Re: [deal.II] Accessing nodal values of a FEM solution

> > However, I have two more related questions. BTW, I am a newbie in C++ > programming. So my questions may seem absurd. > >1. Now that we have a vector holding all nodal point coordinates, and >another vector holding all nodal point values of the solution. How do we >access every

Re: [deal.II] Complex-valued distributed matrices in dealii

Pascal, The wrapped Trilinos matrices are based on Epetra which only supports double AFAICT. That's why you can replace TrilinosScalar easily. On the other hand, you should be able to compile PETSc with complex scalar type and use that with MPI. Best, Daniel Am Do., 23. Juli 2020 um 12:42 Uhr

Re: [deal.II] ABOUT READING GMSH

Xiang, deal.II interprets physical tags as boundary ids when reading .msh files using GridIn::read_msh ( https://www.dealii.org/current/doxygen/deal.II/classGridIn.html#a83872db02e04f52ac52d578912f6da5e ). If your mesh consists of multiple parts in separate msh files you can create triangulation

Re: [deal.II] Setting up dealii through Docker

Bhavesh, It's hard to tell if there is something going wrong and if so what it is from just the information you provided. If you inspect your container can you find the deal.II library, i.e. the include files and the shared library? If so, how did you try to invoke CMake when trying to build

Re: [deal.II] Re: Deal.ii installation

Prasad, CMake ran successfully and the output looks fine. Some of the example steps require certain dependencies which you just didn't activate. Note, that you will not be able to use MPI with this configuration. Best, Daniel Am Mi., 3. Juni 2020 um 05:21 Uhr schrieb Prasad Adhav <

Re: [deal.II] Step 44: imported 2d mesh fails to converge to solution

James, I do find it interesting that the two meshes were not imported with the > same boundary IDs. I guess in the future I should assume that all boundary > IDs are zero and reset them for each calculation? Also, is there a quick > reference guide for what each boundary ID means? I have not

Re: [deal.II] Initial guidance/starting point for solving a non-linear diffusion equation with double neumann BCs

Krishna, Have a look at step-7 for Neumann boundary conditions, step-15 for nonlinear problems and step-26 for time-dependent problems to get started. Let us know if you have more specific questions. Best, Daniel Am Do., 12. März 2020 um 17:38 Uhr schrieb Krishnakumar Gopalakrishnan <

Re: [deal.II] Problem with "constraints.distribute_local_to_global(local_rhs, local_dof_indices, system_rhs)"

Magdalini, The problem only appears with inhomogeneous boundary conditions, but periodic boundary conditions don't set any inhomogeneity. Best, Daniel Am Do., 5. März 2020 um 16:13 Uhr schrieb Magdalini Ntetsika < ntets...@berkeley.edu>: > Hi Wolfgang, > > thank you for the prompt reply. I

Re: [deal.II] Scaling behavior of Matrix-Free test program

Maxi, it would likely be interesting to run the STREAM benchmark on these two systems to see how much memory bandwidth you can hope to get. I would not be too surprised if that still is the limiting factor for your test. Best, Daniel Am Mo., 2. März 2020 um 12:17 Uhr schrieb 'Maxi Miller' via

Re: [deal.II] Step-57

Hussan, Do you observe this problem with the unmodified step-57 or did you change anything? What does the full backtrace look like (running gdb)? Best, Daniel Am Mo., 2. März 2020 um 09:42 Uhr schrieb hussan zeb : > how can resolve this error in step-57, > Scanning dependencies of target

Re: [deal.II] Mesh refinement with periodic boundary conditions

3, 1, >> periodicityVector); >> >> triangulation.add_periodicity(periodicityVector); >> >> // refine one less then maximum refinement level globally >> triangulation.refine_global(maxGridLevel-1); >> >> Perhaps I'm doing it wrong? >> >> On

Re: [deal.II] Mesh refinement with periodic boundary conditions

Andrew, Did you tell the triangulation that it should take periodic boundaries into account? My best bet (with the information given) would be that you didn't call parallel::distributed::Triangulation::add_periodicity()

Re: [deal.II] Support for axisymmetric geometries

Nick, There is no built-in functionality in deal.II to support axisymmetric problems. The best approach is probably reformulate your problem in cylinder coordinates similarly as discussed in

Re: [deal.II] Question on how MatrixTools::MatrixCreator sets the appropriate flags of FeValues?

Krishna, Adding to David's answer, mass matrix and laplace matrix are built for multiple components separately, i.e. there is no coupling between them. Best, Daniel Am Di., 18. Feb. 2020 um 10:17 Uhr schrieb David Wells : > Hi Krishna, > > I'm not sure that I understand your question - those

Re: [deal.II] How to Make Test Functions Satisfy Certain Constraints

Lex, Just look at the first six tutorials at https://www.dealii.org/current/doxygen/deal.II/Tutorial.html. Best, Daniel Am So., 16. Feb. 2020 um 23:45 Uhr schrieb Lex Lee : > Hello all, > > > To numerically solve the governing equations I am studying now, I notice > that the chosen three test

Re: [deal.II] Re: Problem installing Dealii-9.0.0

o all sprouts from it.. > > cheers many, > > Felipe > > > > > On Mon, 10 Feb 2020 at 23:41, Daniel Arndt wrote: > >> >> So this is a strange bug. The problem is from the flag >>> -Woverloaded-virtual With gcc 4.8 and 4.9 As you can see the flag &

Re: [deal.II] Re: Problem installing Dealii-9.0.0

> So this is a strange bug. The problem is from the flag > -Woverloaded-virtual With gcc 4.8 and 4.9 As you can see the flag > alone works https://wandbox.org/permlink/GLbCK7qVqfScXrZp but if I add > another flag it won't compile > https://wandbox.org/permlink/4Lw7aNqGlJkik6SL If you have access

Re: [deal.II] Installation on cray XC50 | linking to petsc, lapack and blas libraries with different names

Vachan, 3. With LAPACK, the story is different. I noticed that deal.II's version of > FindLAPACK.cmake uses the system installed cmake's FindLAPACK.cmake. And > then I came across this question on SO: > https://stackoverflow.com/questions/54681204/cray-cc-wrapper-cmake-find-package-blas > and

Re: [deal.II] deal.II installation on cray XC50 giving MPI_VERSION=0.0

Vachan, You can probably tell better than any of us if this works. Just try. It might quite well be that the compiler doesn't need any extra flags for MPI. Also, it looks like the MPI version could not be detected. This implies that the library doesn't use newer features but should still work. If

Re: [deal.II] Question on KINSOL::SUNDIALS

Rochan, there is Algorithms::Newton that can be used to set up a Newton method and there are multiple tutorial examples that deal with nonlinear problems. Have a look at step-15, step-25, step-44 and in particular step-42. Best, Daniel On Tue, Feb 4, 2020, 6:45 PM rru wrote: > Dear dealii

Re: [deal.II] Re: Instantiation problem for Utilities::MPI::sum (const ArrayView< const T > , const MPI_Comm _communicator, const ArrayView< T > )

Feimi, it's picking the wrong overload. Utilities::MPI::sum(local_vector, mpi_communicator, local_vector); works as well as Utilities::MPI::sum(my_view, mpi_communicator, my_view); Best, Daniel Am Di., 28. Jan. 2020 um 12:57 Uhr schrieb Feimi Yu : > Hi Bruno, > > Thanks for your reply! >

Re: [deal.II] Install Deal.ii-9.1.1 on windows using cmake and visual studio

Amir, Windows support is experimental and we only test for the latest versions. According to https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html CMake 3.16.3 should support "Visual Studio 16 2019" as generator. The error in the attached file arises from `perl` not being present

Re: [deal.II] IterativeInverse function appears to have disappeared between v8.5.0 and v9.0.0?

Krishna, [...] > Can someone please point me in the right direction regarding the > documentation of this class for the latest release of dealii? > Have a look at https://www.dealii.org/current/doxygen/deal.II/changes_between_8_5_0_and_9_0_0.html, item 70. Best, Daniel -- The deal.II project

Re: [deal.II] Re: Application of inverse mass matrix in matrix-free context using cell_loop instead of scale()

Maxi, As usual, it is much easier to help if you provide a complete minimal example and say how the result differs from what you expect. Does it only scale certain vector entries? Are the results correct when running with one MPI process? How does your approach differ from

Re: [deal.II] Using solution on from one FE problem as a boundary condition for another

Ernesto, Imposing strong boundary conditions should not be overly difficult in this case. Just as Wolgang said you should have a look at interpolate_boundary_values() and replace the Function object evaluations on each cell by the function values given through a FEValues object initialized for

Re: [deal.II] Is it bug?

Files/Makefile2:272: CMakeFiles/run.dir/rule] Error 2 > make: *** [Makefile:196: run] Error 2 > > Navneet > > On Fri, Dec 13, 2019 at 11:00 PM Daniel Arndt > wrote: > >> Navneet, >> >> What is the error you are observing? >> >> Best, >> Dani

Re: [deal.II] Re: FE_Q

doxygen/deal.II/classFE__Q.html> > fe; > Best, > Oli > > On Thursday, November 28, 2019 at 7:43:37 PM UTC-5, Daniel Arndt wrote: >> >> Oli, >> >> you need to specify a polynomial degree you want to use. If you have a >> look at step-2 ( >> https://ww

[deal.II] Re: FE_Q

Oli, you need to specify a polynomial degree you want to use. If you have a look at step-2 (https://www.dealii.org/current/doxygen/deal.II/step_2.html), you see that it has a line saying const FE_Q<2> finite_element(1); to

Re: [deal.II] Install dealii failed in Supercomputer center

=/BIGDATA1/app/ >> deal.II/9.1.1-icc-15.0.1 <http://deal.ii/9.1.1-icc-15.0.1> >> -DCMAKE_CXX_COMPILER=icpc >> -DCMAKE_C_COMPILER=icc -DCMAKE_Fortran_COMPILER=ifort >> -DDEAL_II_CXX_FLAGS=-std=c++14 -DDEAL_II_WITH_64BIT_INDICES=ON >> >> the make error like

Re: [deal.II] Problem with FESystem and VectorTools::project_boundary_values_curl_conforming_l2 in 3d

Winni, Would you mind creating a pull request for the first issue you are reporting? Best, Daniel Am Di., 29. Okt. 2019 um 13:06 Uhr schrieb winnifried < woll...@mathematik.tu-darmstadt.de>: > Dear all, > > I encountered the following issue while trying to solve a Maxwell > eigenvalue problem

Re: [deal.II] Bug:Chebyshev preconditioner of 0th degree

MIchaĺ, The documentation in the developer version or the current version ( https://www.dealii.org/developer/doxygen/deal.II/classPreconditionChebyshev.html) says: "[...] Note that if the degree variable is set to one, the Chebyshev iteration corresponds to a Jacobi preconditioner (or the

Re: [deal.II] Query regarding DoFTools::dof_indices_with_subdomain_association()

Vachan, [...] > However, the documentation of the former function states > > Note that this function is of questionable use for DoFHandler objects >> built on parallel::distributed::Triangulation since in that case ownership >> of individual degrees of freedom by MPI processes is controlled by

Re: [deal.II] Implementing variable thermal diffusivity in Step-26

Muhammad, Dear Colleagues, >I am working on thermal analysis where deal.ii > Step-26 is being considered. In my case the thermal diffusivity > (Coefficient being multiplied with Laplace Matrix) is temperature dependent > and hence varying in every cell (or node). That

Re: [deal.II] Merging meshes and empty triangulation

Erik, Can you share your code and your mesh with us? Best, Daniel Am Sa., 5. Okt. 2019 um 20:30 Uhr schrieb Erik Fujiyama < erikfujiy...@gmail.com>: > Hello, I think I'm having a similar problem to the OP. I searched a lot, > but that's the closest that I could find. I'm trying to work with

Re: [deal.II] Error during refinement of a parallel distibuted quarter hyperball

Stefan, I am getting Abort: Expected '(int) edge_trees - (int) ta->elem_count': 'p8est_find_edge_transform_internal (conn, itree, iedge, ei, conn->edge_to_tree + ettae, conn->edge_to_edge + ettae, edge_trees)' Abort: /home/darndt/Sources/p4est-2.2/src/p8est_connectivity.c: Abort

Re: [deal.II] Re: Installation error, unable to configure with p4est

Vachan, [...] > However, > make test > for p4est failed with the following message > There are not enough slots available in the system to satisfy the 10 slots > that were requested by the application: > ./p4est.debug > > Either request fewer slots for your application, or make more slots >

Re: [deal.II] Re: Move vertices in P::D::Triangulation

huyanzhou, in the documentation , it's said in the case of mesh with moved vertices is > refined a few step later, should do as follows: > 1. save the offset applied to every vertex, > 2. call communicate_locally_moved_vertices function > 3. apply the opposite offset > 4. call communicate_local

Re: [deal.II] some question about the move mesh function

huyanzhou, I try to use the communicate_locally_moved_vertices, it fixes the departure > of mesh belongs to different mesh . but there still remains some problem > [...] > you can see that the mesh is consistent on the boundry, but not smooth in > the inner mesh ,there are some shallow hole on

Re: [deal.II] installation fails with intel/19.0.5

Victor, But I’m still not finishing the cmake. > > So there is a ton of > ... > What do those mean? Are they fatal or is that only cmake discovering > what’s available and what not? > No, these are not fatal. We just check for the dependencies to enable. Again, what is the full output when

Re: [deal.II] installation fails with intel/19.0.5

Victor, does running CMake or can't you compile after configuring? I don't immediately see anything suspicious in CMakeError.log. What is the output when running when `cmake` or, if the former works, what is the output when trying to compile? Best, Daniel Am Fr., 27. Sept. 2019 um 16:31 Uhr

Re: [deal.II] Problem warning in eclipse: invalid argument for the distance function

Brian, The warnings you are seeing come from a static analyzer in Eclipse and not from the compiler. It seems like Eclipse does not have full access to the source code or doesn't understand it correctly. E.g., passing a non-const variable to a function that doesn't modify its parameter, is never

Re: [deal.II] step 64 run problem

Jinhyun, I cannot reproduce that problem using nvcc-9.0 and deal.II 9.1.1. What version are you using? Does the code work if you remove that assertion in the library? Best, Daniel Am Fr., 6. Sept. 2019 um 01:52 Uhr schrieb Jinhyun Choo < jinhyun.c...@gmail.com>: > Hello, > > I've just complied

Re: [deal.II] Getting RHS values at nodes with DBC

Giorgos, You can find a discussion for how constraints are handled in deal.II in https://www.dealii.org/developer/doxygen/deal.II/group__constraints.html. Thank you for your feedback. > I'll try to explain what I try to calculate with the help of a standard > FEM textbook: > > [...] > > In the

Re: [deal.II] Solving a TrilinosWrappers::BlockSparseMatrix using Trilinos iterative solver (step-57)

Bruno, I am currently trying to work on a "HPC-ready with Trilinos" version of > step-57 for steady-state solution of the Navier-Stokes equation since I am > curious about compairing it to our stabilized solver. I think that it > could give much better results for steady-state. > The approach

Re: [deal.II] Implement 'w.n = u.n' as a boundary condition, where 'u' is a vector valued FE function/solution from a phase/PDE and 'n' is the unit outward normal in a distributed setting

Bhanu, I have looked at 'VectorTools::compute_nonzero_normal_flux_constraints'. > But what I have here to compute the 'inhomogeneity' is not a closed form > function, but a discrete FE solution computed from another PDE(in my case > Stokes). The 'u' in 'w.n = u.n' is a 'LA::MPI::Vector' FE

[deal.II] Re: triangulation.add_periodicity takes an enormous amount of time

Andreas, I am trying to read from a mesh file and impose periodic boundary > condition. This works out very well for small geometries in three spatial > dimensions. However, if the read meshes tend to have more elements, the > amount of time needed to create the mesh rises drastically. The

Re: [deal.II] Implement 'w.n = u.n' as a boundary condition, where 'u' is a vector valued FE function/solution from a phase/PDE and 'n' is the unit outward normal in a distributed setting

Bhanu, Please suggest me in implementing 'w.n = u.n' as a boundary condition where > 'u' is Stokes solution with 'FESystem fe_stokes(FE_Q(degree+1), > dim, FE_Q(degree), 1)' and 'w' for mesh velocity with 'FESystem > fe_move(FE_Q(degree), dim)'. As I have taken 'degree=1', 'fe_move' has > unit

Re: [deal.II] How to set material id with MPI

KIen, Hi colleagues, > I have a question for parallel::distributed::Triangulation > When 2 cells share 1 edge, but they are living in 2 different MPI > processes, how can I choose only 1 cell containing the common edge from > them. > I think I have to set material id for the cell in the first

Re: [deal.II] getting components of Blockvector

Gabriel, [...] > u_x.reinit(n_dofs_in_one_direction); > *FEValues fe_values(fe, > quadrature_formula, update_values);* > *std::vector> velocity_values(n_q_points);* > *const FEValuesExtractors::Vector velocities(0);* > > *for (const auto :

Re: [deal.II] Distributing objects on cluster nodes according to distributed triangulation (MPI)

Konrad, I have a little conceptual question. Maybe it is dumb but I am new to MPI... > > Say I have a triangulation of type > *parallel::distributed::Triangulation* that gets distributed over N > nodes on a cluster. Each active cell should own (or point to) an object > that makes up a (modified

[deal.II] Re: Question about constraints

Yuesu, I am learning step-7 which has the same class AffineConstraints class, in > step6, we use the member function ::distribute_local_to_global to put the > local matrix and rhs into global matrix and rhs, but in step-7, we still > use system_matrix.add and then use the constraint.condense

Re: [deal.II] MGTransferBlockMatrixFree< dim, Number > ::clear rrmoves number of blocks

Michal, [...] > Moreover the default contructor (without parameters) does not work (error > in compilation - deleted function). Using it could be useful for DG. I > would suggest: > 1) adding constuctor with number of blocks > 2) adding function that sets number of blocks > So you want to a

Re: [deal.II] undefined symbol: mkl_blas_dsyrk

Yuesu, Hello Daniel, > Thank you very much! I make a new folder to save the compile file for > cmake, and I used the command > *cmake -DCMAKE_INSTALL_PREFIX=${HOME}**/deal.II > home/yjin6/Deal.II/dealii-9.0.1* (substituted with my directory), > but cmake gave error warning. I substitute it

Re: [deal.II] undefined symbol: mkl_blas_dsyrk

> Thank you for your timely reply! > I changed the installation direction according to the README document and > redirected it to the deal.ii-9.0.1 source code. > It seems that you still set the installation directory to a non-existent path. If you want to install in your home directory

Re: [deal.II] petsc & trilinos blocksparsematrix reinit with zero locally owned components

Richard, [...] > The very last part (reinit) is working only iff every processor owns parts > of fluid AND solid domain (which is so far not ensured). > This behaviour can be seen running exactly the same problem with mpirun -n > 2 or -n 3, which is attached. > > THE QUESTION IS NOW: > How may

Re: [deal.II] Error on runnig the examples

Javad, I installed Dealii-9.1.1 successfully. So, I wanted to run step-1 and > followed the command lines based on README instruction. But, I have faced > an error that you can see as follow: > > root@Lenovo-PC:~/math/dealii-9.1.1/examples/step-1# cmake > -DDEAL_II_DIR=/root/bin/dealii-9.1.1/ . >

Re: [deal.II] Access old solution(s) in MatrixFreeOperators::Base::apply_add()

Maxi, [...] I tried adding a class member and initializing it during > setup_system(), but when accessing it via read_dof_values(), I had a layout > mismatch, resulting in > The violated condition was: > vec.partitioners_are_compatible(*dof_info.vector_partitioner) > Additional information: >

Re: [deal.II] Re: Porting tutorials to PETSc from Trilinos

Franco, If you forget about the static_cast in the error message just above >> you can actually see what happens: >> The violated condition was: >> global_matrix.m() == global_vector.size() >> >> > > I am lost in this, I have made some stupid error here but I don't see how. > I am posting

Re: [deal.II] Different solution with different software

Felix, Jean-Paul's answer might already have solved your problem. Anyway: I'm not sure to understand how to manufacture a solution for my problem. I > have read step 7 a few times and I understand but for a coupled system like > mine, I don't see how to do it. > Should I choose a solution with u

Re: [deal.II] VMult-function in the MatrixFree-Framework

> > Is there then a way to use LinearOperator as Input for a preconditioner? > Else I still have to form the full system matrix (which I would like to > avoid). > Most precoditioners require access to individual matrx entries. If the class you derive from linear operator provides a suitable

Re: [deal.II] VMult-function in the MatrixFree-Framework

> > On the other hand, would it be sufficient to unroll the >>> residual-calculation, i.e. if the residual is F(u) = nabla^2 u + f, to >>> write (in the cell-loop): (nabla^2(u + eps*src) + f - nabla^2u - >>> f)/epsilon? Or would that lead to wrong results? >>> >> >> It is sufficient to only

Re: [deal.II] VMult-function in the MatrixFree-Framework

Maxi, No, that code is the vmult-call I am using in my LinearOperator (and is > used directly in my solve()-call). The calculate_residual()-function is > similar to the function in step-15, with the difference, that I do not > provide alpha, but the vector, and return the calculated residual

Re: [deal.II] Step-40 fails with "PETSc preconditioner should have anassociated matrix set to be used in solver"

Pandey, > > [...] > > An error occurred in line <88> of file > in > function > void dealii::PETScWrappers::SolverBase::solve(const > dealii::PETScWrappers::MatrixBase&, dealii::PETScWrappers::VectorBase&, > const

Re: [deal.II] VMult-function in the MatrixFree-Framework

> My aim is to implement the jacobian approximation, i.e. (if F(u) = 0 is > the function to solve) I wanted to implement > dst = (F(current_solution + epsilon * src) - F(current_solution))/epsilon. > In my LinearOperator, my code is > LinearOperator jacobian_operator; > jacobian_operator.vmult =

Re: [deal.II] VMult-function in the MatrixFree-Framework

> >- When using the LinearOperator, the function vmult() is used when >solving the system with a GMRES-solver (or similar). Does the same hold up >for the MatrixFree-framework? > > Yes. > >- If the above is correct: In each GMRES-iteration I have to calculate >the residual of

Re: [deal.II] Different solution with different software

Felix, > Is the rate of convergence as expected? >> > > I believe so. I did a linear regression of the convergence graphs in > logscale and got a value of : > -7.6 for the speed : I believe it corresponds to the -8 from second order > finete element in 2D > -3.2 for the pressure : I beliebe it

[deal.II] Re: Different solution with different software

Felix, the usual approach for verifying your code is the method of manufactured solution. Choose functions that are elements of your ansatz space for all solution variables (possibly chaningyour grid to a cartesian one) and compute the corresponding right-hand side. Check that the error

<    1   2   3   4   5   >