New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extra functionality of Tensor class #631

Merged
merged 1 commit into from Mar 2, 2015

Conversation

2 participants
@davydden
Member

davydden commented Mar 2, 2015

the two commits are currently part of https://github.com/dealii/dealii/pull/621/commits
Wolfang wanted at least one of them to be in separate PR, thus I create it.

Show outdated Hide outdated include/deal.II/base/tensor.h
inline
Number contract (const Tensor<1,dim,Number> &src1,
const Tensor<1,dim,Number> &src2)
const Tensor<1,dim,OtherNumber> &src2)

This comment has been minimized.

@bangerth

bangerth Mar 2, 2015

Member

The return type of this should now be typename ProductType<Number,OtherNumber>::type. Same in the operator*.

@bangerth

bangerth Mar 2, 2015

Member

The return type of this should now be typename ProductType<Number,OtherNumber>::type. Same in the operator*.

Show outdated Hide outdated include/deal.II/base/symmetric_tensor.h
* where the scalar is of the same base type and
* T is a symmetric tensor of double.
*/
void add(const Number &a, const SymmetricTensor<rank,dim,double> &p);

This comment has been minimized.

@bangerth

bangerth Mar 2, 2015

Member

Why only add SymmetricTensor<rank,dim,double> and not SymmetricTensor<rank,dim,Number>?

@bangerth

bangerth Mar 2, 2015

Member

Why only add SymmetricTensor<rank,dim,double> and not SymmetricTensor<rank,dim,Number>?

This comment has been minimized.

@davydden

davydden Mar 2, 2015

Member

that was used to add to the resulting tensor a number multiplied by the tensor object coming from the shape functions, thus double only

@davydden

davydden Mar 2, 2015

Member

that was used to add to the resulting tensor a number multiplied by the tensor object coming from the shape functions, thus double only

@bangerth

This comment has been minimized.

Show comment
Hide comment
@bangerth

bangerth Mar 2, 2015

Member

I don't recall the conversation about this. Where do you need the add functions?

Member

bangerth commented Mar 2, 2015

I don't recall the conversation about this. Where do you need the add functions?

@davydden

This comment has been minimized.

Show comment
Hide comment
@davydden

davydden Mar 2, 2015

Member

There was no conversation about the add function, but I use it heavily in the PR cited above, see davydden@2e30cc3

Member

davydden commented Mar 2, 2015

There was no conversation about the add function, but I use it heavily in the PR cited above, see davydden@2e30cc3

@davydden

This comment has been minimized.

Show comment
Hide comment
@davydden

davydden Mar 2, 2015

Member

I think add() shall be quicker than something like

derivatives[q_point] += value *
typename ProductType<Number,dealii::Tensor<order,spacedim> >::type(*shape_derivative_ptr++);

as it shall not require a temporary object.

Member

davydden commented Mar 2, 2015

I think add() shall be quicker than something like

derivatives[q_point] += value *
typename ProductType<Number,dealii::Tensor<order,spacedim> >::type(*shape_derivative_ptr++);

as it shall not require a temporary object.

@bangerth

This comment has been minimized.

Show comment
Hide comment
@bangerth

bangerth Mar 2, 2015

Member

This is for small objects with a handful of elements. The compiler will optimize all of this out -- let's not worry about these micro-optimizations unless we have evidence that they are necessary.

So I would vote to just leave the existing code of the form

derivatives[q_point] += value *
typename ProductType<Number,dealii::Tensor<order,spacedim> >::type(*shape_derivative_ptr++);

in place. There is a cost to adding member functions (as this discussion shows) and it doesn't seem worth it at this point.

Member

bangerth commented Mar 2, 2015

This is for small objects with a handful of elements. The compiler will optimize all of this out -- let's not worry about these micro-optimizations unless we have evidence that they are necessary.

So I would vote to just leave the existing code of the form

derivatives[q_point] += value *
typename ProductType<Number,dealii::Tensor<order,spacedim> >::type(*shape_derivative_ptr++);

in place. There is a cost to adding member functions (as this discussion shows) and it doesn't seem worth it at this point.

@davydden

This comment has been minimized.

Show comment
Hide comment
@davydden

davydden Mar 2, 2015

Member

ok

Member

davydden commented Mar 2, 2015

ok

@davydden

This comment has been minimized.

Show comment
Hide comment
@davydden

davydden Mar 2, 2015

Member

will check that it compiles...

Member

davydden commented Mar 2, 2015

will check that it compiles...

@davydden

This comment has been minimized.

Show comment
Hide comment
@davydden

davydden Mar 2, 2015

Member

builds fine.

Member

davydden commented Mar 2, 2015

builds fine.

@bangerth

This comment has been minimized.

Show comment
Hide comment
@bangerth

bangerth Mar 2, 2015

Member

Looks good.

Member

bangerth commented Mar 2, 2015

Looks good.

bangerth added a commit that referenced this pull request Mar 2, 2015

Merge pull request #631 from davydden/tensor
Extra functionality of Tensor class

@bangerth bangerth merged commit e71080c into dealii:master Mar 2, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@davydden

This comment has been minimized.

Show comment
Hide comment
@davydden

davydden Feb 21, 2016

Member

in reference to #2033

Member

davydden commented Feb 21, 2016

in reference to #2033

@davydden davydden deleted the davydden:tensor branch May 28, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment