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
