Transfer of quadrature point history data after mesh refinement.

[Ali Karrech]

Dear All, 

I'm working on a code which is fairly similar to step-18, but it includes data storage at quadrature points because I want to describe damage and/or plasticity. My code requires the transfer of data after mesh refinement. Could you please let me know what is the easiest way to do that? Please note that I am aware of the Solution Transfer of DoF which doesn't help in this situation. 

Kind regards 

Ali

[Timo Heister]

Dear Ali,

is this using a distributed::parallel::Triangulation or a
dealii::Triangulation? Does this need to work with an MPI parallel
computation?

With a distributed::parallel::Triangulation there is
register_data_attach that allows you to add arbitrary data to each
cell that will be shipped to the correct processor. If you are running
using MPI but with a deal::Triangulation you know who the new owner
will be and you can send this information manually using MPI.

Alternatively, you could create a finite element space to represent
your quadrature point data (say a DGQ(k)) and then use
SolutionTransfer. Of course this will result in some kind of
interpolation happening on coarsening and refinement that might or
might not make sense in your case.

--
Timo Heister
http://www.math.clemson.edu/~heister/

[Ali Karrech]

Hi Timo, 

Thank you very for your response. The application uses distributed::parallel::triangulation. Does register_data_attach transfer the data from the integration points of a given cell to those of its children elements ? Do you mind sharing with me a small script showing how the regiser_data_attach can be used ?

Kind regards 

Ali

[Jean-Paul Pelteret]

Another idea for the discussion is the use of boost::mpi in conjunction with boost::serialization. I haven't yet implemented this myself (so it really is just an idea - maybe its not even feasible?), but my thought is that one can serialize and broadacst from each processor the position dependent data within the QPH, while on the other processors one creates new, uninitialised QPH data and initialises them with the data that they've just received. This effectively copies the whole data structure at each QP.

I hope that my explanation was sufficiently clear. Anyone have any comments on this concept?

[Denis Davydov]

After a small chat with Jean-Paul, these are some issues which came to mind:

1) parallelism issues; what was a single cell owned by a particular processor might end up being split among two completely different processors;

    i suppose each cell will now its parent and thus would still have access to some data attached to it.  

2) it might be easier to handle things on per cell basis. Imagine a heterogeneous continuum mechanics problem with different materials (say plastic and visco-elastic) which have absolutely different data stored in quadrature points; that would require a lot of tricks with FENothing and separate global (discontinuous) FE fields for each material. That is definitely doable, but i don't know if it easier or not.

3) projection to FE (cell-based) field could lead to non-physical values at new quadrature positions: Say, all quadrature points data is positive, still the resulting field might be negative at some points. Thus if  new QP are in this region - there is a problem; So it seems this should generally be a constrained least-square fit (on per cell basis), or something like this.

Maybe, one could think of some function or a set of object to do such kind of things and keep it in library. 

Try to keep it flexible so that it fits most of usage cases. 

What do you think?

Regards,

Denis.

[Timo Heister]

> Thank you very for your response. The application uses
> distributed::parallel::triangulation. Does register_data_attach transfer the
> data from the integration points of a given cell to those of its children
> elements ?

No, but it will tell you with CellStatus if the cell got coarsened or
refined. If you want automatic interpolation you should use
SolutionTransfer (which is just a wrapper around register_data_attach
that does interpolation).

> Do you mind sharing with me a small script showing how the
> regiser_data_attach can be used ?

Take a look at the code of parallel::distributed::SolutionTransfer.

[Wolfgang Bangerth]

On 05/26/2014 03:43 AM, Ali Karrech wrote:
> Hi Timo,

> Thank you very much. Your comments helped me. I though it's a good idea to
> share the solution that I adopted with other users. Apart from
> solution_transfer, I used FESystem and FE_DGQ to create a Finite element field
> which has the same number of degrees as my integration points. I used this new
> field (which I called history) to store my variable and recuperate them when I
> need it. It seems to work properly so far.

This is what I would have done as well. There is a function
FETools::compute_projection_from_quadrature_points_matrix that can help you
with this, in case you haven't already found it.

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@math.tamu.edu
www: http://www.math.tamu.edu/~bangerth/

[Denis Davydov]

Hi

On 14 Jun 2016, at 16:51, dealii...@gmail.com wrote:

Hi

I am solving a problem using Trilinos and parallel::distributed triangulation. It works well. I transfer solution data and old solution data during mesh refinement as follow,

  std::vector<const LA::MPI::BlockVector *> x(2);

  x[0] = &relevant_solution;

  x[1] = &solution_old;

  parallel::distributed::SolutionTransfer<dim, LA::MPI::BlockVector>

                    solution_transfer(dof_handler);

  solution_transfer.prepare_for_coarsening_and_refinement(x);

  triangulation.execute_coarsening_and_refinement();

  setup_system();

  LA::MPI::BlockVector tmp_v(partition);

  LA::MPI::BlockVector tmp_vv(partition);

  std::vector<LA::MPI::BlockVector *> tmp(2);

  tmp[0] = &solution;

  tmp[1] = &tmp_2;

  solution_transfer.interpolate(tmp);

  solution_old = tmp_2;

Now, I also want to transfer quadrature point's data to the new mesh based on the method explained at the end of step-18 in which we can use a discontinuous field that matches the values in the quadrature points. Now using this method, I can prepare a global field (history_field) and I want to transfer the history_field vector as usual using the SolutionTransfer class.

Can I attach the history_field with relevant_solution and solution_old during solution transfer method?

yes, you can. You would need to set up a separate DoFHandler and FE_DGQ etc for this.

Alternatively, you can use this class to achieve the same: https://www.dealii.org/developer/doxygen/deal.II/classparallel_1_1distributed_1_1ContinuousQuadratureDataTransfer.html

Or I must use two solution transfers, the first one for relevant_solution and solution using dof_handler and the second one for history_field using history_dof_handler? I can't understand this step and the relation between FE_DGQ for history field and FE_Q for the main problem during refinement.

The filed you solve for in FEM and the auxiliary field for transferring are not related.

Regards,

Denis.

-- 
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 a topic in the Google Groups "deal.II User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dealii/OSaxZJR19W8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dealii+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[dealii...@gmail.com]

Thank you. Is this class available in the release version 8.3.0?

I set separate dofhandler (history_dof_handler)  for FE_DGQ. I just confusing because the history_field vector has different size respect to the main solution vector and it also has different DoFHandler. I attached dof_handler defined for the main problem for FE_Q, to the solution_transfer, so I am confusing how we can use this solution_transfer which defined based on the dof_handler to transfer history_field?!

[Denis Davydov]

The class I mention is NOT available in 8.3.0, you would need to build from the git repository and have C++11 enabled.

As for the solution transfers, i would speculate that you need two different ones: one for the main field you solve for and another

for quadrature data.

Regards,

Denis.

[Wolfgang Bangerth]

On 06/14/2016 10:44 AM, Denis Davydov wrote:
> As for the solution transfers, i would speculate that you need two
> different ones: one for the main field you solve for and another
> for quadrature data.

Correct. You need to define a separate DoFHandler for the DG field to
which you project your quadrature point data. Then you need a separate
(second) SolutionTransfer object for the second DoFHandler.