Re: [deal.II] point_value FE_Nedelec

[Wolfgang Bangerth]

On 4/22/21 7:11 PM, John Smith wrote:
I have made a silly mistake. Thank you for pointing out this mistake! The 
shape functions indeed look fine!


I apologize for wasting time your time like that …


No worries -- we've all made these sorts of mistakes!
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/b00f21de-434a-c1d2-5cf3-8f41749f9a80%40colostate.edu.

Re: [deal.II] point_value FE_Nedelec

[John Smith]

 

Dear Wolfgang,

I have made a silly mistake. Thank you for pointing out this mistake! The 
shape functions indeed look fine!

I apologize for wasting time your time like that …

Best wishes, 

John


On Friday, April 23, 2021 at 1:21:42 AM UTC+2 Wolfgang Bangerth wrote:

>
> > For the second question: You are absolutely right. I do expect two edge 
> > elements of different degree to be different.
>
> Right, but that does not mean that every shape function of FE_Nedelec(1) 
> must 
> be different from all of the FE_Nedelec(0) shape functions. Some of them 
> may 
> in fact be the same. (c.f. the example of FE_QHierarchical.)
>
> I ran your program, and the shape functions for FE_Nedelec(0) look correct 
> to 
> me, but there are two small mistakes you are making:
> (i) in the figure you show in the other email, your assumptions about
> the order of edges is not correct. It should be this:
>
> *--3--*
> | |
> 0 1
> | |
> *--2--*
>
> (ii) in your little test code, you have these lines where you (try to) 
> reset
> the solution vector:
>
> for (unsigned int i; i < solution.size(); ++i)
> solution(i) = 0;
>
> In this loop, you forget to initialize 'i' to zero at the beginning of
> the loop. If you do, you get the expected results and you will also
> see how this will work for the FE_Nedelec(1).
>
> Best
> Wolfgang
>
>
> -- 
> 
> Wolfgang Bangerth email: bang...@colostate.edu
> www: http://www.math.colostate.edu/~bangerth/
>
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/09182bf2-1d1a-4f34-891c-053bf279ed96n%40googlegroups.com.

Re: [deal.II] point_value FE_Nedelec

[Wolfgang Bangerth]

For the second question: You are absolutely right. I do expect two edge 
elements of different degree to be different.


Right, but that does not mean that every shape function of FE_Nedelec(1) must 
be different from all of the FE_Nedelec(0) shape functions. Some of them may 
in fact be the same. (c.f. the example of FE_QHierarchical.)


I ran your program, and the shape functions for FE_Nedelec(0) look correct to 
me, but there are two small mistakes you are making:

 (i) in the figure you show in the other email, your assumptions about
 the order of edges is not correct. It should be this:

   *--3--*
   | |
   0 1
   | |
   *--2--*

  (ii) in your little test code, you have these lines where you (try to) reset
   the solution vector:

  for (unsigned int i; i < solution.size(); ++i)
solution(i) = 0;

   In this loop, you forget to initialize 'i' to zero at the beginning of
   the loop. If you do, you get the expected results and you will also
   see how this will work for the FE_Nedelec(1).

Best
 Wolfgang


--

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/7b72951c-1d66-8f57-c592-0e3161ca311b%40colostate.edu.

Re: [deal.II] Removing cells in parallel distributed triangulation

[Wolfgang Bangerth]

On 4/22/21 10:52 AM, Mohammadreza ya'ghoobi wrote:


I'm trying to solve a simpler problem of uniaxial response of a plate with 
hole using FE_Nothing as you recommended. I re-read steps 10, 27, and 46 to 
refresh my memory. I think I have the logic but I appreciate if you check some 
of the steps I have a little concern about. The two main step I took are:

1) I assign the cells inside the hole as FE_Nothing and the rest as regular FE.
2) During the stiffness matrix and residual force formation, I only go over 
the elements in regular FE part and exclude the FE_Nothing element from the 
calculation.


My only concern are the cells on the interface. Does performing assembly and 
residual formation just on the FE cells (and exclude FE_Nothing cells) 
guarantee the traction free surface of the cells on the surface of the hole?  
Or I need to take extra action to guarantee the traction free surface of the hole?


That depends on how you create the FE_Nothing element. Its constructor takes a 
flag that determines what the solution should look like on the other side: 
Should it be zero at the interface, or be unconstrained? You want it to be 
unconstrained -- it's a boundary at which you intend to do nothing special 
(which will then correspond to zero-traction Neumann-type boundary condition).


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/0a6ff0c3-b185-784f-8fa7-ffb8f76771d9%40colostate.edu.

Re: [deal.II] Removing cells in parallel distributed triangulation

