Exporting a second order tensor field

[Kristoffer Carlsson]

Hello everyone,

Does anyone know if there is any simple way to export a tensor field? In my own code when I exported second order tensor fields to .vtu formats I could do this by simply exporting a DataArray with NumberOfComponents = 6 for a symmetric second order tensor field and 9 for an unsymmetric one. In deal.ii I don't see any good way to do this and instead I just export one scalar field for each component which is a bit awkward.

The simplest way would of course be if I could just give a std::vector<SymmetricTensor<2,dim>> or something but it is fine If I manually have to do some unrolling.

Any ideas?

Thanks for making deal.ii

// Kristoffer

[Wolfgang Bangerth]

Kristoffer,

This isn't currently implemented, but I think it would not actually be
terribly complicated to do so if you want to give it a try.

The fundamental approach would simply be to extend the
DataComponentInterpretation argument you pass to DataOut::add_vector()
function so that it can also represent symmetric and non-symmetric tensors.
This is the easy part, and you should be able to model what one needs to do
inside add_vector() based on what it currently already does to distinguish
between scalars and vectors.

The more complicated part is to teach the functions in namespace DataOutBase
what to do about tensor components. But you wouldn't have to do this for all
functions right away -- I see no reason why one couldn't do it for just one of
them at first, for example for the VTK or VTU writer.

I don't know exactly how the VTK/VTU format looks like for tensor data, and
since I'm somewhere at 11,000 meters, I also can't look it up. But I imagine
that there is a way to describe tensors in the same way as there is a way to
describe vectors.

It would indeed be interesting to see this implemented. It's been something
that we've had in mind for a long time but never had the manpower to do. If
you're willing to work on this, I'd be happy to provide advice where necessary!

Best
W.


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

[Kristoffer Carlsson]

Hello Wolfgang,

Yes, I am interesting on working towards this since exporting tensorial quantities is something I frequently have to do.

Since I am a new user of deal.II my knowledge of the code base is closed to nil so I have to do a bit of homework first.

A roadmap (similar to the one you presented) could be:

1.) Add support for symmetric / nonsymmetric second order tensors to DataComponentInterpretation. I have written code that exports tensors to VTK/VTU previously so if I limit support to those formats it should in theory not be too difficult.

2.) Add support for adding a std::vector of different type of tensors to add_vector. The reason I want this is that many of my tensor fields live in the quadrature points and are already in deal.ii::Tensor format. Having to unroll them into a big vector and passing that to add_vector together with a DataComponentInterpretation for every field I need to export seems backwards since the type information already exists from the start. The simplest way to implement this would probably be to just unroll the tensors into a vector and add the Interpretation that is determined from the type of the std::vector and pass it on to already existing functionality.

For initial communication would using this post be a good idea and then when I have something half working I could open a WIP PR on github?

I just want to take the opportunity to say I greatly enjoyed the video lectures for Math 676 that you uploaded. 

Best regards,

Kristoffer

[Wolfgang Bangerth]

Kristoffer,

> Yes, I am interesting on working towards this since exporting tensorial
> quantities is something I frequently have to do.

Great!

> Since I am a new user of deal.II my knowledge of the code base is closed to
> nil so I have to do a bit of homework first.
>
> A roadmap (similar to the one you presented) could be:
>
> 1.) Add support for symmetric / nonsymmetric second order tensors to
> DataComponentInterpretation. I have written code that exports tensors to
> VTK/VTU previously so if I limit support to those formats it should in theory
> not be too difficult.

Yes, you need patches that
- add symmetric/non-symmetric tensors to DataComponentInterpretation
- add a function to DataOutInterface similar to get_vector_data_ranges()
for each of the two kinds of tensors
- implement these functions in class DataOut_DoFData similar to how
this is handled for get_vector_data_ranges() in that class
- add arguments to DataOutBase::write_vtu and/or other functions in the
same class similar to the current vector_data_ranges() argument
- call these functions from DataOutInterface::write_vtu with the
added argument (you'll get compiler errors for all of the places you need
to adjust)
- implement handling tensors in DataOutBase::write_vtu/etc for tensor
arguments

All of these steps apart from the last one are really just pretty mechanical
and without great difficulty. The last one is the one that requires knowledge
of the VTU format.

When writing patches, you should start with the current development version
from github. Feel free to write a single commit for each of the steps above
and run them by me (or make a pull request out of them) if you'd like feedback
during the process.

> 2.) Add support for adding a std::vector of different type of tensors
> to add_vector. The reason I want this is that many of my tensor fields live in
> the quadrature points and are already in deal.ii::Tensor format. Having to
> unroll them into a big vector and passing that to add_vector together with a

> DataComponentInterpretation for every field I need to exportseems backwards
> since the type information already exists from the start.The simplest way to

> implement this would probably be to just unroll the tensors into a vector and

> add theInterpretation that is determined from the type of thestd::vector and

> pass it on to already existing functionality.

This is actually much more work than you probably realize, and doesn't really
fit into the current scheme of how things work. I would definitely leave this
for a later step.

The reason why it doesn't fit into the current setup is that all of the
DataOut functionality is geared toward outputting finite element *fields*
defined by piecewise polynomial spaces. This is, after all, what all
visualization programs show in a picture. But all you have is values that are
defined a individual points. So one way or another, you have to have a
procedure that gets you from individual points to a field, and that's of
course going to work exactly how you describe it above. One could think of
doing this automatically for a user, and that's the part that requires some
kind of thought and that I'd leave for a later time.

> For initial communication would using this post be a good idea and then when I
> have something half working I could open a WIP PR on github?

Pull requests have the advantage that we can comment on individual source
lines. So that would be my preference.

> I just want to take the opportunity to say I greatly enjoyed the video
> lectures for Math 676 that you uploaded.

Thanks! These videos have been quite a (positive) journey :-)

[Denis Davydov]

FYI, I am now looking into this issue https://github.com/dealii/dealii/pull/6807