Bruno and Wolfgang, Thank you for the helpful suggestions--I had not thought of the block-diagonal linear system approach in particular, but I think it is a clever way to do what I had previously planned. I don't anticipate it being too expensive, even unordered, but if so, I will implement one of the other two approaches.
Corbin On Tuesday, March 22, 2022 at 10:38:32 PM UTC-4 Wolfgang Bangerth wrote: > On 3/21/22 16:47, Corbin Foucart wrote: > > > > I have an extruded mesh, and I would like to solve a finite element > problem > > separately on each 'column' as part of a larger finite element solve in > which > > all DoF are coupled through a discontinuous Galerkin scheme for an > elliptic > > equation--so multiply defined values on the boundaries of each column > are not > > a problem. > > > > * I already have the columns tagged by material ID > > * I imagine I should instantiate a list of new Triangulations, > DoFHandlers, > > and solver classes for each column and then map the solutions back to the > > original domain > > * *Is there a good way to extract a separate triangulation for each > column*? > > I was looking for something similar to extract_boundary_mesh but with a > > material_id > > > > Alternatively, it seems that I could assign the DoFs in the globally > coupled > > DoFHandler with DoFTools::get_subdomain_association(). *Would this be a > better > > way to set up each finite element problem by column?* It's unclear to me > if I > > could use that information to set up an independent linear system for > each > > subdomain. > > Corbyn, > you could go the way of creating triangulations, DoFHandlers, etc, for > each of > the columns. But you might also want to consider one of the following two > approaches: > > * Since you're already doing a DG approach, consider building your matrix > with > only the interface terms that correspond to the "bottom" and "top" of each > of > your cells. This means that you don't build any term that corresponds to > coupling columns to each other. Solving such a linear system then > corresponds > to solving all of the 1d problems at the same time. (I will note that such > a > matrix would also make for a good preconditioner; it corresponds to one of > the > directions one would solve for in the ADI method.) > > Conceptually, the matrix you obtain using the approach above is block > diagonal > where each block corresponds to one column. In practice, unless you do > something special, the matrix will not actually look block diagonal > because > the order of DoFs does not respect the column-by-column order. But it > wouldn't > be very difficult to implement a function that renumbers DoFs in such a > way > that they are numbered column by column, and then you would indeed have a > block diagonal matrix. > > * If you don't like this approach, you can create a mapping from the DoFs > of > each column to a column-local numbering from zero to n_dofs_per_column. > Instead of writing into global vectors and matrices in the method above > where > you omit the lateral face terms, you can translate writing into smaller > matrices and vectors that correspond to just one column. You can then > solve > the resulting linear system. The mapping of DoF indices then also allows > you > to get back at what the global index of these DoFs was. > > Best > W. > > -- > ------------------------------------------------------------------------ > Wolfgang Bangerth email: [email protected] > www: http://www.math.colostate.edu/~bangerth/ > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/3719937b-8b27-4f3c-a6be-705dfa3157e7n%40googlegroups.com.
