Hi Roy, Regarding the thread below: I wasn't interested in adaptive p-refinement per se in this case, instead my motivation was to enable different variable orders in different regions of a mesh. One use-case for this is to have 2nd order beam elements and 1st order shell elements in the same mesh, for example. The beams and shells use the same variables (u,v,w,theta_x,theta_y,theta_z), but it'd be nice to vary the orders depending on whether we're in a beam subdomain or a shell subdomain.
It occurred to me that one way to do this more directly than with p-refinement would be to enable "subdomain based variable order", i.e. analogously to how we can specify whether a variable is active on a subdomain, we could also specify its order on a subdomain. Does that seem like a reasonable idea to you? And what do you think regarding the implementation, would it be a big undertaking? Best, David On Fri, Mar 9, 2018 at 3:02 PM, David Knezevic <david.kneze...@akselos.com> wrote: > On Fri, Mar 9, 2018 at 2:53 PM, Roy Stogner <royst...@ices.utexas.edu> > wrote: > >> >> On Fri, 9 Mar 2018, David Knezevic wrote: >> >> - If I were to look into adding a special case for non-uniform 1st >>> to 2nd order refinement for LAGRANGE variables, do you think this >>> would be of interest to include that in libMesh, or would it be too >>> specific to include? (I'd like to know if it's potentially of >>> broader interest before looking further into this.) >>> >> >> Uninteresting to me, but I try like mad to avoid writing >> LAGRANGE-specific code, so if I want C0 p refinement I just use >> HIERARCHIC. Others who've coded themselves too far into a >> LAGRANGE-only corner might disagree... but from what I've seen the >> very first way to screw up is to assume that every node has a dof for >> every variable, and any code like that will *still* be broken if those >> users have second-order geometric elements (so they can support p=2) >> but start with p=1. >> >> - How complex do you think it would be to add that special case? >>> >> >> Not very. I personally don't think it's worth it when you'd just end >> up stuck restricted by p<=2 anyways, but if anyone else disagrees I'd >> still happily merge their work. ;-) >> > > > OK, thanks for that info. I'll think some more about whether this is worth > working on or not for my use-case. > > Thanks, > David > ------------------------------------------------------------------------------ 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
