Movie issue in paraview when using the latest code version

[elifo]

Description

Hello everyone,

I am trying to make a movie for a volume that contains multiple faults. I can generate VTK files with no problem, but when I open the VTK files in paraview, it looks very weird as if there are discontinuities in the medium:

Today I tested a previous version (detailed below) that I compile with exactly the same libraries, and it does not cause such a problem:

When I compared the two VTK files for the same instant, I noticed that the precision goes below 1e-38 in the latest version. I also verified that I get the same problem in the default example (splay faults) too.

Is there any trick that I am missing to avoid this issue in specfem3d or paraview?

Thanks!
Elif

The latest version: Running Git package version of the code: v4.0.0-93-gd2105bb
which is Git d2105bb
dating 2023-07-18 10:19:13 +0200

The older version: Git package version of the code: v2.0.2-3297-g770bb14
which is Git commit 770bb14
dating From Date: Mon Jul 5 06:07:42 2021 -0400

Affected SPECFEM3D version

d2105bb

Your software and hardware environment

cuda/11.2 openmpi/4.1.1_cuda-11.2

Reproduction steps

- I set the option to save volume movie files as True in Par_file
- I generate VTK files by converting bin files with xcombine_vol_data_vtk 
- I visualize VTK files with Paraview (5.11 and 5.10 tested) on MacBook Pro

OS

Linux

[danielpeter]

hi Elif,

the updated version is taking account of the fact that the VTK file uses float values to store these data values. Thus, it does an explicit rounding to single-precision before storing them into the vtk file. I assume that in your files, the 1.e-38 cut-off is the machine precision for rounding to single-precision values.

this should only matter if your data values you're trying to visualize are tiny. please check your simulation and source amplitude factors to see whether these small (wavefield?) values make physical sense or not. at the moment, it seems you're too close to numerical precision for floats.

It might also be worth checking if the VTU output looks better - however, it uses the same single-precision as the VTK output, so I doubt it will fix your issue.

[elifo]

thank you, Daniel!