SCIRun User Mailing List

Text archives Help


[SCIRUN-USERS] Re: Re: Biomesh3D


Chronological Thread 
  • From: Darrell Swenson <darrell.swenson@gmail.com>
  • To: Francois Malan <fmalan@medvis.org>
  • Cc: Petar Petrov <pip010@gmail.com>, scirun-users@sci.utah.edu
  • Subject: [SCIRUN-USERS] Re: Re: Biomesh3D
  • Date: Mon, 19 Apr 2010 10:01:52 -0600
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=rL5BrZZPxzmBpIuLdPoFrYmmP8EGOFKe/7PQUCV9DYE/mdTABvQx8FM6Py/hoPDdg0 IjhRP9J1sobs0y8ZQtTvtD3yu2Rh83VLr5T1CH78fB9A2RSywfwRJUq+opAiZ5yK+/jN GoB5AuRP64cCQ7VQPcoSWbzEHGdC9QHb5gw6s=

As far as I know here are the knobs you have for controlling mesh resolution in biomesh3D.

Yes, "max_sizing_field" will influence the spacing of the particles on the surface of the mesh, however, you need to adjust the tetgen flags to control the overal size or quality of the tetrahedral in the mesh.

The parameter "mat_radii" does not directly influence the particle spacing. Rather, it is related to the tightening step which attempts to smooth the surface before it is meshed.

Other parameters that influence the final mesh resolution:

"SIZING_SCALE_VAR" (I am not sure if this still exists in the latest version)
"tetgen_joined_vol_flags" (specifically the 'A' flag controls the total tetrahedral volume and 'q' is a quality constraint)

Good luck,

Darrell Swenson



On Apr 19, 2010, at 9:07 AM, Francois Malan wrote:

Hi Petar

I have experimented a bit with SciRun BioMesh3D myself, and yes, the
medial axis computation can take a ridiculous amount of time. Which is
really strange, since as far as I know it should not be THAT hard to
compute. For example: you can compute a distance field from the
surface and then place particles along the inner maxima. Which should
be something you can do in the order of minutes. But I'm just guessing
here...

The medial axis refinement does, as far as I know, not affect the tet
resolution, but is required for the program to compute correct (i.e.
correct geometry) output. It is only "mat_radii" and
"max_sizing_field" which influence the final tet count.

Try to keep the "refinement_levels" low. Let's say <= 4.

I'd like to try to run your file btw. If you can send me your nrrd and
model_config.py I'll see what happens.

Ciao
Francois



On 19 April 2010 12:10, Petar Petrov <pip010@gmail.com> wrote:
hello all,
I have some issues with the meshing pipeline coming along with scirun.
to start with I am doing a brain 3dmesh of 4tissue types skull,csf,gm,wm,
coming from 3.5 tesla MRI 256x256x256:volume
My first try with 3tissue types was successful it run in decent less than
24h on 3xAMD with 6GB ram.
However running scirun on thw 4tissue type turned to be such a pain.
at one stage or another the pipeline got stacked on some operation which
takes like forever.

and as forever I mean issues like:

[1]- Run Particles system takes prohibitive time to execute:
max sf: 20.55
Binning structure radius = 35.5936
Initializing with a mesh...
        input_seeds/d_3_4_seed.ptcl
Reading particle file...
  number of particles = 309870
309870
Done intializing
Rebuilding Neighborhoods
ApproximateNeighborhoods::optimize iteration: 16785.8 seconds.
Rebuilding Neighborhoods
ApproximateNeighborhoods::optimize iteration: 15472.9 seconds.
Writing point file 9 ...
       DONE.
Writing particle file 9 ...
       DONE.


this 16 thousands seconds for lets say 100 (forget 400) iterations will take
a bit long for just 309870 or even up to a million particles which is to be
expected
note the high value of sizing field = 20. which should produce less of a
tetrahedra, which also mean less of particles at stage 6 , right?


[2]- tetgen never finishes on stage 7:

SCIRun_SVN/bin/tetgen" junctions/particle-union.node
Opening junctions/particle-union.node.
Constructing Delaunay tetrahedralization.
Warning:  Point #709479 is duplicated with Point #190379. Ignored!
Warning:  Point #698163 is duplicated with Point #171285. Ignored!
Warning:  Point #749986 is duplicated with Point #213475. Ignored!
Warning:  Point #784349 is duplicated with Point #234481. Ignored!

after 2 days on 1 CPU = 100% it continues while the memory consumption is
24Mb !

stage 8 never really reached :(

I did some modification on the code coming from SVN, as you can see i got
some debug info out, which i recommend to be able to show with some '-d'
debug flag on the shell.
second big improvement was to do smarter scheduling of the spawned
sub-processes at stage 6, to keep up to 3 running processes thus scale
nicely with my triple core CPU, and insure I dont run out of physical
memory. using virtual memory must be avoided at all cost with the speeds I
am reporting :(((



I can provide the nrrd file of my segmentation,(~500kb) if someone is
willing to give it a try.

It is really frustrating as I cannot seem to pin whats the core of the issue
here. does medial axis refinement reflect the number of particles or tets in
the final mesh?
i found out there is a hardcoded limit of atleast 3 steps in the medial axis
refinement shell utility, something not documented!

I appreciate any inside you might give.

All the best,
Petar









Archive powered by MHonArc 2.6.16.

Top of page