Re: [Libmesh-users] p-refinement for Lagrange variables?

[David K. <dav...@ak...>]

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 <dav...@ak...>
wrote:

> On Fri, Mar 9, 2018 at 2:53 PM, Roy Stogner <roy...@ic...>
> 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
>