Re: [deal.II] VectorTools::compute_nonzero_normal_flux_constraints on inner boundary and rientrant corners

[Wolfgang Bangerth]

I ran a test with a circular hole and a square hole. In both case I didn't get 
what I expected  (see images attached).


Eventually, I need to solve the problem on an irregular inner boundary so I am 
looking for a robust method.


I copied below the code. I very much appreciate any help with this.

Thank you
Giovanna

- - - - - - - - - -
  std::set normal_flux_boundaries;
  std::map *> boundary_functions;
  double velocity = 0.005;
   Functions::ConstantFunction  
constant_velocity(velocity,numVariables);


This corresponds to a vector-valued function equal to
  V = (v,v,...,v)   // every component is equal to 'velocity'



   normal_flux_boundaries.insert (Internal_boundary);
   boundary_functions.insert({Internal_boundary, _velocity});

   VectorTools::compute_nonzero_normal_flux_constraints    ( dof_handler,
                               0,   //  
first_vector_component,

                               normal_flux_boundaries,
                               boundary_functions,
                               constraints,
                               StaticMappingQ1< dim >::mapping
                               );


And this function then computes the constraints that correspond to ensuring 
that the solution's normal component equals

  n * V
Because V points diagonally to the top right in your figures, the constraint 
is that the normal component is zero whenever 'n' points to the top left or 
bottom right, which is exactly what you see in the picture of your square with 
a circular hole. In other words, I think it all looks like it should given 
what the function is doing :-)


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/dc96cce7-0ac9-eca5-179a-5a389817e934%40colostate.edu.

Re: [deal.II] Loss of symmetry by changing parameter

[Wolfgang Bangerth]

Upon closer inspection, one can see that the bottom left corner looks a bit 
"shaky" on the first 2 figures.


This is an artifact of plotting. What you are trying to visualize is a 
bilinear function on the bottom left cell, but Paraview/Visit actually show is 
a subdivision of the square cell into two triangles, and then using a linear 
interpolation on each triangle. The way the square is subdivided into 
triangles uses the bottom right -> top left diagonal. As a consequence, the 
bottom left and the bottom right cell are not shown the same way, even their 
values are perfectly symmetric.




I tried to get to the bottom of why this happens numerically ?
I found that at some point during my assembly of the RHS, there is a 
difference in what I obtained even though it should be perfectly symmetric. 


Are you observing this visually, or are you looking at actual numbers?


By digging even more I realised that the discrepancy steams from the 
boundary_worker (similar to the one of step-12).
On the fig. 4, the bottom right cell has its form function different than 0 
for dof =0 (angle dof) (i.e *fe_face.shape_value(dof = 0; point_gauss) =/= 0* )
whereas on the fig. 5, the bottom left cell has *fe_face.shape_value(dof = 0; 
point_gauss) *= 0 for all gauss point.


It is difficult to imagine that something this basic doesn't work given how 
widely these functions are used. But since you think you know what is 
happening, can you strip down your program to as-simple-as-possible a program 
that illustrates the issue?



So the fig.4 is the RHS for one direction beta=(0.14; 0.14) and fig 5. is the 
RHS for the other direction beta=(0.14;-0.14). The BC


This too does not actually look wrong to me, if you consider how Paraview 
plots the rhs vector. You can only trust the values in the vertices of that 
bottom row of cells, and the two pictures look perfectly symmetric to me.


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/755babdb-916f-6740-5531-5cddb068c283%40colostate.edu.

Re: [deal.II] Viewing node numbers and cell numbers in visualization

[Raghunandan Pratoori]

I was able to do it using DoFTools::map_dofs_to_support_points.

Best,
On Wednesday, October 6, 2021 at 3:22:02 PM UTC-5 Raghunandan Pratoori 
wrote:

> Thank you for your reply Dr. Bangerth.
>
> I want to check which vertices are associated with the what DoFs. How can 
> I extract them for each individual vertex? I could not find any relevant 
> extract_<..>_dofs function to do it.
>
> Best,
> Raghunandan.
> On Tuesday, October 5, 2021 at 10:06:02 PM UTC-5 Wolfgang Bangerth wrote:
>
>> On 10/5/21 8:30 PM, Raghunandan Pratoori wrote:
>> > 
>> > I would like to see how the nodes and cells are numbered during 
>> visualization, 
>> > much like in Abaqus. I am using Paraview for visualization. How should 
>> I write 
>> > my mesh for it to store all this data?
>>
>> Neither cell nor DoF numbers are exported in any format we write. That's 
>> because with the exception of scalar Q1 elements, there is no 1:1 
>> connection 
>> between vertices and DoF indices; for everything else, there is no 
>> connection 
>> and as a consequence we don't output this information. Sorry :-(
>>
>> 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/ceb05774-2bb1-409e-a9ff-d28f75b4cd35n%40googlegroups.com.

Re: [deal.II] Viewing node numbers and cell numbers in visualization

[Raghunandan Pratoori]

Thank you for your reply Dr. Bangerth.

I want to check which vertices are associated with the what DoFs. How can I 
extract them for each individual vertex? I could not find any relevant 
extract_<..>_dofs function to do it.

