visualizing a finite element field: different piecewise constant values within cells

[Simon]

Dear all,

my triangulation is two-dimensional and consists of quadrilaterals, i.e. four vertices per cell. Each cell has four quadrature points (qp's).

I visualize the data at the quadrature points (in paraview) by producing a discontinuous finite element field which has as many DoFs as my triangulation has qp's, that is, the qp values are somehow assigned to the nodes.

In paraview (or other visualization programs) I would like to see four piecewice constant "colors" on every element: Sloppy speaking, each cell is divided into four subcells, and each of the subcells shows only one color which corresponds to the nodal value belonging to that subcell.

To this end, I think I need a finite element with piecewise constant shape functions. Each shape function is '1' at one quarter of the reference domain and '0' at the remaining three quarters.

Or is there an easier way to do this?

If not, I probably would have to write my own finite element class, given that such an element does not exist in dealii?

Thank you,

Simon

[Daniel Arndt]

Simon,

You could also refine once globally and then manually assign values. Implementing a new finite element class just for the sake of visualization sounds like much more work.

Best,

Daniel

--
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+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/0206f2a1-85cb-4970-9da8-d78de0bf6cc7n%40googlegroups.com.

[Wolfgang Bangerth]

On 8/26/22 10:31, Simon wrote:
>
>
> To this end, I think I need a finite element with piecewise constant
> shape functions. Each shape function is '1' at one quarter of the
> reference domain and '0' at the remaining three quarters.
> Or is there an easier way to do this?
> If not, I probably would have to write my own finite element class,
> given that such an element does not exist in dealii?

It is possible to implement such an element, but like Daniel already
said, it's maybe more work than you want to do.

I *assume* that your goal is to visualize the data at the actual
quadrature points, not on quarters of the elements. In that case, may I
suggest that you create a ParticleHandler with particles located at
quadrature points (for which there is already a generator function).
Each particle would then carry one "property" and you'd just have to
assign that property the value of your solution at that point (or
whatever other quantity you want visualized at this point). The final
step is to use the particles::DataOut class to output the information at
the particle locations.

Best
W.


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

[Simon Wiesheier]

"I *assume* that your goal is to visualize the data at the actual
quadrature points, not on quarters of the elements. In that case, may I
suggest that you create a ParticleHandler with particles located at
quadrature points (for which there is already a generator function).
Each particle would then carry one "property" and you'd just have to
assign that property the value of your solution at that point (or
whatever other quantity you want visualized at this point). The final
step is to use the particles::DataOut class to output the information at
the particle locations."

My idea was to actually plot the data at quarters of the elements (this includes the quadrature point, of course, but looks nicer that just a scatter plot -- in my opinion). 

I have to check how the output looks like when using particles::DataOut class. I just scanned the documentation of that class, which says:

'This class currently only supports witing the particle position and their ID and does not allow to write the properties attached to the particles'. 

Given that, I can not write the properties (thus the qp values) to  file, can I? 

Best 

Simon

--
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+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/2ede856e-6144-caba-4858-7525b03d55cc%40colostate.edu.

[Wolfgang Bangerth]

On 8/26/22 15:37, Simon Wiesheier wrote:
>
> My idea was to actually plot the data at quarters of the elements (this
> includes the quadrature point, of course, but looks nicer that just a
> scatter plot -- in my opinion).
> I have to check how the output looks like when using particles::DataOut
> class. I just scanned the documentation of that class, which says:
> 'This class currently only supports witing the particle position and
> their ID and does not allow to write the properties attached to the
> particles'.
>
> Given that, I can not write the properties (thus the qp values) to
> file, can I?

I am pretty sure that is no longer correct. Can you check in step-19 or
one of the other particle programs?

[Simon Wiesheier]

"I am pretty sure that is no longer correct. Can you check in step-19 or

one of the other particle programs?"

You are right. In step 19, for instance, also the properties assigned to the particles are written to a .vtu file.

" In that case, may I
suggest that you create a ParticleHandler with particles located at
quadrature points (for which there is already a generator function)."

I think you are referring to the function

Particles::Generators::quadrature_points(...).

I think there is no version of this function for non-parallel programs, i.e., where you do not have to pass

const std::vector< std::vector< BoundingBox< spacedim > > > & ,

is it?

Best

Simon

--
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+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/bbe96645-c161-8f5d-d872-eeb4d66acc42%40colostate.edu.

[Wolfgang Bangerth]

> "I am pretty sure that is no longer correct. Can you check in step-19 or
> one of the other particle programs?"
>
> You are right. In step 19, for instance, also the properties assigned to the
> particles are written to a .vtu file.

Thanks for checking. I've corrected the documentation.

> " In that case, may I
> suggest that you create a ParticleHandler with particles located at
> quadrature points (for which there is already a generator function)."
>
> I think you are referring to the function
> Particles::Generators::quadrature_points(...).
> I think there is no version of this function for non-parallel programs, i.e.,
> where you do not have to pass
> const std::vector< std::vector< BoundingBox

> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dealii.org%2Fcurrent%2Fdoxygen%2Fdeal.II%2FclassBoundingBox.html&data=05%7C01%7CWolfgang.Bangerth%40colostate.edu%7C2c2deb4a93174345496808da88f9598c%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637972901791289513%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5mXWR2a8OMRTpbPagwUp24Boyoiae8CfloTyuoYAbbg%3D&reserved=0><

> spacedim > > > & ,
> is it?

If you're working on a sequential triangulation, you just pass an (outer)
vector of length 1. (I believe at least.)

[Wolfgang Bangerth]

On 8/29/22 08:36, Simon Wiesheier wrote:
>
> DataOut<dim> data_out;
> data_out.add_data_vector(dof_handler_attached_to_tria1, sol_vector_tria1);
> data_out.add_data_vector(dof_handler_attached_to_tria2, sol_vector_tria2);
>
> In debug mode, this code will not run because tria1 and tria2 are different;
> I can only add 'sol_vector_tria' or ' sol_vector_tria2' to data_out,
> but not both of them together.
>
> That said, the only way is to use two seperate DataOut classes, is it?

I do not recall whether the functions that allow you to specify a separate
DoFHandler require these DoFHandler objects to use the same triangulation. But
knowing the implementation, it would make sense to me if they did. If that
were true, then the last question above would has "yes" as the answer.