Re: [deal.II] Tie constraints in deall.II?

[Wolfgang Bangerth]

I am considering switching to deal.II for carrying out my elasticity 
calculations, but I am not sure from the documentation, tutorials, and this 
user group if it is not too difficult to create a constraint between two 
surfaces such that they are bonded, or forced to be continuous. In ABAQUS this 
is called a tie constraint 


If you can make the mesh at the ends of your object match (e.g., if you want 
to bend your object into a ring), then the construction of these constraints 
is essentially identical to how one imposes periodic constraints -- namely, 
that each degree of freedom one end has to be some kind of linear function of 
the corresponding degree of freedom on the other end. deal.II has functions 
for this kind of thing that you could base an implementation for your cases on.


If the meshes don't match, e.g., if you want to glue one end piece to the side 
of your tube, then the situation becomes more complicated and the usual 
approach to this is to use "mortar elements" or (what we used to call) a 
master-slave approach where in essence the displacement on one side is 
"projected" onto the displacements of the other side. That, too, can be done 
in deal.II (and has been done), but it is substantially more complicated 
because you have to solve a geometry problem where you ask which point on one 
surface a node on the other surface corresponds to.


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/de312b8a-842b-3c89-cd65-16407f66572c%40colostate.edu.

[deal.II] Re: Making ParticlesHandler work with dealii::Triangulation and mesh refinement/coarsening

[blais...@gmail.com]

Dear Wu,
Have you tried without the dynamic cast? Can you bind the callback of a 
regular triangulation?
I must admit I have never tried to use particles with regular triangulation 
(and I think that outside of step-19, not much people have done it ).


On Tuesday, December 15, 2020 at 4:49:39 p.m. UTC-5 WU, Qihang wrote:

> Hi deal.II Community,
>
> I am new to the library and I'm trying to implement a prototype Stokes 
> flow solver with tracer particles using shared memory computing. The 
> overall procedure is something like:
>
> 1) Solve velocities and pressure analogous to Step-22.
> 2) Execute coarsening and refinement
> 3) Interpolate velocities to particles and move particles.
>
> What I found is after grid coarsening, the particles which originally 
> belong to the finer grid loses its host cell and an exception is thrown 
> from ParticleAccessor::get_surrounding_cell().
>
> I read through step-19 on Github. From my understanding the implementation 
> there does not involve AMR and therefore such problems do not occur. I also 
> consulted step-68 and 70. Those two implementations use 
> parallel::distributed::Triangulation and attach pre- and post-refinement 
> callback functions to save and reload particles. However in these functions 
> the dynamic_cast from Triangulation to p::d::Triangulation is invalid and 
> returns a nullptr.
>
> My question is am I correct to assume that the library does not yet fully 
> support particles on dealii::Triangulation with AMR? If yes can I ask for 
> some guidance on how to implement it myself? One naive way out seems to be 
> to store and reload procedure as is done in the library for 
> p::d::Triangulation, but is it too costly?
>
> I really appreciate your time and help.
>
> Cheers,
> Qihang.
>
>
>
>
>

-- 
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/1838b606-b9d3-4508-9904-5ec11493921dn%40googlegroups.com.

Re: [deal.II] FEInterfaceValues

[Timo Heister]

Alberto,

> I would like to have a few more details on the class FEInterfaceValues.
> since it is my feeling that  FEInterfaceValues
> might be conveniently used for interfaces, even out of DG methods.

Yes, I would think so.

> Specifically I'd like to figure out if this notion can be used without 
> recurring to the MeshWorker::mesh_loop,
> which I am not quite confident at present.

Note that we are not using the MeshWorker machinery but a single
function that contains the loops over the cells. The code of the
function is "relatively" easy to understand and you will appreciate
the logic for the following things you would have to deal with when
looping manually:
- assembling from the finer cell for interfaces with adaptive refinement
- correctly handling each facet once (or twice if desired) even in parallel
- handling of periodic boundaries

> I'd like to play autonomously with the class FEInterfaceValues
> but unfortunately I cannot grasp the notion of subface, which is apparently
> required by the reinit as in step 12:
>  fe_iv.reinit(cell, f, sf, ncell, nf, nsf);

With adaptivity you will need to pass the subface as returned by
neighbor_of_coarser_neighbor, otherwise it is
numbers::invalid_unsigned_int. See
https://github.com/dealii/dealii/blob/691ff4907964605dd21e94f06c880786af2cd612/tests/feinterface/fe_interface_values_03.cc#L94-L100
and
https://github.com/dealii/dealii/blob/691ff4907964605dd21e94f06c880786af2cd612/tests/feinterface/fe_interface_values_02.cc#L88-L93

> Can anyone address me some reading on this notion and how it is dealt with
> by the MeshWorker::mesh_loop ?

Take a look at the tests in tests/feinterface/:
https://github.com/dealii/dealii/tree/master/tests/feinterface

Many of them use FEInterfaceValues directly on a small test mesh.

-- 
Timo Heister
http://www.math.clemson.edu/~heister/

-- 
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/CAMRj59Fq2wUezf%3DikmWF5_BPB-Q1zzYgjOgd4XESUYdwX_pJ_A%40mail.gmail.com.

Re: [deal.II] Div-conforming elements in 3D

[Konrad Simon]

Dear Jean-Paul, dear Deal.II community,

I partially solved the problem of sign flipping and permuting the degrees 
of freedom and would like to come up with a merge-request at least for the 
RaviartThomas elements. I have some questions before I can go on and 
guidance would be appreciated.

I decided to go a similar way that is taken for FE_Q elements. There one 
has only a permutation of dofs on non-standard or flipped or rotated faces 
since a sign change in the orientation does not matter. A vector of size 
n_faces_per_cell of which each contains a table mapping each face_dof and 
each of the 8 combinations of the flags (non-standard | flipped | rotated) 
to an offset of that face_dof. The system behind that relies on the 
lexicographic ordering of dofs if I understand correctly. My questions:

1. Is there a similar numbering scheme for dofs on faces for RT elements. 
There one has face moments as dofs and it is not fully clear to me what 
lexicographic means there (if such a principle is usable there at all).

2. If the order (and sign) of face_dofs if permuted for each of the flags 
(non-standard | flipped | rotated) then in what order are the permutations 
applied? (They do not commute)

I would like to avoid hard-coding that (I think up to order 2 would be 
doable -> but already 54 face_dofs). 

I believe the table similar 
to adjust_quad_dof_index_for_face_orientation_table of FE_Q_Base makes 
sense but I guess every FE inheriting from FE_PolyTensor must implement 
such a table then. This is a lot of work and more complicated for Nedelec 
elements.

Best,
Konrad
On Saturday, December 12, 2020 at 8:07:19 PM UTC+1 Konrad Simon wrote:

