Re: [deal.II] Use a coarse grid solution as initial condition for a finer grid

[vachanpo...@gmail.com]

That brings a big simplification, at least when the aim is to just restart 
a simulation and not to map the solution onto some other grid.

Thanks for all the help!
On Tuesday, August 3, 2021 at 9:18:45 PM UTC+5:30 Wolfgang Bangerth wrote:

> On 8/3/21 8:38 AM, vachan potluri wrote:
> > 
> > I also have a simple related question. Can I skip all these steps if the 
> > triangulation, FE and number of processors of the solution being 
> transferred 
> > are kept constant? This is one special case which is like restarting a 
> > completed simulation. In this case (triangulation, FE, and processors 
> kept 
> > constant), is the partition and dof numbering always going out to be the 
> same? 
> > I am not doing any mesh refinement (either in dealii or outside).
> > 
> > If yes, then I suppose loading the solution transfer and deserializing 
> it will 
> > do the job without having to worry about "evaluating" the solution?
>
> Yes, you can reload solutions onto the same Triangulation and DoFHandler. 
> In 
> fact, the reload machinery even works if the number of processes is 
> different.
>
> 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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/f0cc1c0a-53b5-40c8-aff8-73ed2efb1212n%40googlegroups.com.

Re: [deal.II] Use a coarse grid solution as initial condition for a finer grid

[Wolfgang Bangerth]

On 8/3/21 8:38 AM, vachan potluri wrote:


I also have a simple related question. Can I skip all these steps if the 
triangulation, FE and number of processors of the solution being transferred 
are kept constant? This is one special case which is like restarting a 
completed simulation. In this case (triangulation, FE, and processors kept 
constant), is the partition and dof numbering always going out to be the same? 
I am not doing any mesh refinement (either in dealii or outside).


If yes, then I suppose loading the solution transfer and deserializing it will 
do the job without having to worry about "evaluating" the solution?


Yes, you can reload solutions onto the same Triangulation and DoFHandler. In 
fact, the reload machinery even works if the number of processes is different.


Best
 W.

--

Wolfgang Bangerth  email: bange...@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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/d11e4a8a-23eb-a66c-8efa-1e4d6a8f2b4b%40colostate.edu.

Re: [deal.II] Use a coarse grid solution as initial condition for a finer grid

[vachan potluri]

Peter,

Thanks very much for taking time and providing the resources. I will go
through them and get back if I have any more questions.

I also have a simple related question. Can I skip all these steps if the
triangulation, FE and number of processors of the solution being
transferred are kept constant? This is one special case which is like
restarting a completed simulation. In this case (triangulation, FE, and
processors kept constant), is the partition and dof numbering always going
out to be the same? I am not doing any mesh refinement (either in dealii or
outside).

If yes, then I suppose loading the solution transfer and deserializing it
will do the job without having to worry about "evaluating" the solution?

On Tue, 3 Aug 2021 at 14:09, 'peterrum' via deal.II User Group <
dealii@googlegroups.com> wrote:

