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 <viniciusr...@coc.ufrj.br> 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 <royst...@ices.utexas.edu>: > > > > > 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 > Libmesh-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libmesh-users > ------------------------------------------------------------------------------ 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 Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
