# Size-dependent computational costs of Delaunay3D
**URL:** https://discourse.paraview.org/t/size-dependent-computational-costs-of-delaunay3d/4171
**Category:** ParaView Support
**Created:** [April 24, 2020, 9:43am UTC](https://discourse.paraview.org/t/size-dependent-computational-costs-of-delaunay3d/4171 "2020-04-24T09:43:35Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@jduriez](https://discourse.paraview.org/u/jduriez)
#### Post date: [April 24, 2020, 9:43am UTC](https://discourse.paraview.org/t/size-dependent-computational-costs-of-delaunay3d/4171/1 "2020-04-24T09:43:35Z")
Hi,
I have two XMLUnstructuredGrid data sets, each with a set of points (a regular grid actually…) carrying a scalar field.
The two data sets are nearly homothetical one with respect to another: they include the _same number of points/cells_ (within a 10% variation, and have the same memory footprint) but with _different inter-points spacings_. For instance 1 for one data set, and 3 for the other
Yet, the computational costs using Delaunay3D filter (to turn each discrete data set into a continuous one, before extracting iso-surfaces) in ParaView 5.4.1 are completely differents.
There is a 10 ratio in the memory footprint of created Delaunay3D objects in the pipeline (5.1 MB for the one stemming from the “small” grid, 52 MB for the “big” one), together with a 26\* increase in the number of cells (but the same number of points)
And there is a ~ 200 ratio in execution time cost of my workflow…
(Good news is the final iso-surfaces are pretty much homothetic, as expected)
I’m kind of a beginner and run Delaunay3D with default parameters. Maybe there is some dimensional attribute, but I could not find it… (I understand from the doc Tolerance attribute is not a possible one because it is a ratio ?)
What is the reason for this size (or unit)-dependent behavior ?
Thanks
---
### Author:  [@jduriez](https://discourse.paraview.org/u/jduriez)
#### Post date: [July 23, 2020, 12:57pm UTC](https://discourse.paraview.org/t/size-dependent-computational-costs-of-delaunay3d/4171/2 "2020-07-23T12:57:24Z")
A VTK code example is at [https://discourse.vtk.org/t/size-dependent-time-cost-of-delaunay3d-filter/3840](https://discourse.vtk.org/t/size-dependent-time-cost-of-delaunay3d-filter/3840)
---
### Author:  [@jduriez](https://discourse.paraview.org/u/jduriez)
#### Post date: [July 28, 2020, 11:11am UTC](https://discourse.paraview.org/t/size-dependent-computational-costs-of-delaunay3d/4171/3 "2020-07-28T11:11:22Z")
Turning the initial data set from an Unstructured Grid into a Structured one (as it should be from the start…) actually cancelled the need for a Delaunay3D filter before applying Contour filter (which runs smoothly on structured grid, unlike unstructured).
All in all, my problem is solved, even though this Delaunay3D behavior (on a case outside its validity domain, though) remains a little obscure to me.