That’s not the right way to do it, you should have something along the lines:
unsigned int number_of_values () const
{
return 1 + <whatever_is_the_number_of_elements_in_a_matrix>;
}
virtual void pack_values(std::vector<double> &values) const
{
values[0] = psi;
values[1] = B[0][0];
values[2] = B[0][1];
...
}
and same for unpack but other way around (setting internal data from an input
vector).
The point is that we can not guess what type of data users are storing. But we
don’t really need to.
We only need to know how many independent scalar fields would the data
correspond do.
That’s what is returned by number_of_values(). The same resasons pack_values()
are NOT called pack_scalars() etc
Regards,
Denis.
> On 10 Apr 2017, at 11:30, 'Seyed Ali Mohseni' via deal.II User Group
> <dealii@googlegroups.com> wrote:
>
> Dear Denis Davydov,
>
> I am trying to implement the pack_values() and unpack_values() functions for
> a FullMatrix<double>, but the function itself in quadrature_point_data.h is
> defined using a vector of double values only. Nevertheless, my initial
> approach would be the following:
>
> struct MyQData: public TransferableQuadraturePointData
> {
> double psi;
> FullMatrix<double> B;
>
> unsigned int number_of_values () const
> {
> return 2;
> }
>
> virtual void pack_values (std::vector<double> &scalars) const
> {
> Assert(scalars.size()==1, ExcInternalError());
> scalars[0] = psi;
> }
>
> virtual void pack_values (std::vector<FullMatrix<double>> &matrices)
> const
> {
> Assert(scalars.size()==1, ExcInternalError());
> matrices[0] = B;
> }
>
> virtual void unpack_values (const std::vector<double> &scalars)
> {
> Assert(scalars.size() ==1, ExcInternalError());
> psi = scalars[0];
> }
>
> virtual void unpack_values (const std::vector<FullMatrix<double>>
> &matrices)
> {
> Assert(matrices.size() ==1, ExcInternalError());
> B = matrices[0];
> }
> };
>
> Is the above correct? Will it work during refinement? I checked it without
> refinement and it seems to give me correct values at each Gauss point after
> data storage.
>
>
> Note that this may not be what you want in the context of crack propagation
> because what we do to transfer is assume that the quadrature data is
> continuous across the element (thus the name
> ContinuousQuadratureDataTransfer).
>
> Yes, but what choice do I have? Is there another computationally efficient
> approach?
> This means probably that the PointHistory function data storage based on
> step-18 has the same drawback for discontinuous problems, am I right?
>
> I would be gladly willing to implement the
> DiscontinuousQuadratureDataTransfer function, if it is somehow possible to
> accomplish in deal.II. I am pretty sure it will be beneficial for others also
> in many ways. ;)
>
> Kind regards,
> S. A. Mohseni
>
> --
> The deal.II project is located at http://www.dealii.org/
> <http://www.dealii.org/>
> For mailing list/forum options, see
> https://groups.google.com/d/forum/dealii?hl=en
> <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/rgv4YGx5VJE/unsubscribe
> <https://groups.google.com/d/topic/dealii/rgv4YGx5VJE/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com
> <mailto:dealii+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
--
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.
For more options, visit https://groups.google.com/d/optout.
