What’s the current functionality for “subactive” elements? Right now, I am only 
interested in having the control mesh defined as constant monomial elements, 
maybe this special case could be easier to implement. I am not sure how a 
lookup table could be an efficient implementation if I want to refine the mesh 
multiple times. Are there any examples you can think of? 

I am thinking that I could have two different meshes being exact copies at the 
beginning, and then keep a siblings relationship between the elements. For each 
element in the state mesh, I will look for its sibling in the control mesh and 
see their children. Because the siblings are the same element, those children 
would be like the state mesh’s children. This is assuming I don’t do a 
different coordinates change on each mesh.

Miguel

-- 
 

On 5/24/17, 6:22 AM, "Roy Stogner" <royst...@ices.utexas.edu> wrote:

    
    On Tue, 23 May 2017, Salazar De Troya, Miguel wrote:
    
    > I want to use different discretization for the control and the state
    > variable in an optimization problem. Is this possible in libMesh?
    
    You can get uniformly different discretizations by using different
    finite element types, but for any truly independent adaptive
    refinement you'll need multiple Mesh objects.
    
    > I could imagine that having two different meshes would be expensive
    > because for each Gaussian point in the state mesh we would have to
    > find the corresponding element/s in the control mesh.
    
    Right.  Trying to do this on the fly with point locators would turn
    your O(N) assembly functions into O(N log N), so you'd want to keep a
    lookup table cached.
    
    > Maybe both meshes could be actually the same mesh data structure,
    > but they are defined by different depth levels. For instance, the
    > control elements could be children of a state element. Is this
    > feasible to implement?
    
    Yes, but not easily.  This was actually one of the goals behind the
    idea of "subactive" elements, and it would be possible to redefine the
    ancestor/active/subactive methods to take a "view number", while
    adding additional complexity to the refinement_flag settings to
    accomodate multiple views...
    
    But this would require changes in hundreds of places in libMesh.  I
    wouldn't recommend trying it until *after* you have multi-Mesh
    results, and even then only if you're sure you need more memory
    efficiency.
    ---
    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

Reply via email to