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 <luca.ant...@gmail.com> 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 <tos...@gmail.com> wrote:
>> Thanks, Arjan. That was an extremely helpful explanation.
>>
>>
>> On Wed, Feb 20, 2013 at 4:40 PM, Arjan Geers <ajge...@gmail.com> 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 <tos...@gmail.com> 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
>> vmtk-users@lists.sourceforge.net
>> 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
>> vmtk-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/vmtk-users
>
>
------------------------------------------------------------------------------
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
vmtk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/vmtk-users
