# Visualisation postprocessor for spherical velocities

**URL:** <https://community.geodynamics.org/t/visualisation-postprocessor-for-spherical-velocities/1025>\
**Category:** ASPECT\
**Created:** [January 17, 2020, 12:34pm UTC](https://community.geodynamics.org/t/visualisation-postprocessor-for-spherical-velocities/1025 "2020-01-17T12:34:16Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![e-wiel](https://avatars.discourse-cdn.com/v4/letter/e/3be4f8/32.png) [@e-wiel](https://community.geodynamics.org/u/e-wiel)\
**Post date:** [January 17, 2020, 12:34pm UTC](https://community.geodynamics.org/t/visualisation-postprocessor-for-spherical-velocities/1025/1 "2020-01-17T12:34:16Z")

</div>

Hi all,  
Standard velocity visualisation output for paraview give results in full vectors (arrows) and separated in x,y,z-directions. However, regarding a spherical set-up (eg. spherical shell, chunk or sphere) I would like to visualise the velocity field also in separate radial and tangential velocities.

I was wondering if someone already has written a postprocessor that creates vtu-files containing these spherical velocities and is willing to share it?

Or if anyone could give me a heads-up regarding an existing postprocessor which I could try to modify to make it myself and, of course, any tips in how to do so.

Thanks in advance,  
Erik

---

<div class="post-metadata">

**Author:** ![gassmoeller](https://yyz2.discourse-cdn.com/flex036/user_avatar/community.geodynamics.org/gassmoeller/32/11_2.png) [@gassmoeller](https://community.geodynamics.org/u/gassmoeller)\
**Post date:** [January 17, 2020, 6:31pm UTC](https://community.geodynamics.org/t/visualisation-postprocessor-for-spherical-velocities/1025/2 "2020-01-17T18:31:09Z")

</div>

Hi Erik,  
I do not have such a postprocessor, but you are right it would be very useful to have one. If nobody has one available and if you want to create one on your own I would start with a copy of one of the existing postprocessors that creates a vector or tensor quantity, e.g. source/postprocess/visualization/gravity.cc or source/postprocess/visualization/shear\_stress.cc. The function `evaluate_vector_field` in these postprocessors is called once per cell whenever output is written, and the input parameter `input_data` contains the positions and velocities at every location we want to write output for in this cell. E.g. you can do `input_data.solution_values[q][this->introspection().component_indices.velocities[d]]` to access the velocity (as `Tensor<1,dim>`) at the q’th output vertex of that cell. Correspondingly `input_data.evaluation_points[q]` accesses the related positions (as `Point<dim>` in cartesian coordinates). You would then need to convert the velocities using the position into radius/longitude/latitude components and write those into the `computed_quantities` parameter. I think this would make a fine addition to the main code so please let us know if you do this or need any help.

Best,  
Rene

---

<div class="post-metadata">

**Author:** ![bangerth](https://yyz2.discourse-cdn.com/flex036/user_avatar/community.geodynamics.org/bangerth/32/52_2.png) [@bangerth](https://community.geodynamics.org/u/bangerth)\
**Post date:** [January 17, 2020, 10:47pm UTC](https://community.geodynamics.org/t/visualisation-postprocessor-for-spherical-velocities/1025/3 "2020-01-17T22:47:21Z")

</div>

Actually, if you’ve already extracted the velocity as in

```auto
  const Tensor<1,dim> velocity = ...

```

and assuming that you have also gotten the gravity vector somehow (there are examples for both of these things)

```auto
  const Tensor<1,dim> gravity = ...

```

then you can get the vertical (scalar) component of the velocity via

```auto
  const double vertical_velocity = (velocity * gravity) / gravity.norm();

```

and then the horizontal part of the velocity vector is simply

```auto
  const Tensor<1,dim> horizontal_velocity
    = velocity - vertical_velocity * gravity/gravity.norm();

```

This has the advantage that you don’t have to convert between different coordinate systems. It also works in 2d/3d, and in spherical/Cartesian coordinate systems. The only assumption is that the gravity vector indicates a good vertical direction – which is generally true.

Best  
W.

---

<div class="post-metadata">

**Author:** ![bangerth](https://yyz2.discourse-cdn.com/flex036/user_avatar/community.geodynamics.org/bangerth/32/52_2.png) [@bangerth](https://community.geodynamics.org/u/bangerth)\
**Post date:** [January 17, 2020, 10:49pm UTC](https://community.geodynamics.org/t/visualisation-postprocessor-for-spherical-velocities/1025/4 "2020-01-17T22:49:13Z")

</div>

The file `source/postprocess/visualization/vertical_heat_flux.cc` shows how to work around the issue if the gravity vector is zero.