step-69 does not mark momentum as a vector for DataOut

[bangerth]

As a consequence, one can't currently visualize the momentum field as a vector field. I was going to say that this should be relatively easy to fix: One just needs to add a ComponentInterpretation array to ProblemDescription and pass that to data_out.add_vector(). But it's not so simple because we only have a single scalar DoFHandler and the various solution components are stored in separate vectors. There ought to be a way to merge this kind of information into one place, though, so that it can be output all at once as a vector.

[peterrum]

But it's not so simple because we only have a single scalar DoFHandler and the various solution components are stored in separate vectors. There ought to be a way to merge this kind of information into one place, though, so that it can be output all at once as a vector.

The would be nice. We heavily rely on scalar DoFHandler in combination with block vector.

Our best solution till now was: https://github.com/hpsint/hpsint/blob/377047cf7946e5ef33175c9ff02ea6c37c512cc5/include/pf-applications/numerics/data_out.h#L7-L49

(merging components as a post-processing step within get_nonscalar_data_ranges()).

FYI @vovannikov @mschreter

[bangerth]

On my way riding to work yesterday, I thought of pretty much the same solution as yours -- but maybe even simpler: DataOut::write_vtu() looks like this:

template <int dim, int spacedim>
void
DataOutInterface<dim, spacedim>::write_vtu(std::ostream &out) const
{
  DataOutBase::write_vtu(get_patches(),
                         get_dataset_names(),
                         get_nonscalar_data_ranges(),
                         vtk_flags,
                         out);
}

If that were the call in step-60, one could just copy the body of that function into step-69 and use data_out.get_patches() as argument -- for which we would need to make these functions public:, but that's a step I'd be willing to make. For the get_nonscalar_data_ranges(), one would then just substitute one's own set of arguments. That function has a quirky return type, though.

The problem is that step-69 doesn't just call write_vtu(), but write_vtu_with_pvtu_record() -- a much longer function that is not as pretty to duplicate...

[vovannikov]

But it's not so simple because we only have a single scalar DoFHandler and the various solution components are stored in separate vectors. There ought to be a way to merge this kind of information into one place, though, so that it can be output all at once as a vector.

The would be nice. We heavily rely on scalar DoFHandler in combination with block vector.

Our best solution till now was: https://github.com/hpsint/hpsint/blob/377047cf7946e5ef33175c9ff02ea6c37c512cc5/include/pf-applications/numerics/data_out.h#L7-L49

(merging components as a post-processing step within get_nonscalar_data_ranges()).

FYI @vovannikov @mschreter

The idea of such approach was that if the number of components having the same name is dim or dim*dim then they are automatically merged into a vector or a tensor, respectively. This behavior could be also made compulsory via a flag if we would like to add this feature to deal.II's DataOut. And it works for any write_* function. I can prepare a PR is this solution is OK.

[tamiko]

I very much like the idea of changing DataOut so that it merges components with the same name into a vector (including a toggle that controls this behavior).

I wouldn't even base it on dim, or dim*dim. For example, you could have a two-component flux in one or three space dimensions that you want to represent as a vector.

/Edit: @bangerth This had been a long-standing pet peeve of mine - the fact that we cannot easily mark vectors in DataOut for the case when we have a "scalar" DoFHandler.

[tjhei]

The idea of such approach was that if the number of components having the same name is dim or dim*dim then they are automatically merged into a vector or a tensor, respectively.

I like this idea and I don't think we need an option for that but we can always unconditionally do this. What else do you expect if you have several components with the same name? You can certainly not represent this in any of the file formats.

[peterrum]

The idea of such approach was that if the number of components having the same name is dim or dim*dim then they are automatically merged into a vector or a tensor, respectively.

I like this idea and I don't think we need an option for that but we can always unconditionally do this. What else do you expect if you have several components with the same name? You can certainly not represent this in any of the file formats.

@vovannikov Could you open a PR with the changes we did in our code?

[vovannikov]

@vovannikov Could you open a PR with the changes we did in our code?

Yep, sure.