On Thu, Mar 1, 2018 at 11:46 AM, Roy Stogner <royst...@ices.utexas.edu> wrote:
> > On Thu, 1 Mar 2018, David Knezevic wrote: > > On Thu, Mar 1, 2018 at 10:50 AM, Roy Stogner <royst...@ices.utexas.edu> >> 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 ------------------------------------------------------------------------------ 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
