Hi A related question (and hopefully not a distraction) as I'm also considering modelling (coherent and non-coherent) interfaces for coupled problems.
Markus's suggested using an interface between two domains. Nodes on the interface thus share the same nodal coordinates in the undeformed configuration but have independent dofs. Importantly, though they are not coupled in any way. This is a problem ( i think) as generally with interfaces one wants to evaluate the jump in fields across the interface. One could set up the link to determine the jump between the opposite faces using a link-topology matrix in a similar way that you determine the matching dofs for periodic boundary constraints, but this seems like a lot of work. Wolfgang's suggestion of using hp_collector and fe_nothing combinations makes sense as you also have double dof at the interface. How would one determine the jumps across the interface in this approach? I had in mind some scheme where the row of elements in the bulk directly on either side of the interface were DG while the rest of the bulk was CG. You can then extract the jump across the interface very easily (DG) but you need to do something to couple the DG and CG domains (perhaps a constraint matrix would work?). In the schematic below the + and - indicate the elements on either side of the interface. The bulk / interface are the DG elements on either side of the interface. * bulk - (CG) * * bulk / interface - (DG) * (interface) * bulk / interface + (DG) * bulk + (CG) * Many thanks Andrew On 04.02.2011, at 05:02, Wolfgang Bangerth wrote: > > Thomas, > >> The idea was to use a hp_collector like >> >> fe_1 ( FE_Q<dim>(1), 1, FE_Nothing<dim>(), 1 ), >> fe_2 ( FE_Nothing<dim>(), 1, FE_Q<dim>(1), 1 ), >> >> fe_collection.push_back (fe_1); >> fe_collection.push_back (fe_2); > > This is exactly what I always thought the FENothing should be used for! > > >> in this way we would have double degrees of freedom only on the interface, >> BUT we have the following problem: >> >> The violated condition was: >> domination != FiniteElementDomination::neither_element_dominates >> >> that makes sense in general, but not in my case, as I will never try to >> restrict my FE_Q to FE_Nothing. > > Right. I think that the check in this place is the right thing to do in > general, and that we should special case FE_Nothing somehow. > > Can you say where exactly this exception is produced? > > Best > W. > > ------------------------------------------------------------------------- > Wolfgang Bangerth email: [email protected] > www: http://www.math.tamu.edu/~bangerth/ > > _______________________________________________ > dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii _______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