> Hi Jean-Paul,
>
> On Thursday, December 10, 2020 at 11:39:08 PM UTC+1 Jean-Paul Pelteret 
> wrote:
>
>> HI Konrad,
>>
>> I have no familiarity with the H-div elements, so I could be wrong with 
>> this suggestion...
>>
>> The Fe_Nedelec element suffered from a similar issue, where adjacent 
>> cells had to agree on the edge sense/directionality. This requirement could 
>> not be unconditionally guaranteed for that element type, hence the 
>> following note in its introduction 
>> 
>>
>> Even if this element is implemented for two and three space dimensions, 
>> the definition of the node values relies on consistently oriented faces in 
>> 3D. Therefore, care should be taken on complicated meshes.
>>
>
> Yes, this issue is similar. I assume I will need to check that for these 
> elements as well since I also need them.
>
>
>> The more recent FE_NedelecSZ 
>>  
>> element resolves the issue by querying the vertex numbers that make up each 
>> edge/face and applying a rule that gives each face and its bounding edges a 
>> direction. This means that the orientation of the face/edges is always 
>> consistent no matter which of the two cells that share the face you're on. 
>> The details are more explicitly laid out in the FE_NedelecSZ 
>>  
>> introduction, as well as the two papers that are listed therein. 
>>
>
> This is a nice alternative for the Nedelec element. Often though such 
> elements are used in conjunction with H1 or H(div) conformal elements and 
> need to satisfy a compatibility condition (stronger than just LBB, i.e., 
> they must form a bounded co-chain complex that is a subcomplex to something 
> else). I am not sure that this element does satisfy this condition together 
> with classical RT elements etc.
>
>
>> Now, I'm by no means certain that underlying issue that you're seeing 
>> here is the same as that which plagued the canonical Nedelec element 
>> (although your comment #3 makes me suspect that it could be). But if it is, 
>> then perhaps what was done to fix the orientation conflict in the Zaglmayr 
>> formulation of the Nedelec element can serve as inspiration for a fix to 
>> the BDM and RT elements?
>>
>> Thanks for looking into this, and I hope that you have some success at 
>> finding a solution to the problem. Naturally, if there's anything that we 
>> can do to help please let us know. It would be very nice to have a robust 
>> implementation to these elements in the library, so anything that you might 
>> be willing to contribute would be greatly appreciated!
>>
>  
> Lowest order RaviartThomas is already fixed. I will hunt down this issue 
> as good as I can. I might need some help with local and global dof 
> numbering conventions. I will also try to move the discussion to the issue 
> page  on github.
>
> Best,
> Konrad
>

-- 
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 

Re: [deal.II] FEInterfaceValues

[Wolfgang Bangerth]

Alberto,
have you taken a look at step-47? That's probably the program with the 
"purest" use of that class.

Best
 W.

On 12/16/20 11:50 AM, Alberto Salvadori wrote:

Dear community

I would like to have a few more details on the class FEInterfaceValues 
.
since it is my feeling that FEInterfaceValues 


might be conveniently used for interfaces, even out of DG methods.

Specifically I'd like to figure out if this notion can be used without 
recurring to the MeshWorker::mesh_loop 
,

which I am not quite confident at present.

I'd like to play autonomously with the class FEInterfaceValues 


but unfortunately I cannot grasp the notion of subface, which is apparently
required by the reinit as in step 12:
  fe_iv.reinit 
(cell, 
f, sf, ncell, nf, nsf);


Can anyone address me some reading on this notion and how it is dealt with
by the MeshWorker::mesh_loop 
 ?


I appreciate your help

Alberto





Informativa sulla Privacy: http://www.unibs.it/node/8155 



--
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 

[deal.II] FEInterfaceValues

[Alberto Salvadori]

Dear community

I would like to have a few more details on the class FEInterfaceValues 

.
since it is my feeling that  FEInterfaceValues 

might be conveniently used for interfaces, even out of DG methods.

Specifically I'd like to figure out if this notion can be used without 
recurring to the MeshWorker::mesh_loop 

,
which I am not quite confident at present.

I'd like to play autonomously with the class FEInterfaceValues 

but unfortunately I cannot grasp the notion of subface, which is apparently
required by the reinit as in step 12:
 fe_iv.reinit 
(cell,
 
f, sf, ncell, nf, nsf);

Can anyone address me some reading on this notion and how it is dealt with
by the MeshWorker::mesh_loop 

 ?

I appreciate your help

Alberto




-- 


Informativa sulla Privacy: http://www.unibs.it/node/8155 


-- 
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/1d271fc5-1017-49a3-80bf-cdd17e2e70aan%40googlegroups.com.

Re: [deal.II] Re: Some changes in arpack.h (Functionality to compute only eigenvalues)

[Bruno Turcksin]

Le mer. 16 déc. 2020 à 04:55, Animesh Rastogi IIT Gandhinagar
 a écrit :
>
> Thank you Bruno for your suggestion. I tried in regular mode and it doesn't 
> seem to improve the accuracy. The results are approximately the same as I was 
> getting using the shift-invert method.
>
> One thing that I didn't understand is that I used the scipy function "eigs" 
> in python which essentially uses ARPACK, and it still it doesn't match with 
> that. Does it have to do something with the way the ARPACK code is written in 
> dealii?

The code in deal.II just hands the data to ARPACK. There is nothing
special about this. For us it worked for simple cases but for harder
problems we saw a difference.

> Can you let me know how to use Anasazi, I don't see anything related to this 
> in the documentation of deaii? I am planning to now try this eigensolver for 
> my problem and would want to see how much it improves the results.

It's not in deal.II. Anasazi is part of Trilinos. If you are using
Trilinos vector, it's pretty straightforward. You just copy the code
from 
https://github.com/ORNL-CEES/mfmg/blob/master/include/mfmg/dealii/anasazi.templates.hpp
The solver is used here:
https://github.com/ORNL-CEES/mfmg/blob/4026049f0d5e3904562e394954f76cd86aac2ef3/include/mfmg/dealii/amge_host.templates.hpp#L209-L275
If you want to use a different kind of vectors, drop these files in
your code 
https://github.com/ORNL-CEES/mfmg/blob/master/include/mfmg/dealii/multivector.hpp,
https://github.com/ORNL-CEES/mfmg/blob/master/include/mfmg/dealii/anasazi_traits.hpp,
and 
https://github.com/ORNL-CEES/mfmg/blob/master/include/mfmg/dealii/belos_traits.hpp.
You will need to remove the ASSERT, if you don't want to pull more
files.

Best,

Bruno

-- 
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/CAGVt9eNPqEE4UWUtAdXFCH20UPCvoWMfBbg1iTE_5GVFOUKnPA%40mail.gmail.com.

Re: [deal.II] Re: Some changes in arpack.h (Functionality to compute only eigenvalues)

[Animesh Rastogi IIT Gandhinagar]

Thank you Bruno for your suggestion. I tried in regular mode and it doesn't 
seem to improve the accuracy. The results are approximately the same as I 
was getting using the shift-invert method. 

One thing that I didn't understand is that I used the scipy function "eigs" 
in python 
 
which essentially uses ARPACK, and it still it doesn't match with that. 
Does it have to do something with the way the ARPACK code is written in 
dealii?

Can you let me know how to use Anasazi, I don't see anything related to 
this in the documentation of deaii? I am planning to now try this 
eigensolver for my problem and would want to see how much it improves the 
results.

Thanks!

Animesh



On Wednesday, December 16, 2020 at 3:26:57 AM UTC+5:30 bruno.t...@gmail.com 
wrote:

> Animesh,
>
> You need to download the patch to the deal.II directory. If you cloned
> deal.II, you can simply use git apply
> 0001-Enable-ARPACK-in-regular-mode.patch. If you didn't use git to get
> deal.II, I think patch -i 0001-Enable-ARPACK-in-regular-mode.patch
> should work. I have also noted that Arpack was not very accurate. I am
> not sure why because according to the documentation, many other
> packages are successfully using Arpack. At the end, we gave up on
> Arpack and switched to lobpcg from anasazi. The results were more
> accurate and more stable.
>
> Best,
>
> Bruno
>
> Le mar. 15 déc. 2020 à 07:52, Animesh Rastogi IIT Gandhinagar
>  a écrit :
> >
> > Hi Bruno,
> >
> > I would like to use this patch to compute the smallest eigenvalues in my 
> case. Could you please let me know how should I update my source code in 
> the arpack.h header file to accommodate these changes in the patch. I 
> understand that I would need to reinstall dealii after updating the source 
> code, which I am fine with.
> >
> > When I am using the shift-inverse mode, I am not getting the results 
> similar to what I would get using the eigenvalue solver in MATLAB or Python 
> for the same matrix. There is a difference of about 15 to 20 in the 
> eigenvalues (even when comparing it with the ARPACK solver in Python). This 
> is the reason that I would want to try calculating the eigenvalues using 
> the patch you created in regular mode.
> >
> > Thanks!
> >
> > Animesh
> > On Sunday, November 8, 2020 at 6:00:58 PM UTC+5:30 Animesh Rastogi IIT 
> Gandhinagar wrote:
> >>
> >> Thank you Bruno, I was able to change the source code accordingly. I 
> reinstalled dealii and it worked fine!
> >>
> >> Thanks again!
> >>
> >> Animesh
> >>
> >> On Friday, November 6, 2020 at 3:55:29 AM UTC+5:30 bruno.t...@gmail.com 
> wrote:
> >>>
> >>> Animesh,
> >>>
> >>> On Thursday, November 5, 2020 at 1:11:33 PM UTC-5 
> animesh...@alumni.iitgn.ac.in wrote:
> 
>  However, I have no way of passing it as a parameter to the solver 
> function. I was planning to edit the header file arpack.h accordingly which 
> is inside the /usr/local/include/deal.II/lac to have that functionality. I 
> was actually thinking of passing the flag "rvec" as an argument to the 
> function solve. I was wondering if I change the permission of the file to 
> write mode, edit it and save it, would I be able to run my code inside the 
> examples folder. Or do I need to take care of something else while and 
> after editing that headerfile?
> >>>
> >>> You should change the source code and reinstall deal.II. I would do 
> what you propose only if you cannot compile deal.II on that machine. It 
> might work in this particular case but I really advise you against it.
> >>>
> >>> Best,
> >>>
> >>> Bruno
> >>>
> >
> > --
> > 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 a topic in the 
> Google Groups "deal.II User Group" group.
> > To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/dealii/2hA57ZghGqs/unsubscribe.
> > To unsubscribe from this group and all its topics, send an email to 
> dealii+un...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/dealii/81e7a0d4-4ab9-4323-8beb-aa7897feb4c2n%40googlegroups.com
> .
>

-- 
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/aa324ad1-b51d-4940-a34d-68680074b4b4n%40googlegroups.com.