Re: [deal.II] GridTools::find_cells_adjacent_to_vertex: how to avoid multiple calling ?

On 5/4/21 12:15 PM, Simon Wiesheier wrote: I looked up the Implementation of the mentioned function. Basically the function loops over all active cells and compares those global vertices with the one passed as second argument, so far so good. But is there a similar function which accepts a

Re: [deal.II] AffineCostraints and MPI

Alberto, Basically, I would like to rephrase The step-11 tutorial program for parallel::shared matrices, as in step 18. If I am not wrong the "condense" methods do not apply to MPI::SparseMatrix and I guess I should use the methods of the family distribute_local_to_global, Correct. For

Re: [deal.II] Re: Problem related to make_hanging_nodes_constraints in the hp cases

Dear Bruno Thank you for your reply. I think I did not express my problem well. To be clear, I used the FE_Enriched for assigning these two finite elements and combined them using FE_System: FE_Enriched fe_type_1(FE_Q(1,true), nullptr); FE_Enriched fe_type_2(FE_Q(1), enriched_function);

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

I am running my code in Debug using the latest 9.3 release. I have attached a minimal code and what it does it that it prints the constraints. - If BCs are applied for both parts of the system ,my output for the constraint is: 1. 0 = 0 2. 1 = 0 3. 2 = 0 4. 3

[deal.II] Problem with Debugging step-26 program

Deal deal.II community In my attempt to simulate the additive manufacturing process, I modified the step-26 program to reproduce the results in which I ran into an error which produces the output as : $ make run Consolidate compiler generated dependencies of target step-26 [ 66%] Built target

Re: [deal.II] dealii does not work on mac OS Big Sur

Dear Jean-Paul, I am trying to use PRISMS-PF (an open-source software) which is built on top of dealii library. As I wanted to compile, I faced the following error: $ cmake . CMake Deprecation Warning at CMakeLists.txt:5 (CMAKE_MINIMUM_REQUIRED): Compatibility with CMake < 2.8.12 will be

[deal.II] Gmsh unexpected behaviour - axes directions swapped

Dear all, I have encountered a strange problem while dealing with physical boundary ids. I have a simple cube mesh (annexure 1) which I am exporting to msh4 format for reading through GridIn. The mesh is constructed by extruding a square 2D mesh in x-y plane to 3D. I was facing problems with

Re: [deal.II] Inhomogeneous periodic boundary constraints

I ended up getting it working, so in case anyone else is interested in doing something similar, I have attached updated versions of the previous scripts. I further modified set_periodicity_constraints so that it can take a function to set the inhomogeneity based on the values of the two support

[deal.II] make install fails with ld signal 9

Dear all, I am trying to do a new installation of dealii. `make install` exits while compiling libdeal_II.g.so with ld signal 9. I had a look at this question and noted that this might be due to RAM shortage, but my device has

[deal.II] Re: make install fails with ld signal 9

Vachan, On Tuesday, May 4, 2021 at 2:45:30 AM UTC-4 vachanpo...@gmail.com wrote: > Dear all, > > I am trying to do a new installation of dealii. `make install` exits while > compiling libdeal_II.g.so with ld signal 9. I had a look at this question >

Re: [deal.II] Calculating normal vectors to deformed surface with pushforward operation

Hi Alex, Well, the one thing that I can clearly identify as being problematic is that the normal vector does not transform with the deformation gradient (directly), but rather with its cofactor. This is what Nanson’s formula for the transformation of surface areas tell us. We actually have a

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

Dear Daniel, Thank you for your reply. As per your recommendation, I followed step-45 for applying PBC. As long as understand, since I am not using parallel meshing, the second and third step are necessary for my case. Thus, I just used steps 1 and 4 as follows:

Re: [deal.II] dealii does not work on mac OS Big Sur

On 5/4/21 12:43 AM, Farid Mehri Sofiani wrote: CMake Error at CMakeLists.txt:8 (FIND_PACKAGE):   Could not find a package configuration file provided by "deal.II"   (requested version 8.3.0) with any of the following names:     deal.IIConfig.cmake     deal.ii-config.cmake   Add the

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

Dear Daniel, Thank you for your reply. As per your recommendation, I followed step-45 for applying PBC. As far as I realized, since I am not using parallel meshing, the second and third steps are not necessary for my case. Thus, I just used steps 1 and 4 as follows:

Re: [deal.II] Gmsh unexpected behaviour - axes directions swapped

Vachan, It is difficult to say what goes wrong here with the information you provided. How does the msh file created by gmsh look like. Is the boundary information correct there? Which gmsh version are you using? Can you post a complete minimal example of your code? Best, Daniel Am Di., 4. Mai

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

Farzin, https://www.dealii.org/current/doxygen/deal.II/namespaceDoFTools.html#a03324e6e060c6a55191b2c60ad871eab shows that the signature of the function you want to call is void DoFTools::make_periodicity_constraints( const DoFHandlerType & dof_handler, const types::boundary_id b_id1,

Re: [deal.II] GridTools::find_cells_adjacent_to_vertex: how to avoid multiple calling ?

Thanks for all answers! I've got a similar question: I looked up the Implementation of the mentioned function. Basically the function loops over all active cells and compares those global vertices with the one passed as second argument, so far so good. But is there a similar function which

[deal.II] Re: Problem related to make_hanging_nodes_constraints in the hp cases

Chong Liu, On Tuesday, May 4, 2021 at 12:06:39 PM UTC-4 liuch...@gmail.com wrote: > > Question: > > *How can I only constrain the hanging nodes for fe_type_1*? > Why do you want to do that? If you don't constrain fe_type_2, the solution won't be continuous. If you have more dofs in one side