getfem-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Imposing Dirichlet B.C. using Nitsche's method in fictitious domains


From: Yves Renard
Subject: Re: Imposing Dirichlet B.C. using Nitsche's method in fictitious domains for elastoplasticity.
Date: Thu, 28 May 2020 11:56:21 +0200 (CEST)


Dear Kostas,

ALL means INSIDE and OUTSIDE. This is the usefull option since the case to have 
to integrate simultaneously the same term on the domain an on the interface 
does not happen in practice.

This is not so easy here because Gauss points on the interface are some 
internal Gauss points of the elements cut by the level-set. We can add them, 
but sometimes it will be necessry to set their respective weights to zero (to 
integrate on the domain) and on the contrary to set the weight of real internal 
Gauss points to zero (to integrate on the boundary). In practice, this means 
that two different mesh_im are needed with the same Gauss points and different 
weights.

And of course, you are right, in case of evolving interface, some Gauss points 
will appear and some will deseapper, which will cause some difficulties !

This would say, in the case of a moving interface, that the interpolation of 
the plastic strain on the interface is probably the better strategy.

Best regards,

Yves



----- Mail original -----
De: "logari81" <logari81@googlemail.com>
À: "yves renard" <yves.renard@insa-lyon.fr>
Cc: "Heungson Lee" <heungson.lee@gmail.com>, "getfem-users" 
<Getfem-users@nongnu.org>
Envoyé: Mercredi 27 Mai 2020 18:41:03
Objet: Re: Imposing Dirichlet B.C. using Nitsche's method in fictitious domains 
for elastoplasticity.

Dear Yves,

Regarding the first adaptation of mesh_im_level_set, do you mean to combine
INSIDE, OUTSIDE and BOUNDARY? Isn't this what the ALL keyword is about? I
am probably missing something here.
[image: image.png]
Regarding supporting a mesh_im_level_set based mim_data object. You mean
for a static/fixed level-set right? Because for a level-set that evolves
any information on integration points on the interface will be lost after
the interface moves. But maybe this is not the case you are talking about
here.

Best regards
Kostas

On Tue, May 26, 2020 at 5:51 PM Yves Renard <yves.renard@insa-lyon.fr>
wrote:

