Support parallel file formats

[amartinhuertas]

The purpose of this PR is to implement support in WriteVTK.jl of the so-called Parallel File Formats.

See https://vtk.org/wp-content/uploads/2015/04/file-formats.pdf, from page 16 till the end for details.

I have come up with an sketch of two possible workflows for generating such files. Both are leveraged from the pvtk_grid multi-method function, which can be seen as the parallel counterpart for vtk_grid in WriteVTK.jl. At present, pvtk_grid only has two methods, but the idea is that it is extended with the necessary methods to support the rest of formats.

Examples of both workflows can be found here and here, resp.

@fverdugo .... when you have some time, can you please take a look at the sketch and let me know what do you think, limitations, possible improvements, etc. Thanks !

[fverdugo]

Great! this makes almost all the work.

However, I would use a slighly different high-level API, for convenience and also to make sure that the file names within the pvtk file and the actual vtk files match.

Assume that we have defined this struct

struct PVTKLayout
  part::Int
  nparts::Int
  ismain::Bool
end
# By default part 1 is the main part
PVTKLayout(part,nparts) = PVTKLayout(part,nparts,part==1)

User code

# each worker/part calls this code:

# Define playout
pl = PVTKLayout(part,nparts)

# We call pvtk_grid in the same way we call vtk_grid in sequential runs.
# the only difference is that we pass a `VTKLayout` in the first argument.
# `args...` and `kwargs...` will be simply delegated to `vtk_grid`.
# This API is straightforward to use/remember if you know the  serial API
vtkfile = pvtk_grid(pl,args...;kwargs...)

# Add cell and point data as usual (this updates the underlying sequential vtk object)
vtkfile["Pressure"] = x
vtkfile["Processor"] = rand(2)

# Save the file (here comes all "magic")
# for workers it will create a sequential file with the a filename that appends the part id
# In addition, for ismain == true, we generate the pvtu file. 
# here file names will be consisten because the code is in charge to do it correctly, not the user
vtk_save(vtkfile)

What do you think?

[fverdugo]

We can also consider to write all the sequential files in a new folder

I.e.,

results.pvtu
results/
  results_1.vtu
  results_2.vtu
...

[amartinhuertas]

What do you think?

I think it is a nice idea. To have a composition relationship (i..e, a parallel data set file is composed of a serial data set) instead of an association relantionship as we have now. This let us to match the sequential API, among others. I will pursue your approach, and let you know.

[amartinhuertas]

However, I would use a slighly different high-level API, for convenience and also to make sure that the file names within the pvtk file and the actual vtk files match.

Hi @fverdugo, I already implemented this, including the storage of the pieces in a separate directory.

However, there are still issues to be solved byt the current API.

Among others, the fact that PImageData, PRectilinearGrid, and PStructuredGrid, have global and portion-wise attributes whose values have to be provided apart from the attributes of the local portions. For example, WholeExtent (global) and Extent (portion-wise), respectively.

An option is to pass them via optional keyword arguments to the pvtk_grid function. The issue is that, as far as I understand, the main part, i.e., the ones that generates the pvtu, requires to know the extent of all pieces. Should we pass these to pvtk_grid as well? (using a rank-2 array of number of parts X extent). In an actual parallel simulation, a gather operation must be performed before ... right?