<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 14, 2017 at 1:04 PM, Nathan Goldbaum <span dir="ltr"><<a href="mailto:nathan12343@gmail.com" target="_blank">nathan12343@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Ah, so this isn't actually a bug. There's even a comment in the code indicating that this is the intended behavior:<br><br><a href="https://github.com/yt-project/yt/blob/master/yt/data_objects/construction_data_containers.py#L373" target="_blank">https://github.com/yt-project/<wbr>yt/blob/master/yt/data_<wbr>objects/construction_data_<wbr>containers.py#L373</a><br><br></div>So the choices about what to do here are, in my opinion:<br><br></div>* Change this behavior to fill the array with zeros instead of NaNs<br></div></div></div></div></div></blockquote><div><br></div><div>I think this would give the wrong impression, especially for things like weighted average velocity fields.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div></div>* Improve the documentation to make this choice clearer<br></div></div></div></div></blockquote><div><br></div><div>Probably a good thing.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><br></div>I'm not sure offhand what is the best approach, especially given that changing this behavior would be a backward compatibility break.<br></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><br></div>For the original question: your data aren't all NaNs I suspect. E.g. take a look at this example script:</div><div><br></div><div>import yt<br>import numpy as np<br>ds = yt.load('IsolatedGalaxy/<wbr>galaxy0030/galaxy0030')<span class=""><br>disk = ds.disk('c', [0, 0, 1], (1000, 'pc'), (100, 'pc'))<br>proj = ds.proj('density', axis='z', weight_field='density', data_source=disk,<br>               method='integrate')<br></span>dens_proj = proj['density']<br>print(dens_proj[np.isfinite(<wbr>dens_proj)])<br>print(np.nanmax(dens_proj))<br>print(np.nanmin(dens_proj))</div><div><br></div><div>Which prints out values in regions where the projection isn't filled with NaNs.<br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 14, 2017 at 12:45 PM, José Mauricio Utreras <span dir="ltr"><<a href="mailto:jutreras@ug.uchile.cl" target="_blank">jutreras@ug.uchile.cl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
<br>
I got the same result using the IsolatedGalaxy dataset<br>
<br>
ds=yt.load('IsolatedGalaxy/gal<wbr>axy0030/galaxy0030')<br>
disk = ds.disk('c',[0,0,1],(1000,'pc'<wbr>),(100,'pc'))<br>
<span>proj=ds.proj('density',axis='z<wbr>',weight_field='density',data_<wbr>source=disk,method='integrate'<wbr>)<br>
</span>proj['density']<br>
>>> YTArray([ nan,  nan,  nan, ...,  nan,  nan,  nan]) g/cm**3<br>
<div class="m_-2976856030462114526HOEnZb"><div class="m_-2976856030462114526h5"><br>
2017-11-14 15:38 GMT-03:00, Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com" target="_blank">nathan12343@gmail.com</a>>:<br>
> Can I get one of you to open an issue?<br>
><br>
> <a href="https://github.com/yt-project/yt/issues/new" rel="noreferrer" target="_blank">https://github.com/yt-project/<wbr>yt/issues/new</a><br>
><br>
> If you can, please include a script to reproduce the problem, making use of<br>
> one of the public datasets on <a href="http://yt-project.org/data" rel="noreferrer" target="_blank">yt-project.org/data</a>.<br>
><br>
> -Nathan<br>
><br>
> On Tue, Nov 14, 2017 at 12:34 PM, Andrew James Emerick<br>
> <<a href="mailto:aje2123@columbia.edu" target="_blank">aje2123@columbia.edu</a><br>
>> wrote:<br>
><br>
>> Hello Matias and Nathan,<br>
>><br>
>> I was able to reproduce this error on my own Enzo data set(s) using<br>
>> similar code. I did a little more playing around and it looks like it<br>
>> only<br>
>> breaks when having a weight_field. weight_field = None seems to be O.K. .<br>
>> It also occurs for the "region" objects, in addition to the disk.<br>
>> Interestingly, as Matias pointed out, doing something like this works:<br>
>><br>
>> region = ds.region([0.5,0.5,0.5], [0.0, 0.0, 0.0], [1.0, 1.0, 1.0])<br>
>> proj=ds.proj('density',axis='z<wbr>',weight_field='density',data_<br>
>> source=region,method='integrat<wbr>e')<br>
>><br>
>> but this does not:<br>
>><br>
>> region = ds.region([0.5,0.5,0.5], [0.1,0.1,0.1], [0.9,0.9,0.9] )<br>
>> proj =ds.proj('density',axis='z',we<wbr>ight_field='density',data_<br>
>> source=region,method='integrat<wbr>e')<br>
>><br>
>> In short, this indeed appears to be a bug, and possibly not specific to a<br>
>> single dataset.<br>
>><br>
>><br>
>><br>
>><br>
>> Andrew<br>
>><br>
>><br>
>> On Tue, Nov 14, 2017 at 12:40 PM, Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com" target="_blank">nathan12343@gmail.com</a>><br>
>> wrote:<br>
>><br>
>>> This sounds like a bug. I don't think you should ever get back NaNs from<br>
>>> a projection operation.<br>
>>><br>
>>> Is there any chance you can share the dataset that's triggering this<br>
>>> behavior?<br>
>>><br>
>>> On Tue, Nov 14, 2017 at 11:34 AM, Matias Enrique Suazo Campos <<br>
>>> <a href="mailto:matias.suazo@ug.uchile.cl" target="_blank">matias.suazo@ug.uchile.cl</a>> wrote:<br>
>>><br>
>>>> Dear YT users,<br>
>>>><br>
>>>> I'm trying to make a density projection, in the following lines I show<br>
>>>> you the lines that I have.<br>
>>>><br>
>>>> #Ramses output<br>
>>>> ds = yt.load(path+"output_%05d"%sna<wbr>p+"/info_%05d.txt" %snap)<br>
>>>> disk = ds.disk('max',[0,0,1],(20,'pc'<wbr>),(5,'pc'))<br>
>>>> proj=ds.proj('density',axis='z<wbr>',weight_field='density',data_<br>
>>>> source=disk,method='integrate'<wbr>)<br>
>>>><br>
>>>> However when I print proj["density"] I get a list of nan, however when<br>
>>>> I<br>
>>>> use the whole domain as my data_source I get reasonable numbers.<br>
>>>><br>
>>>> Thanks,<br>
>>>> Matías Suazo<br>
>>>> MSc student at Universidad de Chile<br>
>>>><br>
>>>> ______________________________<wbr>_________________<br>
>>>> yt-users mailing list<br>
>>>> <a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br>
>>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/lis<wbr>tinfo.cgi/yt-users-spacepope.<wbr>org</a><br>
>>>><br>
>>>><br>
>>><br>
>>> ______________________________<wbr>_________________<br>
>>> yt-users mailing list<br>
>>> <a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br>
>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/lis<wbr>tinfo.cgi/yt-users-spacepope.<wbr>org</a><br>
>>><br>
>>><br>
>><br>
>><br>
>> --<br>
>> NSF Graduate Fellow<br>
>> Columbia University<br>
>> Department of Astronomy<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> yt-users mailing list<br>
>> <a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br>
>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/lis<wbr>tinfo.cgi/yt-users-spacepope.<wbr>org</a><br>
>><br>
>><br>
><br>
______________________________<wbr>_________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/lis<wbr>tinfo.cgi/yt-users-spacepope.<wbr>org</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" rel="noreferrer" target="_blank">http://lists.spacepope.org/<wbr>listinfo.cgi/yt-users-<wbr>spacepope.org</a><br>
<br></blockquote></div><br></div></div>