vtkWrite support for Lagrangian data
Has vtkWrite support been implemented for Lagrangian? If not, could this be implemented ASAP. We have some cases that we want to animate, and using the old approach of writing the Lagrangian data only, then reconstructing, then converting to vtk is very unwieldy. We’d like to write the spray data in vtk format directly from a functionObject, and be able to select which associated spray properties (d, U, nP, etc.) get output.
Karl
Child items
0No child items are currently assigned. Use child items to break down this issue into smaller parts.
- !206v1806
Activity
@mark : could you please comment more on this ?
assigned to @mark
Hi Karl,
A major rework of the vtk output is planned (can discuss per email) - I'm not certain that a quick fix is immediate doable (or necessarily desirable). The current vtk output is extremely unwieldy in parallel and results in numerous individual files that are not easily processed anyhow. The future changes would include collecting onto the master and writing from there. Although parallel output for clouds is much easier than for the mesh, it is too large of a change so shortly before release.
For the current requirement (lagrangian output with specified fields) it should be possible to manage this with the new ParaView Catalyst interface with clouds. Assuming that you can get the appropriate ParaView version installed on the cluster. Indeed, with this interface it would be possible to generate the animations directly without writing the intermediate files. If this doesn't work, I would put this issue on the top of the list for post-release changes.
-
As a stop-gap (or a solution), you can also just generate VTK files with Catalyst. May be a bit of overkill if you just want vtk files, but would work.
Nonetheless, I would put this on the top for post-release changes. Please don't hesitate to ping me on it, to make sure it doesn't get forgotten.
mentioned in merge request !206 (merged)
-
Hi Karl,
I've added a
vtkCloudfunction object (merge request !206 (merged)) for addition into the next release. It should generally also work ok with the develop branch, but will not compile nicely with the current master (too many changes to wordRes and other bits).As mentioned in the commit, it streams everything in parallel, which allows you to create VTP files during the simulation and without any reconstructPar. It also generated a file-series (*.vtp.series), which many also be helpful for your situation.
@Prashant - I've tagged this for merging into the next release, so if you'd like to add this to your functionality tests. An example is in under lagrangian/coalChemistryFoam/simplifiedSiwek (parallel or serial).
Mark, trying this out now with v1806. The tutorial case for simplifiedSiwek seems to work. There seems to be a small issue though. In my own case, when I have the start-of-injection (SOI) set to some non-zero value, then the times prior to SOI don't create any *.vtp files (because there is no spray present yet). This is not very nice for the post-processing though, as it'd be better to have an empty/dummy file written for each time that spray is not present. Would this be possible? Otherwise, I'll need to introduce logic on my end to add dummy files for spray to match up with the other time-series files (iso-contours of flame surface, film thickness, etc.) for animation in ParaView/blender.
By Karl Meredith on 2018-07-11T02:04:57 (imported from GitLab project)
There seems to be an issue with restart in writing out the VTK/reactingCloud1.vtp.series file. Upon restart, this file gets stomped on and the previous one is overwritten. There needs to be a more elegant way to record the time series upon restart. Perhaps appending the *.series file with the restart time name, perhaps opening the original *.series file and appending data to it.
By Karl Meredith on 2018-09-18T12:21:59 (imported from GitLab project)
Another option would be to change the naming from using an integer to using a string that represents the output time. This would actually be more convenient. Then, we wouldn't even need the *.series file to translate between the two. For example, instead of reactingCloud1_00076283.vtp, the file name could simply be reactingCloud1_100.96.vtp Or, a second option would be to create time directories, like 100.96 and then store the individual vtp file in each directory.
By Karl Meredith on 2018-09-18T13:26:54 (imported from GitLab project)
The second option mentioned above (writing directories using the time name and then placing the *.vtp file in these directories) would be more consistent with the way that vtk files are written to postProcessing. In fact, the more I think about it the more it seeems like these vtp files should be written to the postProcessing directory, not the VTK directory.
By Karl Meredith on 2018-09-18T13:32:28 (imported from GitLab project)
-
I'd need to check with the kitware guys (via the discourse forum) if there are any restrictions/limitations with embedding a time value into the filename, and if the generic file series reader parses the values back out properly. I remember this either not working in the past, or working with questionable reliability. Would need to check. This is one of the reasons that they started with the additional json file though. The "useTimeName" option is currently commented out in vtkCloud.C since I didn't want to set more options into the world until needed (and tested).
Writing into a postProcessing directory is currently possible with the
directoryoption. Eg, something liketype vtkCloud; ... directory "<case>/postProcessing";This might be a reasonable (or better) place for the output to land by default, but I don't think that having an intermediate time directory within the postProcessing will help much (other than probably making it harder to find and load files). In either case, I think that the fundamental issue with restart remains. If there are files already output and the restart is from an earlier time instance, the initial write needs to discard these entries from the file series file, and perhaps remove the files from disk too.
-
Hi Karl, Apart from the restart issue, I also wanted to have a more general reconstruction method. So each cloud file (generated by vtkCloud) includes index and time value in its header. The attached script (perl) simply reconstructs vtp cloud file series from this information. This is not really intended to skirt this issue, but as an alternative that can be helpful on its own.
The script name may or may not be the best, can't specify a single cloud (it does all of them) but at least you can play with it a bit.
/mark