[Mohammadreza ya'ghoobi]

Dear Jean-Paul,

I'm trying to solve a simpler problem of uniaxial response of a plate with 
hole using FE_Nothing as you recommended. I re-read steps 10, 27, and 46 to 
refresh my memory. I think I have the logic but I appreciate if you check 
some of the steps I have a little concern about. The two main step I took 
are:
1) I assign the cells inside the hole as FE_Nothing and the rest as regular 
FE.
2) During the stiffness matrix and residual force formation, I only go over 
the elements in regular FE part and exclude the FE_Nothing element from the 
calculation.

My only concern are the cells on the interface. Does performing assembly 
and residual formation just on the FE cells (and exclude FE_Nothing cells) 
guarantee the traction free surface of the cells on the surface of the 
hole?  Or I need to take extra action to guarantee the traction free 
surface of the hole?

Thanks
Reza
On Tuesday, April 20, 2021 at 5:19:13 PM UTC-4 Jean-Paul Pelteret wrote:

> Hi Reza,
>
> With no context as to how element deletion affects the geometry itself, 
> may I ask if you’ve considered element deactivation using the FE_Nothing 
> element? If you can afford to store the mesh but primarily want to ensure 
> that no DoFs are assigned to a region outside of the physical domain 
> boundaries, then this might be an alternate approach to adjusting the mesh 
> directly.
>
> Best,
> Jean-Paul
>
> On 20. Apr 2021, at 21:58, mohammadreza yaghoobi  
> wrote:
>
> Thanks Marc. 
>
> My biggest challenges are both time and memory. I'm trying to model a 
> crystal plasticity sample with ~20 million elements. In the case of no 
> element deletion, I can simply use global refinement and I won't face 
> memory issues while generating mesh and running the code (and of course no 
> time on element deletion).
>
> However, when I'm trying to add the element deletion feature, then I 
> cannot use global refinement,  and I'll face the memory issue, since all of 
> the triangulation will be on the coarsest level. On top of that, for every 
> processor, the code has to search the element deletion pattern for all of 
> the triangulation (~20 million elements). As I increase the sample size, 
> each processor still needs to handle all the elements which becomes a big 
> bottle-neck, and also uses the resources very inefficiently. Actually, 
> parallelization cannot help at all with this part of the code, which 
> actually serves as the serial with large memory requirements. Just to give 
> you an idea, it will take about 12 hrs in my example to bypass the element 
> deletion search part running on 1500 processors, each has 38gb memory. I 
> actually have to underutilize my node (instead of 24, I'm using 5) because 
> of memory issues.
>
> The ideal case would be each processor just handling their own part and 
> some reduction happened throughout the processors.
>
> I hope I was able to clarify the bottle neck.
>
> Thanks
> Reza
>
>
>
> On Tue, Apr 20, 2021 at 3:47 PM Marc Fehling  wrote:
>
>> Hello Reza,
>>
>> `parallel::distributed::Triangulation` objects store the entire coarse 
>> mesh, see also the module documentation 
>> . 
>> This allows for a quick execution of adaptive refinement. So from my 
>> understanding, you need to perform this operation on *all* active cells, 
>> including ghost and artificial ones. So the working code you have might be 
>> the only way to use 
>> `GridGenerator::create_triangulation_with_removed_cells()` in the parallel 
>> distributed context.
>>
>> Can you quantify how inefficient your code is? For example did you time 
>> how long your mesh creation takes and compare it to the overall runtime?
>>
>> Best,
>> Marc
>>
>> On Tuesday, April 20, 2021 at 12:14:10 PM UTC-6 mohammadre...@gmail.com 
>> wrote:
>>
>>> Hi,
>>>
>>> I'm trying to subtract some elements based on a user-defined criteria. 
>>> Ideally, I want to use each processor in a way that they are responsible 
>>> only for their partition (using is_locally_owned()) to remove the cells 
>>> from the triangulation 
>>> using GridGenerator::create_triangulation_with_removed_cells. However, when 
>>> I used  this, it will not proceed after 
>>> GridGenerator::create_triangulation_with_removed_cells. 
>>> Very inefficient solution is each processor will process the whole 
>>> triangulation space and remove the elements. This works. However, as the 
>>> simulation size increases, this becomes really a bottle neck.
>>>
>>> Is there any way I can tackle this smarter?
>>>
>>> Thanks
>>> Reza
>>>
>>> *Below is the version of the code which works but very inefficiently.*
>>> *I added the red lines so every processor be responsible just for their 
>>> own parts. It stops at 
>>> GridGenerator::create_triangulation_with_removed_cells.*
>>>
>>>
>>>
>>> GridGenerator::subdivided_hyper_rectangle (triangulation2, 
>>> userInputs.subdivisions, Point(), 
>>> 

[deal.II] deal.II Newsletter #163

['Rene Gassmoeller' via deal.II User Group]

Hello everyone!

This is deal.II newsletter #163.
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:

#12080: [C++17] Check whether the output directory exists. (proposed by 
bangerth) https://github.com/dealii/dealii/pull/12080

#12079: Add level set functions for a plane and a sphere (proposed by 
simonsticko) https://github.com/dealii/dealii/pull/12079