>
> Dear  Heungson Lee,
>
> I hadn't thought about this case (fictitious domain). You are right, the
> cut integration methods do not support to have both integration points for
> the elements and for the interface.
> Clearly, it would need two adaptations:
> - mesh_im_level_set level-set object to support both integration points on
> the interface and elements.
> - mim_data object to support mesh_im_level_set object, which is not done
> for the moment
> Both seems to be not so complex adaptations (it would need to investigate
> a little more, though).
>
> Best regards,
>
> Yves.
>
>
> ----- Mail original -----
> De: "Heungson Lee" <heungson.lee@gmail.com>
> À: "yves renard" <yves.renard@insa-lyon.fr>
> Cc: "getfem-users" <Getfem-users@nongnu.org>
> Envoyé: Mardi 26 Mai 2020 09:23:45
> Objet: Re: Imposing Dirichlet B.C. using Nitsche's method in fictitious
> domains for elastoplasticity.
>
> Dear Yves Renard and getfem users.
>
> I am trying to add boundaries to MeshImData. However, in case of a
> fictitious domain method with boundaries specified by a levelset, I was not
> able to find a way to select boundary regions and include it in MeshIm as
> we do for conforming meshes. The problem is that MeshImData doesn't work
> with MeshIm produced with expressions other than 'all(a)'.
>
> I tried these
>
> 1. Because I wanted to add boundary to MeshIm object, I first tried
> mim = gf.MeshIm('levelset',mesh_ls,'inside(a)+boundary(a)',
> gf.Integ('IM_TRIANGLE(6)'))
>
> but the function does not accept expressions like 'inside(a)+boundary(a)'.
> 2. In case I use the following script
> mim = gf.MeshIm('levelset',mesh_ls,'inside(a)', gf.Integ('IM_TRIANGLE(6)'))
> mim.set_integ(4)
>
> This also failed at the line
> mim_data = gf.MeshImData(mim, -1, [2, 2])
> And even if I use 'all(a)' there seems to be no way to provide the boundary
> regions to Neumann term and to add_Dirichlet_condition_with_Nitsche_method
> function.
>
> 3. I also tried to separately generate MeshIm,mim =
> gf.MeshIm('levelset',mesh_ls,'inside(a)', gf.Integ('IM_TRIANGLE(6)'))
> mim_bound = gf.MeshIm('levelset',mesh_ls,'boundary(a)',
> gf.Integ('IM_TRIANGLE(6)'))
> but this also failed at mim_bound_data = gf.MeshImData(mim_bound, -1, [2,
> 2])
>
> 4. using cut_mesh() of MeshLevelSet
> These meshes are composed of rectangular elements and triangle elements (
> rectangular elements cut by a level set). And I was not able to define
> MeshIm that works with this composition.
>
> Am I missing something here?
>
> Respectfully yours.
>
>
> On Thu, May 21, 2020 at 8:21 PM Yves Renard <yves.renard@insa-lyon.fr>
> wrote:
>
> >
> > Dear Heungson Lee,
> >
> > There is a priori two known approaches for the used of Nitsche's methode
> > for plasticity. The easiest is to consider some additional Gauss points
> on
> > the boundary in order to have the plastic strain there as you mention, or
> > to extrapolate it from the internal Gauss points as it is mentionned for
> > instance in Seitz thesis
> > https://mediatum.ub.tum.de/doc/1454145/1454145.pdf
> >
> > For the first approach (additional Gauss points on the boundary) you can
> > normally specify a mesh region where you include both the domain and the
> > boundary where you want to prescribe the Dirichlet condition, which means
> > that the region will contain both some elements and some faces of
> elements.
> > Then you create the mim_data object with this mesh region.
> >
> >
> > Concerning the variants with nonzero theta parameter, this is indeed
> > complicated for nonlinear material laws, since the constitutive law has
> to
> > be derivated. This is much more complicated for plasticity where the
> > constitutive law is only piecewise regular and thus cannot be derivated
> > twice for the solve with Newton algorithm. So it seems that, unless the
> use
> > of a regularization, the only variant of Nitsche's method that can be use
> > for plasticity is the one with theta = 0.
> >
> > Best regards,
> >
> > Yves
> >
> >
> >
> > ----- Mail original -----
> > De: "Heungson Lee" <heungson.lee@gmail.com>
> > À: "getfem-users" <Getfem-users@nongnu.org>
> > Envoyé: Lundi 18 Mai 2020 09:07:18
> > Objet: Imposing Dirichlet B.C. using Nitsche's method in fictitious
> > domains for elastoplasticity.
> >
> > Dear getfem++ users. I am Heungson Lee.
> >
> >  I am trying to impose Dirichlet B.C. using Nitsche's method in
> fictitious
> > domains for elastoplasticity. For linear elastic problems, it just works
> > fine. But for elastoplastic problems such as Prandtl Reuss plasticity, I
> > was not able to make it work.
> >
> > I think the major problem is:
> >
> > 1. Stress tensor and its variation on the Dirichlet boundary.
> > -> Nitsche's method brick requires Neumann term on the boundary which
> uses
> > plastic strain. And the elastoplasticity brick requires plastic strain to
> > be stored in MeshImData. I was not able to find a way to compute plastic
> > strain on the boundary and store it in MeshImData for this purpose.
> >
> > These two problems might be not that important right now.
> >
> > 2. Nitsche's method brick does not recognize nonlinear variables for
> small
> > strain elastoplasticity brick.
> > -> So I temporarily modified the getfem source code and python interface
> > related to the function 'add_Dirichlet_condition_with_Nitsche_method' to
> > receive an additional boolean parameter from users which tells if the
> > problem is linear or nonlinear problem. It seems that this walk-around
> > works.
> >
> > 3. Fails to calculate the derivative of the Neumann term when theta (one
> of
> > Nitsche's method parameter) is not zero.
> > -> It seems that Neumann term includes the Heaviside function which is
> > originated from the yield function to distinguish whether it's in elastic
> > or plastic region. Inside 'add_Dirichlet_condition_with_Nitsche_method'
> > function, derivative of the Neumann term is symbolically evaluated, but
> it
> > fails because of the Heaviside function.
> >
> >
> > Please refer to the attached file to see what I am trying to do.
> >
> > If you have any idea how to make this work. please let me know. I would
> > really appreciate it.
> >
> > Respectfully yours.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]