Remove VTKFileCollection

[KnutAM]

This PR removes VTKFileCollection introduced in #692, since it doesn't seem very flexible. This puts us back to the 0.3.14 behavior, having to specify the filename of each vtu (VTKGridFile) file manually, but allowing this behavior seems to be a reasonable low-level interface.

So far, only updated the quasi_incompressible_hyperelasticity.jl example to see the diff. Once I get some feedback, I will revert the others to (if we decide to go this way).

In the future, I would like to make this nicer, specifically I think that WriteVTK.jl should allow something like vtk = vtk_grid(pvd, grid, time) which automatically gives a filename for the vtk derived from the pvd. A similar syntax already exists there for the block files, vtk = vtk_grid(vtm, griddata). We could then mirror this, simply by

function VTKGridFile(f::WriteVTK.VTKFile, grid; kwargs...)
    coords, cls = create_vtk_griddata(grid)
    return VTKGridFile(WriteVTK.vtk_grid(f, coords, cls; kwargs...))
end

[lijas]

Like I wrote in #1004, I could not really use the VTKCollection wrapper in my code/solver, because it was not flexible enough (I need to use WriteVTK functions directly instead). Maybe other users find the current version of the wrapper convenient, and then we can keep it, but otherwise I would suggest reverting (i.e. merging this PR).

[KnutAM]

I would suggest reverting (i.e. merging this PR)

OK, if no one objects, I'll finish this up during the weekend and merge :)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.57%. Comparing base (81b987a) to head (55771a4).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1015      +/-   ##
==========================================
- Coverage   93.58%   93.57%   -0.02%     
==========================================
  Files          39       39              
  Lines        5895     5885      -10     
==========================================
- Hits         5517     5507      -10     
  Misses        378      378              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[fredrikekre]

PR looks good but just skimming through this, perhaps this should be open_vtk instead?

[termi-official]

What do you mean? That we have some function open_vtk which supportes the do syntax and which automatically figures out the correct format?

[fredrikekre]

I just mean it might look better to have something like

open_vtk("transient-heat-$step", dh) do vtk::VTKGridFile
    write_solution(vtk, dh, u)
    pvd[t] = vtk
end

instead of the current

VTKGridFile("transient-heat-$step", dh) do vtk::VTKGridFile
    write_solution(vtk, dh, u)
    pvd[t] = vtk
end

[termi-official]

But how does open_vtk figure out that it is a VTKGridFile (which maps for us to VTU) and not e.g. a multiblock file or structured mesh file?

[fredrikekre]

It doesn't figure it out, it always return it. Perhaps open_vtk(VTKBlockFile, ....) could be the interface or something.

[KnutAM]

PR looks good but just skimming through this, perhaps this should be open_vtk instead?

While I agree that it looks better, it also looks like it comes from WriteVTK? So in that case, perhaps don't export but make public? Having to write Ferrite.open_vtk is perhaps equally good as VTKGridFile, but looks nicer (and is even more clear that comes from Ferrite)?

Sharing some more thoughts below, to make those notes easier to find in the future.

[KnutAM]

Scope of VTKGridFile

But how does open_vtk figure out that it is a VTKGridFile (which maps for us to VTU) and not e.g. a multiblock file or structured mesh file?

It doesn't figure it out, it always return it. Perhaps open_vtk(VTKBlockFile, ....) could be the interface or something.

The VTKGridFile will only contain WriteVTK.DatasetFile (this was now enforced in #1014, was a mistake to have subtype of WriteVTK.VTKFile in the first place). So this would never give a multiblock file. My thought so far was to collect all export functionality in this type. In #867 my thought was to add required data inside the VTKGridFile, and have a kind of VTKExportData field or smth to cache the required grid transformations. These transformations get more complex for non-nodal vector interpolations (#798), as we would also need to output a higher fidelity mesh due to the nonlinearities of the interpolations.

The alternative path would be to have different types for the different cases, and have an AbstractVTKGridFile, with subtypes such as VTKGridFile, VTKDiscontinuousGridFile, and VTKDiscontinuousRefinedGridFile, but I fear coming up with sensible names gets tricky here. But the advantage with the abstract type could be that it is easier to extend. For this case, open_vtk makes sense.

WriteVTK's "Metadata formats"

With this PR, we now leave the handling of WriteVTK's "Metadata formats": vtk_multiblock and paraview_collection to WriteVTK itself. Then we only have to support passing these types through VTKGridFile, i.e.

function VTKGridFile(mb::WriteVTK.MultiblockFile, gridordh::AbstractGridOrDofHandler; kwargs...)
    coords, cls = create_vtk_griddata(gridordh)
    return VTKGridFile(WriteVTK.vtk_grid(mb, coords, cls; kwargs...))
end

or allowing adding a VTKGridFile to these types (as done in this PR), i.e.

function WriteVTK.collection_add_timestep(pvd::WriteVTK.CollectionFile, datfile::VTKGridFile, time::Real)
    WriteVTK.collection_add_timestep(pvd, datfile.vtk, time)
end

[lijas]

I think this PR looks good, and it keeps it relatively flexible to add more advanced stuff (DG export etc) when we need it in the future?