Updating Qhull?

[HubertHolin]

I notice that the qhull version now shipping with matplotlib is from 2012, while the current version on qhull.org is 2015.2 . This newer version promises a better (if arguably incomplete) C++ interface, and reentrancy. Would it be worth it to update the version shipping with matplotlib?

[jenshnielsen]

👍 from me I would probably not target 2.0 but for 2.1 it makes sense to give it a try. I think @ianthomas23 wrote most of the code that uses qhull so he might have some insight if there are any issues with this?

[QuLogic]

Fedora already has a patch for this, I think.

[ianthomas23]

I'll write a PR for this.

Ian

On 18 July 2016 at 19:15, Elliott Sales de Andrade <notifications@github.com

wrote:

Fedora already has a patch for this
https://pkgs.fedoraproject.org/cgit/rpms/python-matplotlib.git/commit/?id=da083597a27287918a51ec229172da8a8abc6068,
I think.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#6791 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAja5jDUgthBWdtR0I4lpkyNN8JAD-eeks5qW8LcgaJpZM4JO1gh
.

[HubertHolin]

I believe the Fedora patch is for the non-reentrant version (++#include <libqhull/qhull_a.h> vs #include <libqhull_r/qhull_ra.h>). But at any rate it's a step forward. And thanks iantthomas23 for his proposal!

[WeatherGod]

Slightly off-topic, but while we have your attention, Ian. There was a
poster at the SciPy conference that might be of interest to you,
maybe: "Cell_tree2d:
A High Performance Bounding Volume Hierarchy for Unstructured Meshes".
Unfortunately,
the SciPy website won't produce a permalink, but you can find it at
http://scipy2016.scipy.org/ehome/146062/332963/.

On Tue, Jul 19, 2016 at 6:36 AM, HubertHolin notifications@github.com
wrote:

I believe the Fedora patch is for the non-reentrant version (++#include
<libqhull/qhull_a.h> vs #include <libqhull_r/qhull_ra.h>). But at any
rate it's a step forward. And thanks iantthomas23 for his proposal!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#6791 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AARy-Au0mRKlmUMmAnkqw54ND6rOF4F1ks5qXKingaJpZM4JO1gh
.

[ianthomas23]

@WeatherGod: I have heard of cell_tree2d via the pyugrid folks. It has functionality similar to our TrapezoidMapFinder.

[WeatherGod]

Ah, ok. Yeah, his poster did a comparison with TrapezoidMapTriFinder along
with other algorithms. IIRC, it beat the pants off of
TrapezoidMapTriFinder, but my suspicion is that that might be due to its
support for masked arrays, perhaps?

On Wed, Jul 20, 2016 at 4:50 AM, Ian Thomas notifications@github.com
wrote:

@WeatherGod https://github.com/WeatherGod: I have heard of cell_tree2d
via the pyugrid folks. It has functionality similar to our
TrapezoidMapFinder.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#6791 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AARy-GUM9tuZ6M8zQl1mcXCfzAg5zVPUks5qXeFKgaJpZM4JO1gh
.

[ianthomas23]

@WeatherGod: I'd expect their algorithm to be faster; it is much more recent than the one used in TrapezoidMapTriFinder. Back in March a pyugrid discussion had the two performing within 30% of each other, so they must have made some improvements since then.

I find it quite amusing that the state of unstructured grid tools in python is so advanced that other people are using some of our handy plotting utilities as comparisons.

[rathann]

Fedora package mainainer here. It'd be nice to have support for using system version of qhull. We're currently doing that with a patch (as noted by @QuLogic ), but would gladly drop it if upstream support was in place.

@HubertHolin : are you saying we should switch the #include to the <libqhull_r/qhull_ra.h> version?

[HubertHolin]

@rathann: are you saying we should switch the #include to the <libqhull_r/qhull_ra.h> version?

Ultimately yes, but most likely not immediately.

The impetus for switching is that this other version is based upon a reentrant architecture, which should prove more robust than a non-reentrant one, in addition to the potential benefits of re-entrancy for this particular problem (which I do not know if they are real or simply potential). However, reading from the Qhull website, I am afraid there would be more work than simply switching the include directive, while the risk exists that in its current form (the reentrant work is stated as being missing a few pieces) this version might not work for our purposes, so it might prove prudent to experiment before switching, and this requires time. But maybe we do have enough time for the 2.1 release…

[QuLogic]

Updated via #7747.