[yt-users] Projection

Nathan Goldbaum nathan12343 at gmail.com
Tue Nov 14 12:58:28 PST 2017


Matt opened an issue to track this:

https://github.com/yt-project/yt/issues/1623

Let's move further discussion about this behavior to the issue.

On Tue, Nov 14, 2017 at 2:42 PM, Matthew Turk <matthewturk at gmail.com> wrote:

>
>
> 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
>>
>>
>
> _______________________________________________
> 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/2cd9f1d1/attachment.html>


More information about the yt-users mailing list