Re: [Libmesh-users] Periodic boundaries for circular segment domains

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

On Thu, Mar 1, 2018 at 11:46 AM, Roy Stogner <roy...@ic...>
wrote:

>
> On Thu, 1 Mar 2018, David Knezevic wrote:
>
> On Thu, Mar 1, 2018 at 10:50 AM, Roy Stogner <roy...@ic...>
>> wrote:
>>
>>       If you have something vector or tensor valued, like e.g. a
>> *velocity*
>>       variable, and your formulation doesn't already use polar coordinates
>>       for the components of that variable, then you're in trouble if you
>>       want anything other than 0/90/180/270 degree rotations, because we
>>       don't currently have any way to specify a periodic BC for one
>> variable
>>       as a weighted sum of other variables.
>>
>>
>> Ah, OK. I was hoping to do cases other than 0/90/180/270 degree
>> rotations, and I'm considering elasticity, hence (u,v,w) displacement
>> variables.
>> As a result I think the current implementation won't work for me since
>> I'd need one variable to be a weighted sum of the others.
>>
>> I can look into adding this,
>>
>
> That would be great!
>
> any suggestions on where to start?
>>
>
> I think the right place to add this would be PeriodicBoundaryBase, but
> I'm not sure what the right way to add it would be.  Right now we have
> a set of variables associated with each periodic boundary, but to do
> this properly we'd also need the user to supply a matrix representing
> the transformation of those variables from one boundary to the other,
> and we'd need to cache the inverse of that matrix for use in a number
> of (often literally!) corner cases where we have to apply constraint
> equations to the "source" DoFs.
>
> compute_periodic_constraints() in fe_base.C is (other than the header
> and caching that matrix inverse) the only function you'd need to
> change, but it's 700 lines of confusing and easily-broken (especially
> in the DistributedMesh case IIRC) code.
>
> We'd probably need to use DenseMatrix to take the matrix inverse, but
> in the short run we'd want to have some semantics like "hold a
> unique_ptr<DenseMatrix>, and if that pointer is null then treat it
> like an identity matrix", to avoid suddenly adding an O(N_variables)
> complexity factor to compute_periodic_constraints.
>

OK, thanks for this input. I'll look into this when I get some time.

David