Dear Prof. Bangerth, Thank you for your reply.
I would ideally have liked to impose the boundary conditions strongly but it looks like doing so will not be straight-forward. I will do some investigations into applying the boundary conditions weakly and attempt that first. One approach I had tried was to use Lobatto quadrature and use a quadrature point history data structure to transfer the solution at the boundary. The problem with this approach was that the differing element types lead to some strange behaviours along the boundary. Thanks again, Ernesto On Thursday, 9 January 2020 23:43:27 UTC+2, Wolfgang Bangerth wrote: > > > Ernesto, > > > I am currently working with a staggered coupled system where I am > solving > > several finite element problems in sequence. Up until now my boundary > > conditions have been fairly straightforward and I've been able to get > > meaningful results from my work. > > > > The finite element schemes I use for each step are fairly different, > with some > > being discontinuous and of varying orders. > > > > I am now in a position where I need to use the solution of one of my > steps as > > the boundary condition for the next (I actually need to combine two of > them > > with a simple arithmetic function, but baby steps for now). I presume I > need > > to use some sort of projection to achieve this, but I'm not exactly sure > how > > to go about it. I thought to try and use the project_boundary_values() > > function to do what I need, but I am unsure how I would structure > > the boundary_functions argument. > > Do you need to enforce these boundary conditions strongly? If you can > enforce > them weakly, then the solution of one problem only enters the weak form of > another problem (in that case through a boundary integral) and that is > really > not very different from the way we do this in other problems where we have > multiple DoFHandlers -- e.g., in step-31. (Though my usual advice still > holds > true that I think everything becomes simpler if you pack everything into > one > DoFHandler). > > It gets more complicated if you want to impose strong boundary conditions. > You've already found the FEFieldFunction function, but it's complicated > and > slow. A simpler way would be if you looked at the implementation of the > interpolate_boundary_values() function and identified where it is asking > the > Function object for its values. That's the place where you'd need to > somehow > combine your existing solutions into something else and turn that into a > constraint. > > Best > W. > > -- > ------------------------------------------------------------------------ > Wolfgang Bangerth email: bang...@colostate.edu > <javascript:> > 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 dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/832bb83a-7e04-4243-9524-64db1bfc9345%40googlegroups.com.
