Re: [Libmesh-users] Adaptative Mesh Refinement

[Derek G. <fri...@gm...>]

MOOSE has had this for a long time - you can see how we do it here:

https://github.com/idaholab/moose/blob/devel/framework/src/problems/FEProblemBase.C#L4651

Basically:

1.  Indicate/Mark
2.  Adapt
3.  Reinit and re-project
4.  Repeat

Derek

On Sun, Jul 15, 2018 at 1:55 PM Vinicius C. Reis <vin...@co...>
wrote:

> Hi Roy, my problem is pretty simple so the workaround you've suggested will
> work perfectly fine. For now, since I'm testing only simple geometries it
> might suffice to do all refinement before solving, so no post solve
> projection would even be necessary. If I have the chance to implement any
> complex geometry I'll disable the mesh-to-mesh projection and see how it
> goes. But I have to say, being able to restrict the boundary intersection
> to a subdomain would be a great easy in the computational effort required.
>
> As for the value of newly created elements, I'm not sure if initializing
> the new dofs to zero would be enough. At least in (not actually) my
> formulation, surrogate boundary, the new dofs will have to be mapped from
> the real boundary to the surrogated one. For steady problems, this is not a
> problem since the boundary conditions are taken into account in the
> variational statement itself. The challenge might be in transient and
> multiphysics problems in which there's a moving boundary (the actual
> interesting problems). Assuming zero previous values on time integration
> might not the right thing. But I have to admit I'm just guessing at this
> point.
>
> Anyways, a general solution I can think is to leave the user with the
> option of setting a function object (lambda function would be my
> preference) that will be used to evaluate the value of the newly inserted
> dofs.
>
> I hope this makes sense.
>
> Best regards,
> Vinícius Reis
>
> 2018-06-29 11:46 GMT-03:00 Roy Stogner <roy...@ic...>:
>
> >
> > On Thu, 28 Jun 2018, Roy Stogner wrote:
> >
> > On Tue, 12 Jun 2018, Vinicius C. Reis wrote:
> >>
> >>  Hi John, I pasted a somewhat smaller version of my code below. By
> playing
> >>>  with the refinement steps limit and the commented out init() and
> >>> reinit()
> >>>  lines you should be able to reproduce the two exceptions I got.
> >>>
> >>
> >> We could try to start treating that the way we currently treat element
> >> addition mid-simulation: all the newly created DoFs get coefficients
> >> initialized to zero.  I assume that's the behavior you're hoping for?
> >>
> >
> > Oh, just in case it helps: all my "how do we interpret this, how do we
> > implement this" confusion only applies to the projection step.  If
> > you're solving a steady problem then a quick-and-dirty workaround for
> > that case would be to just disable mesh-to-mesh projections and redo
> > the solve from scratch after each refinement step.
> > ---
> > Roy
> >
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Libmesh-users mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-users
>