> Hi Vachan,
>
> I don't think you need to use RPE plane. My guess is that you can use
> VectorTools::point_values(), which internally uses PRE (see
> https://github.com/dealii/dealii/blob/e413cbf8ac77606cf4a04e1e2fa75232c08533b4/include/deal.II/numerics/vector_tools_evaluate.h#L230-L343).
> Here you could collect the support points from the new DoFHandler, let
> VT::point_values() do the work and finally set the values at the support
> points.
>
> Further resources are:
> - the test folder
> https://github.com/dealii/dealii/tree/master/tests/remote_point_evaluation
> (in particular
> https://github.com/dealii/dealii/blob/master/tests/remote_point_evaluation/vector_tools_evaluate_at_points_01.cc;
> here, the solution is interpolated between non-matching grids)
> - the usage of RPE and VT::point_values() in DataOutResample (
> https://github.com/dealii/dealii/blob/master/source/numerics/data_out_resample.cc
> )
> - the usage in the two-phase solver adaflo (
> https://github.com/kronbichler/adaflo/blob/master/include/adaflo/sharp_interface_util.h
> )
>
> PM
>
> On Tuesday, 3 August 2021 at 09:03:02 UTC+2 vachanpo...@gmail.com wrote:
>
>> Dr. Wolfgang,
>>
>> Thank you for still taking interest in this thread :)
>>
>> This becomes a very difficult data transfer problem because you want to
>>> evaluate the solution at a point that the current process may know
>>> nothing
>>> about. In essence, you will have to ask all of the other processes about
>>> who
>>> owns a part of the mesh on which a given interpolation point is located,
>>> and
>>> then that process has to send you the value of the function at that
>>> point. You
>>> have to do that for all points. This is going to be an expensive
>>> operation.
>>> You might want to check out the Utilities::MPI::RemotePointEvaluation
>>> class in
>>> the latest (9.3) release for help with this.
>>
>> I understand that the approach I had mentioned is inefficient. I only
>> need to do this once, to start a simulation, so I thought it might be okay.
>>
>> I had a look at Utilities::MPI::RemotePointEvaluation. This is how I
>> think it can be used (correct me if wrong)
>>
>>1. Call reinit() with the dof locations, along with the corresponding
>>triangulation and mapping, where I want to evaluate FEFieldFunction (I
>>suppose the triangulation and mapping here are not of the 
>> FEFieldFunction?).
>>2. Call evaluate_and_process() by passing in the FEFieldFunction.
>>
>> I have a few questions.
>>
>>1. What is the "buffer" argument in evaluate_and_process()?
>>2. The documentation for this function says get_point_ptrs() must be
>>used to "process" the output in case the point-cell map is not one-one. I
>>will surely encounter such cases. How can I use the data returned by
>>get_point_ptrs() and how exactly should I "process" the output?
>>
>> I couldn't find this used in any examples. Any clarifications would be
>> greatly helpful.
>>
>> On Tue, 3 Aug 2021 at 04:47, Wolfgang Bangerth 
>> wrote:
>>
>>> On 7/5/21 11:04 PM, vachan potluri wrote:
>>> >
>>> > So is your fine mesh a refinement of the coarse one? If not, you
>>> may want to
>>> > look at FEFieldFunction.
>>> >
>>> > Yes, it is. But the "refinement" is done by the meshing
>>> software, outside
>>> > dealii. Is there any simplification possible in such a case?
>>>
>>> Not really. If deal.II has no knowledge about the relationship between
>>> cells
>>> on the two meshes, then it is in essence the interpolation from one
>>> unstructured grid to another unstructured grid.
>>>
>>>
>>> > Otherwise, I think FEFieldFunction would be a safe choice. Since I
>>> want to use
>>> > it with p::d::Triangulation, will setting all dofs as relevant do the
>>> job?
>>> > This way the partitioning can also be different.
>>>
>>> This becomes a very difficult data transfer problem because you want to
>>> evaluate the solution at a point that the current process may know
>>> nothing
>>> about. In essence, you will have to ask all of the other processes about
>>> who
>>> owns a part of the mesh on which a given interpolation point is located,
>>> and
>>> then that process has to send yo

Re: [deal.II] Use a coarse grid solution as initial condition for a finer grid

['peterrum' via deal.II User Group]

Hi Vachan,

