Plot3D reader problem with function file

Hello,

It seems the Plot3D reader is unable to correctly read function files. I have a Plot3D grid file grid.xyz (binary, multi-grid, with IBlanks, double precision and written in Fortran) and a function file volume.f containing 6 scalar fields. The two files open just fine on other software such as Tecplot. Any idea what could be going on?
paraview_p3d_bug.tar.gz (1.1 MB)

I confirm ParaView is unable to open the provided files.

If you are sure the files are valid, please open an issue: https://gitlab.kitware.com/paraview/paraview/-/issues

Thanks for the reply @mwestphal, I just created an issue:
https://gitlab.kitware.com/paraview/paraview/-/issues/22927

The grid file is written in Fortran unformatted format, meaning it includes byte counts before and after each record. The function file is written in C binary format (or Fortran with access=‘stream’), so it doesn’t have byte counts. Paraview’s reader needs it to be consistent. You can use the attached script to remove byte counts from the grid file.

python3 unformatted_to_cbinary.py grid.xyz grid_cbin.xyz

Then you should be able to open grid_cbin.xyz and volume.f.
unformatted_to_cbinary.py (429 Bytes)

1 Like

Thanks for the reply Eric, this indeed worked on my end. One feature that would be worthwhile to add is the ability to input several function files (one for each timestep) similar to what is possible for .q solution files. Is there a workaround for this?

You can use a “PLOT3D meta file.” This is a JSON file that specifies a sequence of PLOT3D files to load. A nice bonus of this is that you can provide names for the variables in your function file rather than Function0, Function1, etc. Create a file with a .p3d extension that looks like:

{
  "function-names": [
    "sweet",
    "sour",
    "salty",
    "bitter",
    "umami",
    "funky"
  ],
  "filenames": [
    {
      "time": 0.1,
      "xyz": "grid_cbin1.xyz",
      "function": "volume1.f"
    },
    {
      "time": 0.2,
      "xyz": "grid_cbin2.xyz",
      "function": "volume2.f"
    }
  ]
}

I’ve only ever used this for AMR cases where the grid was changing. If you have the same grid for all time steps, I assume you have to repeat the “xyz” entry. I don’t know if the reader is smart enough to avoid re-reading the grid when it hasn’t changed.

More documentation on the meta file format is available here. Most of the entries are optional.