[yt-users] use of MultivariateTransferFunction

[Eric Gentry]

It sounds like mesh/particle filtering might be a good solution for this
situation: http://yt-project.org/doc/analyzing/filtering.html

This would allow you to create a filter based on density_gradient_magnitude,
and then only plot the density of cells/particles that make it through your
filter.

It's much more limited than a full multivariate transfer function, but it
sounds like it does exactly what you want.



--
Eric Gentry
PhD Candidate
ISB 159 | ericsgentry.com
Astronomy and Astrophysics
University of California, Santa Cruz


On Mon, Dec 4, 2017 at 10:39 AM, Nathan Goldbaum <nathan12343 at gmail.com>
wrote:

>
>
> On Sun, Dec 3, 2017 at 5:39 PM, <genghis17 at comcast.net> wrote:
>
>> Hello,
>>
>> I am trying to render some density data using a transfer function which
>> depends on both the density and the density_gradient_magnitude field.  From
>> my study of the docs it seems that this can be done using the
>> MultivariateTransferFunction class, but the few examples given do not make
>> it clear.
>>
>> What I want to do is render the density using, say, the 'hsv' colormap.
>> The bounds for the density will be 1e-6 to 1e0. However, if the *gradient*
>> of the density at a given grid point is outside the range of, say, 1e-5 to
>> 1e-2, then I don't want that datum to be visible in the plot.  The point of
>> this is to highlight features in the density that are only recognizable
>> when considering how the density changes from place to place.
>>
>> It is not clear to me whether this kind of rendering can be done with yt,
>> but in any case the immediate problem I'm having is that
>> source.set_transfer_function() does not accept an instance of
>> MultiVariateTransferFunction as an argument.  I get an error about an
>> incorrect data type:
>>
>> Traceback (most recent call last):
>>   File "./doit.py", line 64, in <module>
>>     source.set_transfer_function(mv)
>>   File "/usr/lib64/python2.7/site-packages/yt/visualization/volume_rendering/render_source.py",
>> line 311, in set_transfer_function
>>     self.transfer_function = transfer_function
>>   File "/usr/lib64/python2.7/site-packages/yt/visualization/volume_rendering/render_source.py",
>> line 210, in transfer_function
>>     "received object of type %s" % type(value))
>> RuntimeError: transfer_function not a valid type, received object of type
>> <class 'yt.visualization.volume_rendering.transfer_functions.MultiV
>> ariateTransferFunction'>
>>
>>
> MultiVariateTransferFunction was written many years ago and was never
> properly documented or tested. A few years ago the volume rendering
> infrastructure was substantially refactored and the
> MultiVariateTransferFunction did not go along for the ride, mostly due to
> the poor state of the documentation and testing for it. I tried to port it
> a little bit ended up not having time to do the deep dive that was
> necessary to fully understand what it does.
>
> In principle it should be possible to use a multi variate transfer
> function with the new volume rendering infrastructure but it will take
> someone willing to dive in and do some refactoring to re-enable support.
>
> A first thing to do would be to add MultiVariateTransferFunction to the
> `valid_types` tuple a few lines above where the error you're seeing is
> getting issued.
>
> If the documentation indicates that it's possible to use the
> MultiVariateTransferFunction we should probably remove those mentions until
> someone is able to re-enable that functionality.
>
> If you're not willing to mess with the internals of the volume renderer
> then I'm afraid you're doing to need to stick with the other kinds of
> transfer functions in yt.
>
>
>
>> I can avoid this error using either TransferFunction() or
>> ColorMapTransferFunction(), but then I can't query two fields of data to do
>> the rendering, as far as I know.
>
>
> I'm not sure there's a way to do what you're trying to do in the current
> version of yt, unfortunately. I suspect that the way forward is to
> re-enable the existing MultiVariateTransferFunction or rewrite it from
> scratch.
>
>
>> (It would be easier to set up transfer functions if fields could simply
>> be referred to by name instead of by field_id.  How does one figure out the
>> field_id for an arbitrary field that one has added to a dataset?  Is the
>> density field always 0 and then any added fields are enumerated in the
>> order in which they are added?)
>>
>
> I agree about the field ids numbers not being particularly intuitive. Code
> contributions going in the direction of making that more intuitive would be
> very welcome.
>
>
>>
>> Does anyone know of a way to do this with yt?
>>
>> thanks,
>>
>> Dale
>>
>> _______________________________________________
>> yt-users mailing list
>> yt-users at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>
>
>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20171204/409cf85e/attachment-0002.html>