#12077: Remove `parallel::distributed::ErrorPredictor`. (proposed by 
marcfehling) https://github.com/dealii/dealii/pull/12077

#12076: Correct 2-D FE_Nedelec Interpolation (proposed by harmonj) 
https://github.com/dealii/dealii/pull/12076

#12075: Doc: Function has been renamed (proposed by marcfehling; merged) 
https://github.com/dealii/dealii/pull/12075

#12074: Bugfix: `hp::Refinement::predict_error` - cast to int (proposed by 
marcfehling) https://github.com/dealii/dealii/pull/12074

#12073: step-27: limit p-level difference (proposed by marcfehling) 
https://github.com/dealii/dealii/pull/12073

#12071: Move GridReordering::invert_all_negative_measure_cells(). 
(proposed by drwells; merged) https://github.com/dealii/dealii/pull/12071

#12070: Minor optimization in Utilities::MPI::broadcast(). (proposed by 
bangerth; merged) https://github.com/dealii/dealii/pull/12070

#12069: Simplify control flow in AlignedVector::resize{,_fast}. (proposed by 
bangerth; merged) https://github.com/dealii/dealii/pull/12069

#12068: Improve the scalar assignment exception message. (proposed by drwells; 
merged) https://github.com/dealii/dealii/pull/12068

#12067: Deprecate TriaAccessor::number_of_children. (proposed by bangerth; 
merged) https://github.com/dealii/dealii/pull/12067

#12065: Minor updates to the grid reordering module. (proposed by bangerth; 
merged) https://github.com/dealii/dealii/pull/12065

#12064: Add a test for AlignedVector. (proposed by bangerth; merged) 
https://github.com/dealii/dealii/pull/12064

#12063: Add error message to GridIn::ExcNoTriangulationSelected (proposed by 
peterrum; merged) https://github.com/dealii/dealii/pull/12063

#12062: Add function estimating Function bounds over a BoundingBox (proposed by 
simonsticko) https://github.com/dealii/dealii/pull/12062

#12061: fix a warning (proposed by tamiko; merged) 
https://github.com/dealii/dealii/pull/12061

#12060: fix a -Wdtor warning (proposed by tamiko; merged) 
https://github.com/dealii/dealii/pull/12060

#12059: Remove GridReordering part 1 (proposed by drwells; merged) 
https://github.com/dealii/dealii/pull/12059

#12057: Provide a move constructor for InterpolatedTensorProductGridData. 
(proposed by bangerth) https://github.com/dealii/dealii/pull/12057

#12056: Make the documentation of TableBase less chatty. (proposed by bangerth; 
merged) https://github.com/dealii/dealii/pull/12056

#12055: Fix grammar. (proposed by bangerth; merged) 
https://github.com/dealii/dealii/pull/12055

#12054: Utilities::MPI::mpi_sum_avg: create MPI_Datatype and MPI_Op once 
(proposed by tamiko; merged) https://github.com/dealii/dealii/pull/12054

#12053: Fix test matrix_free/ecl_02 (proposed by peterrum; merged) 
https://github.com/dealii/dealii/pull/12053

#12052: Make test remote_point_evaluation/vector_tools_evaluate_at_points_02 
more robust (proposed by peterrum; merged) 
https://github.com/dealii/dealii/pull/12052

#12051: Fix matrix_free/compute_diagonal tests in release mode (proposed by 
peterrum; merged) https://github.com/dealii/dealii/pull/12051

#12050: Fix test matrix_free/categorize_by_boundary_ids_01 (proposed by 
peterrum; merged) https://github.com/dealii/dealii/pull/12050

#12049: Remove remaining create_triangulation_compatibility calls. (proposed by 
drwells; merged) https://github.com/dealii/dealii/pull/12049

#12048: Get rid of create_triangulation_compatibility in the GMSH reader. 
(proposed by drwells; merged) https://github.com/dealii/dealii/pull/12048

#12047: FEInterfaceValues extractors (proposed by zjiaqi2018) 
https://github.com/dealii/dealii/pull/12047

#12046: Remove calls to create_triangulation_compatibility in GridGenerator. 
(proposed by drwells; merged) https://github.com/dealii/dealii/pull/12046

#12045: Remove two more create_triangulation_compatibility calls. (proposed by 
drwells; merged) https://github.com/dealii/dealii/pull/12045

#12031: Update the KINSOL callbacks to what KINSOL current provides. (proposed 
by bangerth; merged) https://github.com/dealii/dealii/pull/12031

#12030: Support different KINSOL versions. (proposed by bangerth; merged) 
https://github.com/dealii/dealii/pull/12030

#12027: Improve error messages during configuration. (proposed by bangerth; 
merged) https://github.com/dealii/dealii/pull/12027

#12026: Use a better filename for SUNDIALS finding. (proposed by bangerth; 
merged) https://github.com/dealii/dealii/pull/12026


## And this is a list of recently opened or closed discussions:

#12078: `CMake