[yt-users] Problem when making a slice plot

Markus Haider markus.haider at uibk.ac.at
Sun Sep 16 08:43:31 PDT 2012


Hi Matthew,

Thanks for the detailed answer. It is not a problem, I just wanted to 
know for sure that it is the visualization and not the data which is wrong,

Cheers,
Markus

> Hi Markus,
>
> On Sat, Sep 15, 2012 at 7:18 AM, Markus Haider <markus.haider at uibk.ac.at> wrote:
>> Hi everyone,
>>
>> I am experiencing a strange problem when making a slice plot of a flash
>> snapshot. From the first snapshot (which should be the initial condition) I
>> plotted the temperature, which should just be the same value all over the
>> simulation box.
>>
>> However, when I make a slice through the middle of the volume, this is how
>> the result looks like, when yt automatically determines limits of the
>> colorbar:
>> http://ubuntuone.com/4I63O6KY7LDELHa0ZWvjem
> Ah, yes.  This is a familiar problem -- the colorbar limits are so
> tight as to not be visible on the colorbar itself!  What you're seeing
> is actually the roundoff error in the antialiasing that yt applies,
> which preferentially builds up at cell boundaries and in higher
> refined areas.  I think the (relative) scatter should be on the order
> of 1e-14 or so.  Since it's so small, it only shows up when *all* the
> values are the same.  For reference, here's the source code:
>
> https://bitbucket.org/yt_analysis/yt/src/tip/yt/visualization/_MPL.c#cl-143
>
> The problem comes in during the calculation of the overlap factors,
> which are meant as a simple means of anti-aliasing.  Please note, this
> code is overdue for touching up; it's not only terse but a bit
> obscure.  The overlap lines:
>
> overlap2 = ((min(rypx, ysp+dysp) - max(lypx, (ysp-dysp)))*ipx_dy);
> overlap1 = ((min(rxpx, xsp+dxsp) - max(lxpx, (xsp-dxsp)))*ipx_dx);
> and then the value deposited is: (dsp*overlap1)*overlap2;
>
> This is taking the overlap of a pixel with a cell in the y, then in
> the x, and multiplying the two.  When there are multiply cells
> overlapping a pixel, this becomes off by just a tiny bit.
>
> You can disable this behavior by turning off antialiasing in the FRBs.
>   Perhaps we should simply do this by default, although I think it will
> lead to slightly less attractive plots in most cases.  This can be
> done on a slice plot like:
>
> slice_plot = SlicePlot( ... )
> slice_plot.antialias = False
> slice_plot._recreate_frb()
>
>> If I specify the color-bar limits on my own, it looks like as it should be:
>> http://ubuntuone.com/7E1YmEgKoV9XmR77Ddplhs
>>
>> Does someone know what is going wrong here?
> Yup, in short -- the values are all correct to extremely tight
> precision, but matplotlib will happily expose that tight precision
> when it autosets colorbar limits.  I think one possibility we could
> explore is actually having the SlicePlot / ProjectionPlot do a better
> job of auto-calculating limits, and not letting matplotlib do it, when
> values are quite tightly clustered.  One could imagine ensuring that
> we get a bit of room on both sides, or perhaps not logging plots that
> have < 1 OOM in spread.
>
> Hope that helps -- let us know!
>
> Matt
>
> PS I just saw you had asked this in IRC -- hope to see you again soon!
>
>> Here is the script I used to make the plot:
>> http://ubuntuone.com/7icVc1nNDBaQfRRZBRTXEt
>>
>> And in case you want to reproduce the error, here is the snapshot file:
>> http://ubuntuone.com/6wq4c6HALXdqyktHjWTtaB
>>
>> Thanks for your help,
>> Markus
>> _______________________________________________
>> 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
>
>
> End of yt-users Digest, Vol 55, Issue 19
> ****************************************
>




More information about the yt-users mailing list