I don't think you need to use RPE plane. My guess is that you can use 
VectorTools::point_values(), which internally uses PRE (see 
https://github.com/dealii/dealii/blob/e413cbf8ac77606cf4a04e1e2fa75232c08533b4/include/deal.II/numerics/vector_tools_evaluate.h#L230-L343).
 
Here you could collect the support points from the new DoFHandler, let 
VT::point_values() do the work and finally set the values at the support 
points.

Further resources are:
- the test 
folder 
https://github.com/dealii/dealii/tree/master/tests/remote_point_evaluation 
(in 
particular 
https://github.com/dealii/dealii/blob/master/tests/remote_point_evaluation/vector_tools_evaluate_at_points_01.cc;
 
here, the solution is interpolated between non-matching grids)
- the usage of RPE and VT::point_values() in 
DataOutResample 
(https://github.com/dealii/dealii/blob/master/source/numerics/data_out_resample.cc)
 
- the usage in the two-phase solver adaflo 
(https://github.com/kronbichler/adaflo/blob/master/include/adaflo/sharp_interface_util.h)

PM

On Tuesday, 3 August 2021 at 09:03:02 UTC+2 vachanpo...@gmail.com wrote:

> Dr. Wolfgang,
>
> Thank you for still taking interest in this thread :)
>
> This becomes a very difficult data transfer problem because you want to
>> evaluate the solution at a point that the current process may know nothing
>> about. In essence, you will have to ask all of the other processes about 
>> who
>> owns a part of the mesh on which a given interpolation point is located, 
>> and
>> then that process has to send you the value of the function at that 
>> point. You
>> have to do that for all points. This is going to be an expensive 
>> operation.
>> You might want to check out the Utilities::MPI::RemotePointEvaluation 
>> class in
>> the latest (9.3) release for help with this.
>
> I understand that the approach I had mentioned is inefficient. I only need 
> to do this once, to start a simulation, so I thought it might be okay.
>
> I had a look at Utilities::MPI::RemotePointEvaluation. This is how I 
> think it can be used (correct me if wrong)
>
>1. Call reinit() with the dof locations, along with the corresponding 
>triangulation and mapping, where I want to evaluate FEFieldFunction (I 
>suppose the triangulation and mapping here are not of the 
> FEFieldFunction?).
>2. Call evaluate_and_process() by passing in the FEFieldFunction.
>
> I have a few questions.
>
>1. What is the "buffer" argument in evaluate_and_process()?
>2. The documentation for this function says get_point_ptrs() must be 
>used to "process" the output in case the point-cell map is not one-one. I 
>will surely encounter such cases. How can I use the data returned by 
>get_point_ptrs() and how exactly should I "process" the output?
>
> I couldn't find this used in any examples. Any clarifications would be 
> greatly helpful.
>
> On Tue, 3 Aug 2021 at 04:47, Wolfgang Bangerth  
> wrote:
>
>> On 7/5/21 11:04 PM, vachan potluri wrote:
>> > 
>> > So is your fine mesh a refinement of the coarse one? If not, you 
>> may want to
>> > look at FEFieldFunction.
>> > 
>> > Yes, it is. But the "refinement" is done by the meshing 
>> software, outside 
>> > dealii. Is there any simplification possible in such a case?
>>
>> Not really. If deal.II has no knowledge about the relationship between 
>> cells 
>> on the two meshes, then it is in essence the interpolation from one 
>> unstructured grid to another unstructured grid.
>>
>>
>> > Otherwise, I think FEFieldFunction would be a safe choice. Since I want 
>> to use 
>> > it with p::d::Triangulation, will setting all dofs as relevant do the 
>> job? 
>> > This way the partitioning can also be different.
>>
>> This becomes a very difficult data transfer problem because you want to 
>> evaluate the solution at a point that the current process may know 
>> nothing 
>> about. In essence, you will have to ask all of the other processes about 
>> who 
>> owns a part of the mesh on which a given interpolation point is located, 
>> and 
>> then that process has to send you the value of the function at that 
>> point. You 
>> have to do that for all points. This is going to be an expensive 
>> operation.
>>
>> You might want to check out the Utilities::MPI::RemotePointEvaluation 
>> class in 
>> the latest (9.3) release for help with this.
>>
>> 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

Re: [deal.II] Use a coarse grid solution as initial condition for a finer grid

[vachan potluri]

Dr. Wolfgang,

Thank you for still taking interest in this thread :)

This becomes a very difficult data transfer problem because you want to
> evaluate the solution at a point that the current process may know nothing
> about. In essence, you will have to ask all of the other processes about
> who
> owns a part of the mesh on which a given interpolation point is located,
> and
> then that process has to send you the value of the function at that point.
> You
> have to do that for all points. This is going to be an expensive operation.
> You might want to check out the Utilities::MPI::RemotePointEvaluation
> class in
> the latest (9.3) release for help with this.

I understand that the approach I had mentioned is inefficient. I only need
to do this once, to start a simulation, so I thought it might be okay.

I had a look at Utilities::MPI::RemotePointEvaluation. This is how I think
it can be used (correct me if wrong)

   1. Call reinit() with the dof locations, along with the corresponding
   triangulation and mapping, where I want to evaluate FEFieldFunction (I
   suppose the triangulation and mapping here are not of the FEFieldFunction?).
   2. Call evaluate_and_process() by passing in the FEFieldFunction.

I have a few questions.

   1. What is the "buffer" argument in evaluate_and_process()?
   2. The documentation for this function says get_point_ptrs() must be
   used to "process" the output in case the point-cell map is not one-one. I
   will surely encounter such cases. How can I use the data returned by
   get_point_ptrs() and how exactly should I "process" the output?

I couldn't find this used in any examples. Any clarifications would be
greatly helpful.

On Tue, 3 Aug 2021 at 04:47, Wolfgang Bangerth 
wrote:

> On 7/5/21 11:04 PM, vachan potluri wrote:
> >
> > So is your fine mesh a refinement of the coarse one? If not, you may
> want to
> > look at FEFieldFunction.
> >
> > Yes, it is. But the "refinement" is done by the meshing
> software, outside
> > dealii. Is there any simplification possible in such a case?
>
> Not really. If deal.II has no knowledge about the relationship between
> cells
> on the two meshes, then it is in essence the interpolation from one
> unstructured grid to another unstructured grid.
>
>
> > Otherwise, I think FEFieldFunction would be a safe choice. Since I want
> to use
> > it with p::d::Triangulation, will setting all dofs as relevant do the
> job?
> > This way the partitioning can also be different.
>
> This becomes a very difficult data transfer problem because you want to
> evaluate the solution at a point that the current process may know nothing
> about. In essence, you will have to ask all of the other processes about
> who
> owns a part of the mesh on which a given interpolation point is located,
> and
> then that process has to send you the value of the function at that point.
> You
> have to do that for all points. This is going to be an expensive operation.
>
> You might want to check out the Utilities::MPI::RemotePointEvaluation
> class in
> the latest (9.3) release for help with this.
>
> Best
>   W.
>
>
> --
> 
> Wolfgang Bangerth  email: bange...@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 dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/61601d83-856e-dd27-dc78-3653bd45ec2f%40colostate.edu
> .
>

-- 
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/CALAVa_zoMRqDBmRLzGhVg7XiV3AOYmU9TJWGtxSARY0tU2t9sA%40mail.gmail.com.

Re: [deal.II] Use a coarse grid solution as initial condition for a finer grid

[Wolfgang Bangerth]

On 7/5/21 11:04 PM, vachan potluri wrote:


So is your fine mesh a refinement of the coarse one? If not, you may want to
look at FEFieldFunction.

Yes, it is. But the "refinement" is done by the meshing software, outside 
dealii. Is there any simplification possible in such a case?


Not really. If deal.II has no knowledge about the relationship between cells 
on the two meshes, then it is in essence the interpolation from one 
unstructured grid to another unstructured grid.



Otherwise, I think FEFieldFunction would be a safe choice. Since I want to use 
it with p::d::Triangulation, will setting all dofs as relevant do the job? 
This way the partitioning can also be different.


This becomes a very difficult data transfer problem because you want to 
evaluate the solution at a point that the current process may know nothing 
about. In essence, you will have to ask all of the other processes about who 
owns a part of the mesh on which a given interpolation point is located, and 
then that process has to send you the value of the function at that point. You 
have to do that for all points. This is going to be an expensive operation.


You might want to check out the Utilities::MPI::RemotePointEvaluation class in 
the latest (9.3) release for help with this.


Best
 W.


--

Wolfgang Bangerth  email: bange...@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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/61601d83-856e-dd27-dc78-3653bd45ec2f%40colostate.edu.

Re: [deal.II] Use a coarse grid solution as initial condition for a finer grid

[vachan potluri]

Dr. Wolfgang,

Thank you for the reply.

So is your fine mesh a refinement of the coarse one? If not, you may want to
> look at FEFieldFunction.

Yes, it is. But the "refinement" is done by the meshing software, outside
dealii. Is there any simplification possible in such a case?

Otherwise, I think FEFieldFunction would be a safe choice. Since I want to
use it with p::d::Triangulation, will setting all dofs as relevant do the
job? This way the partitioning can also be different.

You would have to attach manifolds to the triangulation object that is being
> reconstructed, before reconstruction.

Ok, noted.

Thank you.

-- 
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/CALAVa_zuoanwZ4kqrvE-2X%3DoKQ4wt2xhAkK3NEMptm2pJXwA3g%40mail.gmail.com.

Re: [deal.II] Use a coarse grid solution as initial condition for a finer grid

[Wolfgang Bangerth]

On 7/5/21 4:45 AM, vachanpo...@gmail.com wrote:


I have seen the answer here 
 that 
uses solution transfer to restart a simulation. I am thinking of doing 
something similar by first re-constructing solution vectors from the saved 
file and then using them along with dof locations (of the fine mesh) to set 
the initial condition for a fine mesh.


So is your fine mesh a refinement of the coarse one? If not, you may want to 
look at FEFieldFunction.



Is there any better way to accomplish what I desire? Also, will this approach 
work well for curved manifolds, or do I have to take additional steps to 
somehow reload the manifold data separately? Any help would be gladly appreciated.


You would have to attach manifolds to the triangulation object that is being 
reconstructed, before reconstruction.


Best
 W.



--

Wolfgang Bangerth  email: bange...@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 dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/6a185f67-417c-5ae7-3610-3adb86febe9f%40colostate.edu.