Hi Richard,
 sorry for the long wait.

Your pipeline looks good, but you'll need the radius at each point
(you seem proficient in Python and VTK so I won't provide you with
details on how to add a vtkDoubleArray to PointData, but let me know
if you need directions).

In any case, the mesh generator needs a scalar field over the input 
surface to be remeshed. That scalar field will be used (multiplied by
a factor) as the nominal size of the triangle edges in the remeshed 
surface (as demonstrated in the mesh generation tutorial on the vmtk
website).

The way you generate that scalar field is really up to you, you could
do it through curvatures or by evaluating the distance of the surface
from centerlines, or the closest centerline radius. The latter is probably 
what you're aiming at now, so as soon as you have your dataset with 
centerlines and radii (in a point array named, say, Radius), you can do

vmtkdistancetocenterlines -ifile surface.vtp -centerlinesfile centerlines.vtp 
-radiusarray Radius -useradius 1 -centerlineradius 1 --pipe 
vmtkmeshgenerator -elementsizemode edgelengtharray -edgelengtharray 
Radius -edgelengthfactor 0.3 -ofile foo.vtu 

The first script will generate the centerline radius field on the surface
and the second will remesh the surface taking that field into account for
the local triangle size.

Hope this helps


Luca


On Oct 12, 2012, at 6:43 PM, Richard Downe wrote:

> Upon observing the behavior of my automated setup for a week, I do think 
> I'm going to have to include the centerlines.
> I'm reasonably confident in the quality of my triangulated surfaces, but 
> I do think the fixed edge length passed to vmtkmeshgenerator is overly 
> limiting.
> 
> My question is this: what arguments to I need to feed into 
> vmtkcenterlinemerge if I want to have an appropriate vtkPolyData for use 
> as such in subsequent processing?
> 
> I have the code sample below for simply putting the centerlines into a 
> vtkPolyData; I have radius information available, but I'm curious what 
> it needs to look like internally for the rest of the vmtkpipeline to be 
> happy with it.
> Thanks.
> -rd
> 
>     def ComputeCenterlinePolyData(self, fusmesher):
>         vesselPoints = vtk.vtkPoints()
>         vesselLines = vtk.vtkCellArray()
>         vesselPoly = vtk.vtkPolyData()
> 
>         vesselCenterline = fusmesher.GetVesselCenterline()
>         vesselPoints.SetNumberOfPoints(len(vesselCenterline))
>         vesselLines.InsertNextCell(len(vesselCenterline))
> 
>         for i in range(len(vesselCenterline)):
>             p = vesselCenterline[i]
>             vesselPoints.SetPoint(i, p['x'], p['y'], p['z'])
>             vesselLines.InsertCellPoint(i)
> 
>         vesselPoly.SetPoints(vesselPoints)
>         vesselPoly.SetLines(vesselLines)
> 
>         branchPolys = []
> 
>         for i in range(fusmesher.GetBranchCount()):
>             branchPoints = vtk.vtkPoints()
>             branchLines = vtk.vtkCellArray()
>             branchPoly = vtk.vtkPolyData()
> 
>             branchCenterline = fusmesher.GetBranchCenterline(i)
>             branchPoints.SetNumberOfPoints(len(branchCenterline))
>             branchLines.InsertNextCell(len(branchCenterline))
> 
>             for j in range(len(branchCenterline)):
>                 p = branchCenterline[j]
>                 branchPoints.SetPoint(j, p['x'], p['y'], p['z'])
>                 branchLines.InsertCellPoint(j)
> 
>             branchPoly.SetPoints(branchPoints)
>             branchPoly.SetLines(branchLines)
>             branchPolys.append(branchPoly)
> 
>         appender = vtk.vtkAppendPolyData()
>         appender.AddInput(vesselPoly)
> 
>         for i in range(fusmesher.GetBranchCount()):
>             appender.AddInput(branchPolys[i])
> 
>         return appender.GetOutput()
> 
> On 10/09/2012 05:41 AM, Luca Antiga wrote:
>> Hi Richard,
>> 
>> On Oct 2, 2012, at 5:08 PM, Richard Downe wrote:
>> 
>>> I have been attempting to use vmtk to generate meshes for use with fluent.
>>> Because the nature of my workflow involves geometric transformations of
>>> segmented borders, my starting point is a point set (well, more
>>> accurately, several disjoint structured grids).
>>> I have a program that generates a topologically sound triangular surface
>>> with minimal triangle angle of 24 degrees, flow extensions added, and
>>> caps removed at boundaries.
>>> 
>>> My coordinates are also spaced in meters, so my edge lengths are
>>> typically on the order of 0.0002.
>>> After a few false starts, I have successfully been able to run
>>> vmtkmeshgenerator on the STL file output by my initial triangulation,
>>> and pipe it into vmtkmeshwriter to create a fluent file, and use a pipe
>>> I wrote myself to identify the inlets based on proximity of the entities
>>> to known locations of centerlines at boundaries.
>> Sounds like great work.
>> 
>>> The first surface I attempted ran in fluent fine.  2 subsequent, more
>>> complex surfaces are causing fluent to fail in mysterious ways that are
>>> almost certainly related to mesh quality.  I am invoking
>>> vmtkmeshgenerator with -edgelength 0.0002 as the only argument.  Are
>>> there known steps I can take to alleviate this/improve mesh quality?
>>> There are clearly a large number of people using vmtk successfully, so I
>>> can only assume I could be doing something better.  (When I examine the
>>> mesh, fluent's quality rating is typically between 10 and 20, with a
>>> maximum aspect ratio value of around 35).
>> I'd really need to look into the mesh, would it be possible for you to send
>> me the stl file?
>> 
>>> My current tack is to attempt to add the centerlines into the flow using
>>> vmtkdistancetocenterlines, on the assumption that this will cause the
>>> sizing function to generate more useful information, and thereby give me
>>> better shaped tetrahedra -- but I could use advice, as I do somewhat
>>> feel like I'm swinging in the dark.
>> Depending on the nature of your domain, it is possible that 0.0002 as an
>> element size ends up being inadequate for certain regions and overkill
>> for others, so the use of centerline information almost certainly helps.
>> 
>> However, I'd first take a look at the surface to see if it rings any bell.
>> 
>> Best,
>> 
>> 
>> Luca
>> 
>> 
>>> Thanks.
>>> --Richard
>>> 
>>> ------------------------------------------------------------------------------
>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>> Deploy New Relic app performance management and know exactly
>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>> http://p.sf.net/sfu/newrelic-dev2dev
>>> _______________________________________________
>>> vmtk-users mailing list
>>> vmtk-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/vmtk-users
> 
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> 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_sfd2d_oct
_______________________________________________
vmtk-users mailing list
vmtk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/vmtk-users

Reply via email to