Converting/viewing Vector<double> objects as Tensor<1, dim> objects

45 views
Skip to first unread message

Corbin Foucart

unread,
May 1, 2023, 6:15:33 PM5/1/23
to deal.II User Group
Hello everyone,

Is there an developer-intended way to view a Vector<double> object with dim entries as a Tensor<1, dim> object for ease of multiplication with other Tensor<1, dim> instances such as normal vectors?
I can do something like:

// dim = 3
Vector<double> vec({4,5,6});
ArrayView<double> view(&a[0], 3); 
Tensor<1, 3, double> tensor(view);

but from the documentation this seems to make a copy, and I wondered if there was a deal.ii way to "view" the Vector<double> as a Tensor object. This operation is the result of a numerical flux computation and is called many times during assembly. 

Thank you,
Corbin

Wolfgang Bangerth

unread,
May 1, 2023, 7:20:05 PM5/1/23
to dea...@googlegroups.com
Correct, this makes a copy. There really isn't a different way (in
deal.II): Tensor objects own their data, they are not "views", and so
they cannot avoid the copy. Of course, if you don't want to do the copy,
then you can always write out the tensor operation you are interested in
from the original vector elements by hand.

That said: It would greatly surprise me if the copying of elements is
limiting the speed of your program. Have you benchmarked this? Are you
sure that you aren't trying to optimize a part of the program that
doesn't actually need to be optimized?

Best
W.


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

Corbin Foucart

unread,
May 1, 2023, 8:20:32 PM5/1/23
to deal.II User Group
Thanks for the fast reply, Wolfgang!

I have done some preliminary benchmarking of the code and indeed this operation is not anywhere close to a bottleneck--I was asking primarily out of curiosity, as I'm refactoring the code and was considering what return type of an abstract representation of the flux makes sense in terms of class design. In light of your answer it seems that a view-based design doesn't make a lot of sense, and I might as well return a Tensor object directly, as that's the easiest for user code to work with.

Best,
Corbin

Wolfgang Bangerth

unread,
May 1, 2023, 11:26:59 PM5/1/23
to dea...@googlegroups.com
On 5/1/23 18:20, Corbin Foucart wrote:
>
> I have done some preliminary benchmarking of the code and indeed this
> operation is not anywhere close to a bottleneck--I was asking primarily out
> of curiosity, as I'm refactoring the code and was considering what return type
> of an abstract representation of the flux makes sense in terms of class
> design. In light of your answer it seems that a view-based design doesn't make
> a lot of sense, and I might as well return a Tensor object directly, as that's
> the easiest for user code to work with.

Indeed.

Tensors store their data as regular class members, rather than as pointers to
the heap. They are relatively small objects, and it is generally very cheap to
work with these kinds of objects because the compiler can either place them on
the stack or, oftentimes, even in registers. It is probably 2 orders more
expensive to operate on data that is dynamically allocated on the heap.
Reply all
Reply to author
Forward
0 new messages