Possible issue in sph.render_image function

[Thor Tepper-Garcia]

Hi,

From the outset I just want to emphasise what a neat package Pynbody is.

I've been using it ever since I discovered it a few years back and it does not stop to amaze ;) So thanks for that, Andrew and collaborators!

Anyway, I was looking into some of its plotting capabilities to create 2D maps, specifically: hist2d, gauss_kde, and sph.render_image. The latter has - at least for my purposes - by far the best performance. Attached an example: three plots, each displaying the mean vertical velocity <vz> of a gas disk on a face-on projection, using each of these three methods.

As you can see, render_image works extremely well in this case, and also in other cases, e.g. when averaging any other velocity (radial, azimuthal) and of course it works extremely well when projecting the gas density.

However, when I repeat the same experiment with, say, the z coordinate, it does something weird. Attached an example, similar to <vz>, but now showing the mean z. While hist2d and gauss_kde yield comparable (and expected) results, render_image does not.

My question is: Is it fundamentally impossible to calculate maps of z, or of any *spatial coordinate* in general, with render_image? Or am I doing something wrong?

I'm sure (I think) I'm setting all the arguments (e.g. out_units, kernel) to sensible values, as demonstrated by the <vz> maps. For reference, these are the function calls in each case:

s = pynbody.load('path to Ramses output file')

# mean vz

sph.render_image(s.gas,
                qty='vz',
                x2=30.,
                xy_units='kpc',
                out_units='km s^-1',
                kernel=sph.Kernel()
        )

# mean z

sph.render_image(s.gas,
                qty='z',
                x2=30., 
                xy_units='kpc',
                out_units='kpc',
                kernel=sph.Kernel()
        )

The former works as expected, judging by comparing to hist2d and gauss_kde, but with superior quality. The latter doesn't.

Note that I'm referring here to the gas cells in a Ramses simulation.

Any hint as to why this is the case and, ideally, how to solve will be much appreciated!

Cheers

Thor

[Pontzen, Andrew]

Hi Thor,

What you’ve asked pynbody to do is plot an image of z as evaluated in the z=0 plane, so roughly speaking you will get an image full of zeros. That’s not precisely true because the cells are not precisely aligned on z=0, but basically you’re making a plot of zero plus/minus some numerical noise.

From what I understand, it seems like what you really want is a projected mean z, perhaps density-weighted. For that you’d want to do something like

pynbody.plot.sph.image(s.gas, qty=‘z’, av_z=‘rho’, …)

Hope this helps!

All the best, Andrew

--
You received this message because you are subscribed to the Google Groups "pynbody-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pynbody-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pynbody-users/cb7e6be3-0259-428c-98b1-4478b4dac081n%40googlegroups.com.
<disc_vz_hist2d.png><disc_z_renderimg.png><disc_vz_renderimg.png><disc_z_hist2d.png><disc_vz_gausskde.png><disc_z_gausskde.png>

[Tepper]

Hey Andrew,

Thanks a million for you help!

I did see where I went wrong.

So, render_image always produces a slice at z_plane *except*

when qty=‘rho’, in which case it does take an average?

I ask because in this case density maps created with either plot.sph.image or

sph.render_image look identical.

While I see that, for my case at least, the density is highest at z=0,

I would expect some differences, albeit small, between calculating

a projected (i.e. integrated) density and simply plotting a cut at z=0.

Other questions I have, if you don’t mind:

1) Is it possible to change the width of the smoothing kernel used in

gauss_kde?

2) Is it possible to create plots with plot.sph.image which are not

square, say, 10 kpc in height but 20 kpc in width? I’m guessing not

by peeking into the source code, but perhaps there is a workaround?

Cheers

Thor

___________________________

Dr. Thor Tepper García

Astrophysicist
www.thorsten.mx
@thorsten_mx