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
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Link issues together to show that they're related. Learn more.
Activity
- Developer
@mark : could you please comment more on this ?
- Mark OLESEN assigned to @mark
assigned to @mark
- Maintainer
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.
- Author Maintainer
Catalyst is a nice option, but I generate the animations with Blender, so I need the raw vtk files output. Would you please push this to the top of the post-release changes?
By Karl Meredith on 2018-06-12T14:43:33 (imported from GitLab project)
- Maintainer
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.
- Mark OLESEN mentioned in commit ae8eb1f2f3c594540853e03157f23b584ed3eb5c
mentioned in commit ae8eb1f2f3c594540853e03157f23b584ed3eb5c
- Mark OLESEN mentioned in merge request !206 (merged)
mentioned in merge request !206 (merged)
- Maintainer
Hi Karl,
I've added a
vtkCloud
function 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 OLESEN mentioned in commit ea580190b84013dc3e9d50dfd86c2f72440b5413
mentioned in commit ea580190b84013dc3e9d50dfd86c2f72440b5413
- Mark OLESEN mentioned in commit 454313da32e418352308610eaab71998963d417c
mentioned in commit 454313da32e418352308610eaab71998963d417c
- Maintainer
Now also included runTimePostProcessing support for these clouds and vtp files, some can now also generate basic images on the fly.
- Admin mentioned in commit 7c6e0087c6ee2e0133bf22b390bc78617d15b5fe
mentioned in commit 7c6e0087c6ee2e0133bf22b390bc78617d15b5fe
By Andrew Heather on 2018-06-18T12:22:37 (imported from GitLab project)
- Mark OLESEN mentioned in commit a899ecb707c0e0d40c12fbc11ebb3d678490c10b
mentioned in commit a899ecb707c0e0d40c12fbc11ebb3d678490c10b
- Author Maintainer
Thanks Mark. I'll have to try this out once we upgrade to the latest release. We are still on v1712.
By Karl Meredith on 2018-06-19T13:32:48 (imported from GitLab project)
- Mark OLESEN mentioned in commit 9db5942dc98256e38339e18919cc7ada9598e615
mentioned in commit 9db5942dc98256e38339e18919cc7ada9598e615
- Mark OLESEN closed
closed
- Author Maintainer
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)
- Admin reopened
reopened
By Karl Meredith on 2018-07-11T02:04:58 (imported from GitLab project)
- Maintainer
I agree. I think I would probably categorize this as a bug as well.
- Mark OLESEN closed via commit 64f7cf2f05676f56e09f12f38d66e73c07ba3828
closed via commit 64f7cf2f05676f56e09f12f38d66e73c07ba3828
- Mark OLESEN mentioned in commit 64f7cf2f05676f56e09f12f38d66e73c07ba3828
mentioned in commit 64f7cf2f05676f56e09f12f38d66e73c07ba3828
- Author Maintainer
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)
- Admin reopened
reopened
By Karl Meredith on 2018-09-18T12:21:59 (imported from GitLab project)
- Author Maintainer
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)
- Author Maintainer
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)
- Maintainer
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
directory
option. 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.
- Author Maintainer
Okay Mark. Makes sense. If you could at least get a fix for the restart issue that'd be great!
By Karl Meredith on 2018-09-18T18:20:52 (imported from GitLab project)
- Maintainer
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
- Author Maintainer
Thanks Mark. That perl script works great!
By Karl Meredith on 2018-09-19T17:40:59 (imported from GitLab project)
- Mark OLESEN mentioned in commit 24018fb207930107bd83d580de4996a9a9a2f0bf
mentioned in commit 24018fb207930107bd83d580de4996a9a9a2f0bf
- Mark OLESEN mentioned in commit 0859f9036746285b017b1400c8c29b8d465675e7
mentioned in commit 0859f9036746285b017b1400c8c29b8d465675e7
- Mark OLESEN mentioned in commit 0bb49bc475681cded374f72f10ef2b2f54f730a6
mentioned in commit 0bb49bc475681cded374f72f10ef2b2f54f730a6
- Mark OLESEN mentioned in commit b0adea3196d36e6485ab4ce03268396d81fcac57
mentioned in commit b0adea3196d36e6485ab4ce03268396d81fcac57
- Mark OLESEN mentioned in commit 3088809b14054e588b911eb78325c4f40b4ca0a4
mentioned in commit 3088809b14054e588b911eb78325c4f40b4ca0a4
- Mark OLESEN mentioned in commit bb8deab5527fc631d0f4ef7300b8138e622d6d90
mentioned in commit bb8deab5527fc631d0f4ef7300b8138e622d6d90
- Mark OLESEN mentioned in commit 28e9d4ebbb02a1b427382c20fcc41da9c597849d
mentioned in commit 28e9d4ebbb02a1b427382c20fcc41da9c597849d
- Mark OLESEN mentioned in commit a7f6b919bfa7f15a9f76e104990cb93076d736aa
mentioned in commit a7f6b919bfa7f15a9f76e104990cb93076d736aa
- Mark OLESEN mentioned in commit a9a9fadab563f74083b3dccb796062ecc475a269
mentioned in commit a9a9fadab563f74083b3dccb796062ecc475a269
- Mark OLESEN mentioned in commit 7aba8d5689c34215ae6331530e9d020b1817710c
mentioned in commit 7aba8d5689c34215ae6331530e9d020b1817710c
- Mark OLESEN mentioned in commit b1342e955577b31bafaedb731db5c4f9692ceff4
mentioned in commit b1342e955577b31bafaedb731db5c4f9692ceff4
- Mark OLESEN mentioned in commit 60d56fb40630d676ff5834d496810777ca9c2415
mentioned in commit 60d56fb40630d676ff5834d496810777ca9c2415
- Mark OLESEN mentioned in commit a7ee459331c976e478d5e451fea1ef2ab3ef65bd
mentioned in commit a7ee459331c976e478d5e451fea1ef2ab3ef65bd
- Mark OLESEN mentioned in commit 465effa1ee66bb3f22eb4d5ef3f56dce4ec6b4ae
mentioned in commit 465effa1ee66bb3f22eb4d5ef3f56dce4ec6b4ae
- Mark OLESEN mentioned in commit eb9f0a77b5c8818f5a4182431c17b97028cb4e25
mentioned in commit eb9f0a77b5c8818f5a4182431c17b97028cb4e25
- Mark OLESEN mentioned in commit 55ddc766fc7da7b034139e23227956e2ddf74f6c
mentioned in commit 55ddc766fc7da7b034139e23227956e2ddf74f6c
- Mark OLESEN mentioned in commit 3586a32bec061b12a16af9f96a2c040a6287a9ba
mentioned in commit 3586a32bec061b12a16af9f96a2c040a6287a9ba
- Mark OLESEN mentioned in commit 20f20e95548baf7226651b1b099696a5bd983ebc
mentioned in commit 20f20e95548baf7226651b1b099696a5bd983ebc
- Mark OLESEN closed
closed