Re: [vmtk-users] Mapping and Patching Data

[Luca A. <luc...@gm...>]

Hi Evan,

On Mar 1, 2013, at 7:51 PM, Evan Kao wrote:

> Hello Luca,
> 
> Thanks for the quick response and help.  Using subdivisions seemed to have fixed the problem of missing patches (I did end up having to use the AbscissaMetric array as the longitudinal axis in vmtkbranchpatching as opposed to StretchedMapping due to issues with Python crashing when trying to compute the bifurcation reference systems from the subdivided surface, but this is probably more of an issue with the system I'm using than one with vmtk).

It's possible, but try to use subdivision after the mapping and prior to patching. You'll still see the little hole at the bifurcation center, which shouldn't be that big of a deal (although I don't know your exact application), but you'll be able to use StretchedMapping for the patching, which results in a more regular coverage of the surface.

> Why nonsense? The data is all there.
> 
> To clarify, I don't think the data is nonsense, but when I provide the flag -patcheddatafile xxx.vti/png for vmtkbranchpatching, it doesn't seems to visualize the data correctly, as seen in the image files I attached in the previous e-mail (I just see a gray rectangle).  But it's probably not a big deal, since I can just export the raw data and visualize it however I want, as you suggested.

You are right, there's lots of room for improvement regarding visualization in patching (and in general). Thanks for the suggestion!

Luca

> Thanks,
> Evan Kao
> 
> On Fri, Mar 1, 2013 at 4:01 AM, Luca Antiga <luc...@gm...> wrote:
> Hi Evan,
> 
> On Mar 1, 2013, at 1:59 AM, Evan Kao wrote:
> 
>> Hello group,
>> 
>> I am still having some trouble with mapping and patching data.  When I created the patched surface and viewed it, I noticed that some patches of the surface were missing (see: missingpatches.png, any011_wss_clipped_patching.vtp).  Inspecting the surfaces generated from the previous steps, it seems small pieces of the surface is cut out at the bifurcation (surface after splitting.png, any011_wss_clipped.vtp), although I don't know if that is related to the problem in the surface patching step, or simply a result of the way the centerlines were formed (centerlines,png, any011_wss_cl.vtp).
> 
> Both issues are related to the fact that the surface is probably too coarse in some regions relative to the size of the patch. Also, due to the way clipping is performed, you can have a small missing triangle at the bifurcation, whose size decreases with the increase in the surface density. This is due to the linear interpolation of the cuts on top of the triangulation.
> A workaround in these cases is to pass the surface through 
> vmtksurfacesubdivision -method butterfly -subdivisions 1 
> prior to patching.
> 
>> The image files generated with the patched data (both .vti and .png) were nonsense (vmtkimageviewer of patcheddata.png, any011_wss_clipped_patching.png, any011_wss_clipped_patching.vti).
> 
> Why nonsense? The data is all there. It's one image in which all three branches are stored contiguously, this way:
> 
> SECTORS x (SLAB_A + SLAB_B + SLAB_C)
> 
> I attach a couple of screenshots that demonstrate it, obtained using Paraview.
> 
> It's probably not the most practical way to plot the data, though. I suggest you export the vtp patched data this way:
> 
> vmtksurfacewriter -ifile any011_wss_clipped_patching.vtp -ofile foo.dat -celldata 
> 
> which will generate a csv-like file in which lines are individual patches, each with its wss value, groupid, slab and sector. 
> This will allow you to generate plots of the unwrapped surface for your needs using any general purpose plotting software by plotting sector on x, slab on y and wss as the color.
> 
> Hope this helps
> 
> Luca
> 
>> To simplify the issue, I also tried mapping and patching only one branch segment (the aneurysm) by cutting out the other branches with vmtksurfaceclipper before any sort of branch extraction and splitting.  There didn't seem to be any issues with missing patches this time around, but the .png file also failed to provide the expected results (the patched 3D surface, and the "unwrapped" 2D surface).
>> 
>> Any idea on what's going wrong?
>> 
>> Thanks,
>> Evan Kao
>> 
> 
> 
> 
> 
> 
>> On Fri, Feb 22, 2013 at 3:54 PM, Evan Kao <to...@gm...> wrote:
>> Thanks, Arjan.  That was an extremely helpful explanation.
>> 
>> 
>> On Wed, Feb 20, 2013 at 4:40 PM, Arjan Geers <aj...@gm...> wrote:
>> Hi Evan, 
>> 
>> VTK polydata files store the location of points and information on how these points are connected to form cells. Additionally, they can store scalars and vectors at each point or cell. So, indeed, you want the WSS field already included in the surface file before performing any vmtkbranch* operations. 
>> 
>> Hopefully, you can export from your CFD solver an ASCII file similar to surface.tec (attached). It contains x,y,z-coordinates of each point, the wss magnitude at each point, and connectivity information. When opening this surface with vmtksurfacereader, VMTK converts it into a VTK polydata, which can then be written with vmtksurfacewriter (see surface.vtp attached). To check what VMTK actually does when converting the ASCII file, go to the function 'ReadTecplotSurfaceFile' in vmtksurfacereader.py. This should provide you with some hints on how to convert your own format to VTP. 
>> 
>> Hope this helps, 
>> 
>> Arjan
>> 
>> PS: Since the commercial CFD solver Ansys-CFX is quite widely used, the attached script cfx2vtp.py (variation on above-mentioned 'ReadTecplotSurfaceFile') might be useful to some reading this email. Converting surface.csv (attached) should give surface.vtp again.
>> 
>> 
>> On Wed, Feb 20, 2013 at 9:40 PM, Evan Kao <to...@gm...> wrote:
>> Hello,
>> 
>> I am confused about some of the details regarding the matching and patching of data in the tutorial.  Specifically, at what stage in the process are we supposed to import the simulation data into vmtk, and how?  For instance, in the tutorial, are the WSS and OSI distributions already part of the surface file ("aorta.vtp") before any processing occurs?  It doesn't seem like there are any ways to import data in any of the vmtkbranchmetrics, vmtkbranchmapping, or vmtkbranchpatching functions.  And what form does the data have to be in?  It should be pretty easy to export nodal or cell CFD data as an array, but how would we incorporate that into vmtk?
>> 
>> Thanks for your time,
>> Evan Kao
>> 
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb
>> _______________________________________________
>> vmtk-users mailing list
>> vmt...@li...
>> https://lists.sourceforge.net/lists/listinfo/vmtk-users
>> 
>> 
>> 
>> 
>> <any011_wss_clipped_patching.png><centerlines.png><missing patches.png><surface after splitting.png><vmtkimageviewer of patched data.png><any011_wss_clipped_patching.vtp><any011_wss_clipped_patching.vti><any011_wss_cl.vtp><any011_wss_clipped.vtp>------------------------------------------------------------------------------
>> 
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_feb_______________________________________________
>> vmtk-users mailing list
>> vmt...@li...
>> https://lists.sourceforge.net/lists/listinfo/vmtk-users
> 
>