[yt-users] Projection

[Matthew Turk]

On Tue, Nov 14, 2017 at 1:04 PM, Nathan Goldbaum <nathan12343 at gmail.com>
wrote:

> Ah, so this isn't actually a bug. There's even a comment in the code
> indicating that this is the intended behavior:
>
> https://github.com/yt-project/yt/blob/master/yt/data_
> objects/construction_data_containers.py#L373
>
> So the choices about what to do here are, in my opinion:
>
> * Change this behavior to fill the array with zeros instead of NaNs
>

I think this would give the wrong impression, especially for things like
weighted average velocity fields.


> * Improve the documentation to make this choice clearer
>

Probably a good thing.

I think I would suggest another option, which would be to filter it based
on which values are non-NaN.  In the cases identified in the emails, I
would *suspect* that what's happening is that there are elements in the
quad tree that are initialized from the tree initialization step (which
just looks at the mesh from the container, not the selected elements in the
mesh) and left at zero following initialization.  We could either have a
"touched" flag on all of the mesh elements (i.e., "has this been touched by
data, or is it left at initialized value) and filter in the conversion of
the quad tree to the flat arrays, or we could filter in the python code
based on NaNs.  My preference would be to filter it in the creation of the
flat arrays, as then it will be uniformly applied even without weight
fields.


>
> I'm not sure offhand what is the best approach, especially given that
> changing this behavior would be a backward compatibility break.
>

I think filtering NaNs is not a big change in compatibility.  I think we'd
just need to make sure that the cmap normalization has the same behavior
for missing values as for NaN values, which I think it does.


>
> For the original question: your data aren't all NaNs I suspect. E.g. take
> a look at this example script:
>
> import yt
> import numpy as np
> ds = yt.load('IsolatedGalaxy/galaxy0030/galaxy0030')
> disk = ds.disk('c', [0, 0, 1], (1000, 'pc'), (100, 'pc'))
> proj = ds.proj('density', axis='z', weight_field='density',
> data_source=disk,
>                method='integrate')
> dens_proj = proj['density']
> print(dens_proj[np.isfinite(dens_proj)])
> print(np.nanmax(dens_proj))
> print(np.nanmin(dens_proj))
>
> Which prints out values in regions where the projection isn't filled with
> NaNs.
>
>
> On Tue, Nov 14, 2017 at 12:45 PM, José Mauricio Utreras <
> jutreras at ug.uchile.cl> wrote:
>
>> Hi everyone,
>>
>> I got the same result using the IsolatedGalaxy dataset
>>
>> ds=yt.load('IsolatedGalaxy/galaxy0030/galaxy0030')
>> disk = ds.disk('c',[0,0,1],(1000,'pc'),(100,'pc'))
>> proj=ds.proj('density',axis='z',weight_field='density',data_
>> source=disk,method='integrate')
>> proj['density']
>> >>> YTArray([ nan,  nan,  nan, ...,  nan,  nan,  nan]) g/cm**3
>>
>> 2017-11-14 15:38 GMT-03:00, Nathan Goldbaum <nathan12343 at gmail.com>:
>> > Can I get one of you to open an issue?
>> >
>> > https://github.com/yt-project/yt/issues/new
>> >
>> > If you can, please include a script to reproduce the problem, making
>> use of
>> > one of the public datasets on yt-project.org/data.
>> >
>> > -Nathan
>> >
>> > On Tue, Nov 14, 2017 at 12:34 PM, Andrew James Emerick
>> > <aje2123 at columbia.edu
>> >> wrote:
>> >
>> >> Hello Matias and Nathan,
>> >>
>> >> I was able to reproduce this error on my own Enzo data set(s) using
>> >> similar code. I did a little more playing around and it looks like it
>> >> only
>> >> breaks when having a weight_field. weight_field = None seems to be
>> O.K. .
>> >> It also occurs for the "region" objects, in addition to the disk.
>> >> Interestingly, as Matias pointed out, doing something like this works:
>> >>
>> >> region = ds.region([0.5,0.5,0.5], [0.0, 0.0, 0.0], [1.0, 1.0, 1.0])
>> >> proj=ds.proj('density',axis='z',weight_field='density',data_
>> >> source=region,method='integrate')
>> >>
>> >> but this does not:
>> >>
>> >> region = ds.region([0.5,0.5,0.5], [0.1,0.1,0.1], [0.9,0.9,0.9] )
>> >> proj =ds.proj('density',axis='z',weight_field='density',data_
>> >> source=region,method='integrate')
>> >>
>> >> In short, this indeed appears to be a bug, and possibly not specific
>> to a
>> >> single dataset.
>> >>
>> >>
>> >>
>> >>
>> >> Andrew
>> >>
>> >>
>> >> On Tue, Nov 14, 2017 at 12:40 PM, Nathan Goldbaum <
>> nathan12343 at gmail.com>
>> >> wrote:
>> >>
>> >>> This sounds like a bug. I don't think you should ever get back NaNs
>> from
>> >>> a projection operation.
>> >>>
>> >>> Is there any chance you can share the dataset that's triggering this
>> >>> behavior?
>> >>>
>> >>> On Tue, Nov 14, 2017 at 11:34 AM, Matias Enrique Suazo Campos <
>> >>> matias.suazo at ug.uchile.cl> wrote:
>> >>>
>> >>>> Dear YT users,
>> >>>>
>> >>>> I'm trying to make a density projection, in the following lines I
>> show
>> >>>> you the lines that I have.
>> >>>>
>> >>>> #Ramses output
>> >>>> ds = yt.load(path+"output_%05d"%snap+"/info_%05d.txt" %snap)
>> >>>> disk = ds.disk('max',[0,0,1],(20,'pc'),(5,'pc'))
>> >>>> proj=ds.proj('density',axis='z',weight_field='density',data_
>> >>>> source=disk,method='integrate')
>> >>>>
>> >>>> However when I print proj["density"] I get a list of nan, however
>> when
>> >>>> I
>> >>>> use the whole domain as my data_source I get reasonable numbers.
>> >>>>
>> >>>> Thanks,
>> >>>> Matías Suazo
>> >>>> MSc student at Universidad de Chile
>> >>>>
>> >>>> _______________________________________________
>> >>>> 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
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> NSF Graduate Fellow
>> >> Columbia University
>> >> Department of Astronomy
>> >>
>> >> _______________________________________________
>> >> 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
>>
>
>
> _______________________________________________
> 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/20171114/49378c57/attachment-0002.html>