Best,
Raghunandan.
On Tuesday, October 5, 2021 at 10:06:02 PM UTC-5 Wolfgang Bangerth wrote:

> On 10/5/21 8:30 PM, Raghunandan Pratoori wrote:
> > 
> > I would like to see how the nodes and cells are numbered during 
> visualization, 
> > much like in Abaqus. I am using Paraview for visualization. How should I 
> write 
> > my mesh for it to store all this data?
>
> Neither cell nor DoF numbers are exported in any format we write. That's 
> because with the exception of scalar Q1 elements, there is no 1:1 
> connection 
> between vertices and DoF indices; for everything else, there is no 
> connection 
> and as a consequence we don't output this information. Sorry :-(
>
> 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/aa7faa4e-38a3-46be-bed9-f92bd3a56f2fn%40googlegroups.com.

[deal.II] Signature of TARGET_LINK_LIBRARIES in deal.II macros

['David Schneider' via deal.II User Group]

Hello everyone,

I recently started a project with different dependencies and I'm running 
into an issue due to a CMake deal.II macro. I'm forced to use 
'DEAL_II_SETUP_TARGET' as well as a similar macro from the other project 
and the projects use different versions of CMake's TARGET_LINK_LIBRARIES: 
one project uses TARGET_LINK_LIBRARIES including the signature keyword 
(PUBLIC, PRIVATE, INTERFACE), deal.II uses TARGET_LINK_LIBRARIES without 
the signature keyword. However, CMake does not allow to use both versions 
in one project. In principle, the issue is also described on stackoverflow 

 
in a different context, but I cannot modify the signature from my project.

I was wondering whether I'm the first one with this problem and whether it 
would be possible to have a switch within the deal.II macro in order to 
choose either of these signatures. Maybe someone has another solution I'm 
not aware of. I'm not even entirely sure, which of both signatures is 
actually the recommended way to go.

Best regards,
David

-- 
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/1d6ca7af-bac2-418f-a092-a44e3fe66162n%40googlegroups.com.

[deal.II] Re: Loss of symmetry by changing parameter

[Sylvain Mathonnière]

Always some errors are left after I wrote the message... errare humanum est.
I inversed the figure in the text, I meant : 

"On the fig. 5, the bottom right cell has its form function different than 
0 for dof =0 (angle dof) (i.e *fe_face.shape_value(dof = 0; point_gauss) 
=/= 0* ) 
whereas on the fig. 4, the bottom left cell has *fe_face.shape_value(dof = 
0; point_gauss) *= 0 for all gauss point.

Also when I wrote "The BC", I wanted to say that the boundary conditions 
are the same in both cases and are actually implemented directly in the 
assembly (like in step-12).

El miércoles, 6 de octubre de 2021 a la(s) 17:36:29 UTC+2, Sylvain 
Mathonnière escribió:

> Dear all,
>
> I am experiencing a symmetry issue in my calculation with certain set of 
> parameters.
> In the 3 figures below, I used different sets of parameters (same 
> equation) and plotted the result once the simulation reaches steady state.
> The two first figures look fairly symmetric (as it should be) but the 3rd 
> one is obviously not symmetric.
> Upon closer inspection, one can see that the bottom left corner looks a 
> bit "shaky" on the first 2 figures.
>
> [image: fig1_3.PNG]
>
> I tried to get to the bottom of why this happens numerically ? 
> I found that at some point during my assembly of the RHS, there is a 
> difference in what I obtained even though it should be perfectly symmetric. 
> The solver takes also significantly longer to solve it.
> I represented the RHS on a coarse grid to highlight the difference.
>
> [image: fig4_5.PNG]
>
> By digging even more I realised that the discrepancy steams from the 
> boundary_worker (similar to the one of step-12).
> On the fig. 4, the bottom right cell has its form function different than 
> 0 for dof =0 (angle dof) (i.e *fe_face.shape_value(dof = 0; point_gauss) 
> =/= 0* ) 
> whereas on the fig. 5, the bottom left cell has *fe_face.shape_value(dof 
> = 0; point_gauss) *= 0 for all gauss point.
>
> For the record, I am solving several time the radiative transport equation 
> I  using the discontinuous galerkin method using several directions. 
> [image: RTE.PNG]
> So the fig.4 is the RHS for one direction beta=(0.14; 0.14) and fig 5. is 
> the RHS for the other direction beta=(0.14;-0.14). The BC 
>
> *My question is the following: *
> Is this a normal behaviour that I am experiencing and the lack of symmetry 
> in fig. 3 is linked with the fact that my mesh is not fine enough ?
> or could it be the result of something wrong in my code (I attached a 
> snipset of it below) ?
>
> I am not experienced enough to know the difference. I know the code works 
> well because I compared it to scientific reference + using the method of 
> manufactured solution, so if there is a mistake, it has to be "small".
>
> Best regards,
>
> Sylvain Mathonnière 

-- 
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/dda13b58-6234-45bd-8a29-3fbf0d7e6ae3n%40googlegroups.com.