WriteVTK.jl
WriteVTK.jl copied to clipboard
JuliaVTK
Generalize the package for read/write VTK
This package is really useful for my research and I wish I could completely forget about other file formats. The problem is that currently I can only save into disk, reading back into Julia is not possible.
Could you consider generalizing this package to a more general VTK.jl package? You definitely have the skills as well as the FileIO.jl generality at your disposal :blush:
What I don't really have is time. I have some research to do as well, you know? :-)
More seriously, that's definitely a good suggestion and I've thought about it. The VTK file format can vary a lot, but at least I can aim at reading the files that can be generated by WriteVTK.jl. I'll look into it, and I'll also consider integration with FileIO.
I am gonna close this issue since it is already in the plans. Maybe a new package name would be appropriate for handling read/write. I believe that Tim has used the name VTK.jl already, but maybe you could use VTKutils.jl or something.
Is this issue still of interest? I would need the feature and have some time in the next weeks to look into it.
It would be nice to have. To be honest I probably won't try to implement it myself anytime soon. It can be fairly complex since there's a lot of different ways a VTK file can be written...
Personally in these cases I prefer to work with HDF5 files, since they can be easily written and read back. Data can also be visualised the XDMF format.
So if you're motivated feel free to look into this issue, and I'd be glad to help and merge your code.
I'm using BSON files if I really need the data back in julia. My main usage is actually focused on the pvd files. I'd like to append newly generated VTK files e.g. after restarting a simulation. Would having only this feature be of interest for you, or is that to specific?
That's actually a great idea. It would definitely be interesting to append stuff to pvd files, and it shouldn't be too difficult to implement.
I'm reopening this because it would be good to add reading functionality.
We recently registered an initial version of ReadVTK.jl, a Julia package to read in VTK XML files. Its creation was motivated by us relying on @jipolanco's excellent WriteVTK.jl package to convert Trixi.jl's native output files to VTK for further postprocessing, and thus we needed a way to read the VTK files back in for CI testing purposes.
Please note that ReadVTK.jl has currently only a very limited feature set and there are many useful capabilities that are missing. Since our own requirements are currently all met (and due to time constraints), we do not have plans to develop it further at this point. However we are looking forward to community contributions, and we'll be happy to discuss strategies or review PRs if someone should be motivated to add new features or improve existing ones! We are also open for suggestions if someone is willing to take over the further development of ReadVTK.jl, or if someone is motivated to merge its reading capabilities into a joint read/write VTK package.
Thanks! This is great, and I'm sure it will be useful for other people. I will add a mention to ReadVTK.jl on WriteVTK's README.
In my opinion it makes sense to keep both packages separate, but if someone wants to merge the functionalities of both packages, it is fine for me as well, and I will be happy to help.
In my opinion it makes sense to keep both packages separate, but if someone wants to merge the functionalities of both packages, it is fine for me as well, and I will be happy to help.
Yeah, in general I would agree with you that having two separate packages usually keeps the overhead low and development speed higher. However, you have already set up some nice data structures like VTKCellType, Connectivity etc., from which I think the ReadVTK.jl package could also benefit. Maybe a middle ground could be to have a VTKBase.jl package with some common functionality on which both ReadVTK and WriteVTK could depend? But this is, of course, up to the person(s) actually implementing it :-)