Visualizing higher-order cells in 3D (step-67)

[David]

Hi there,

I'm running a 3D case using the 'write-higher-order-cells' flag and the 'write-vtu-in-parallel' function. The output writing is quite similar to the way step-67 handles it. However, the output of my 3D data sets looks a bit odd when running the case in parallel. I can reproduce it by running the 3D case (testcase 1) of step-67 in parallel and visualizing it:

I

The small deformations seem to be related to the partitioning (as shown in the lower figure). I'm using paraView version 5.9 (rc1), which should be recent enough in order to handle the higher-order cells.

Has anyone a similar problem or is it related to my paraView version?

Thanks in advance and best regards,
David

[Wolfgang Bangerth]

On 2/7/21 2:12 AM, 'David' via deal.II User Group wrote:
> ,
>
> I'm running a 3D case using the 'write-higher-order-cells' flag and the
> 'write-vtu-in-parallel' function. The output writing is quite similar to the
> way step-67 handles it. However, the output of my 3D data sets looks a bit odd
> when running the case in parallel.

David -- can you be more explicit about what "a bit odd" means in this case?
What are we looking at, and why do you think this is wrong?

Best
W.

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

[David]

Hi Wolfgang,

> David -- can you be more explicit about what "a bit odd" means in this case?

> What are we looking at, and why do you think this is wrong?

Certainly. We are looking at solution_000.vtu (zx-plane) of step-67, where I changed the testcase to 1 (cylinder in channel) and the dimension to 3D, computed on 4 cores.

What I mean by 'a bit odd' are in particular the wrinkles on the surface:

Running the same case in serial looks as follows.

The surface is smooth as usual. I would expect the visualization of the serial and the parallel case to be the same.

Best regards,
David

[David]

Hi Alexander,

> What is the minimum number of processes this happens? Can you reproduce it for 2 procs?

> Additionally, can the mesh size be reduced to a minimum (ideally a handful of cells, say 4-8)?

Yes, I can reproduce it on 2 procs and I can also simplify the mesh to a size of four cells on a rectangle. The problem vanishes if I select linear shape functions or zero nonlinear subdivisions in paraView (which is probably the same).

If I increase the nonlinear subdivision setting in paraVIew to four (as opposed to the default one), it looks as follows:

Hope this helps!

best regards,

David

Am Di., 9. Feb. 2021 um 23:04 Uhr schrieb Alexander <agra...@gmail.com>:

David

i believe that in order to proceed, one will have to simplify this further.

What is the minimum number of processes this happens? Can you reproduce it for 2 procs?

Additionally, can the mesh size be reduced to a minimum (ideally a handful of cells, say 4-8)?

Alexander

--
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 a topic in the Google Groups "deal.II User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dealii/O059tF8sy3o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dealii+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/aaf0032a-63d8-4709-b913-d0932809f3b3n%40googlegroups.com.

[Daniel Arndt]

David,

For me the most likely suspect without looking into the code at all is a missing update_ghost_values.

Best,

Daniel

Am Di., 9. Feb. 2021 um 17:04 Uhr schrieb Alexander <agra...@gmail.com>:

David

i believe that in order to proceed, one will have to simplify this further.

What is the minimum number of processes this happens? Can you reproduce it for 2 procs?

Additionally, can the mesh size be reduced to a minimum (ideally a handful of cells, say 4-8)?

Alexander

On Monday, February 8, 2021 at 10:20:35 AM UTC+1 daschn...@googlemail.com wrote:

--
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.

[Wolfgang Bangerth]

On 2/18/21 6:39 AM, 'David' via deal.II User Group wrote:
>
> the problem here is independent of any data set. So, you can also see it in
> paraView in the 'solid color' block. It seems to be an artificial curvature
> within the element.
> To my best knowledge it is not required to update any geometry related data.

I have to admit that I don't know how to address this because I don't know nor
use Paraview. As mentioned before, it would be useful to obtain the smallest
possible testcase that reproduces the problem -- minimal number of processors,
minimal number of cells.

Best
Wolfgang

[David]

Hi Wolfgang,

> I have to admit that I don't know how to address this because I don't know nor
> use Paraview. As mentioned before, it would be useful to obtain the smallest
> possible testcase that reproduces the problem -- minimal number of processors,
> minimal number of cells.

I already tried to answer this question above since Alexander asked the same question (not sure why his message has been deleted):

> Yes, I can reproduce it on 2 procs and I can also simplify the mesh to a size of four cells on a rectangle. The problem vanishes if I select linear shape functions or zero nonlinear subdivisions in paraView (which is probably the same).

> If I increase the nonlinear subdivision setting in paraVIew to four (as opposed to the default one), it looks as follows:

Does it help?

Regards,
David

[David]

Hi Peter,

>David, could you try out the following PR: https://github.com/dealii/dealii/pull/11784

I tried it and the PR doesn't fix it for me.

> Not sure if the issue there is related. If not, could you post a vtk/vtu file and I'll read it with my Paraview version.

Very good idea. I attached an affected file.

Can you reproduce the issue with your paraView version?

Regards,

David

Am Di., 23. Feb. 2021 um 16:08 Uhr schrieb peter rum <peterr...@gmail.com>:

David, could you try out the following PR: https://github.com/dealii/dealii/pull/11784

Not sure if the issue there is related. If not, could you post a vtk/vtu file and I'll read it with my Paraview version.

Peter

--
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 a topic in the Google Groups "deal.II User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dealii/O059tF8sy3o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dealii+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/1d13c760-0972-450f-a553-b26f2b2fb7den%40googlegroups.com.

[peter rum]

Thanks, David!

I have loaded in my local Paraview (v. 5.7.0) and I don't get any issues. You are using v. 5.9.0; so my best guess would be that Paraview has permuted the support points between the releases, what would be really annoying. Maybe you could check https://github.com/dealii/dealii/blob/e4171ed1729d09c842a6ee77c08bd7e669c5fd1c/source/base/data_out_base.cc#L774-L888 and compare it to the current implementation of VTK.

Peter