Hi Everyone,

In case anyone ever follows this thread and needs to find the code 
associated with interpolate_boundary_values(), I found 
https://github.com/dealii/dealii/blob/master/include/deal.II/numerics/vector_tools.templates.h

I will report back on my implementation.

Thanks,
Ernesto

On Tuesday, 21 January 2020 09:45:28 UTC+2, Ernesto Ismail wrote:
>
> Hi Daniel and J-P,
>
> Thanks for your advice. I will try what you suggest.
>
> I feel like a bit of an idiot here, but I can't seem to find the source 
> code for the interpolate_boundary_values() function. I've rooted around 
> various source folders on Git and most of them don't contain much e.g. 
> https://github.com/dealii/dealii/blob/master/source/numerics/vector_tools_project.cc
>  I 
> think I'm just not familiar enough with how the project is laid out. Can 
> anyone point me in the right direction?
>
> Thanks,
> Ernesto
>
> On Wednesday, 15 January 2020 23:08:58 UTC+2, Jean-Paul Pelteret wrote:
>>
>> Hey Ernesto,
>>
>> I’ve used the approach outlined by Wolfgang and Daniel in my own work 
>> (multi physics problems, single DoFHandler with BC’s being transferred 
>> between a primary and secondary problem solved on subsets of the domain). 
>> Overall, it works really well so I’d back up their suggestion and recommend 
>> that you adopt it. Its mostly really just a question of finding common 
>> support points on the two surfaces, and seeing which DoF indices link up 
>> and transferring data from one solution vector to the other. I was looking 
>> though my code to see if I could share a snippet with you, but its so close 
>> in structure to the interpolate_boundary_values() (and still retains all of 
>> the original comments in the deal.II source :-) that its not really worth 
>> it. 
>>
>> Cheers,
>> J-P
>>
>> On 15 Jan 2020, at 07:48, Daniel Arndt <d.arn...@gmail.com> wrote:
>>
>> Ernesto,
>>
>> Imposing strong boundary conditions should not be overly difficult in 
>> this case. 
>> Just as Wolgang said you should have a look at 
>> interpolate_boundary_values() and replace the Function object evaluations 
>> on each cell by the function values given through
>> a FEValues object initialized for your first solution. Assuming that you 
>> are using interpolatory ansatz functions, this interpolation has to happen 
>> at the support points of your target finite element.
>> In particular, these support points should be the quadrature points for 
>> the FEValues object.
>>
>> Best,
>> Daniel
>>
>> Am Di., 14. Jan. 2020 um 01:50 Uhr schrieb Ernesto Ismail <
>> ernest...@gmail.com>:
>>
>>> 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 
>>>>                             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 dea...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/dealii/832bb83a-7e04-4243-9524-64db1bfc9345%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/dealii/832bb83a-7e04-4243-9524-64db1bfc9345%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>> -- 
>> 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 dea...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/CAOYDWbKY2%3D%2BBdWX4mh7guYEROFPT7mX8QR%3D4ED4KWymi_cD7Aw%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/dealii/CAOYDWbKY2%3D%2BBdWX4mh7guYEROFPT7mX8QR%3D4ED4KWymi_cD7Aw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>>
>>

-- 
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/55999209-1999-4399-bf1b-f48f7e67cc48%40googlegroups.com.

Reply via email to