[yt-users] cam.rotate
Nathan Goldbaum
nathan12343 at gmail.com
Mon Nov 18 11:51:54 PST 2013
I know this doesn't help much right now, but we're aware that the camera
interface is clunky and can be hard to understand.
There is an open proposal (
https://bitbucket.org/chummels/ytep/src/6200839294df62e3a64e4cdcc240426f6b67959b/source/YTEPs/YTEP-0010.rst)
to write a new volume rendering interface that will hopefully be easier to
work with. Cameron Hummels is leading that effort - if anyone is
interested in helping out they should contact him.
On Mon, Nov 18, 2013 at 11:46 AM, John Regan <johnanthonyregan at gmail.com>wrote:
> Hi,
>
> Sorry setting north_vector to L was an attempt to fix the problem so the
> image I sent initially was with north_vector set to [1,1,1].
> Setting it to L caused the warning you suggested and I killed the run.
> Maybe I'll try setting it to Lperp though?
>
>
> On 18 November 2013 21:42, Sam Skillman <samskillman at gmail.com> wrote:
>
>> Ah, yes, that is in fact the problem -- if north_vector is L and so is
>> the looking vector, it will ignore the north vector. Hopefully an error
>> message was issued something along the lines of:
>> mylog.error("North vector and normal vector are the same. Disregarding
>> north vector.")
>>
>> What I'd suggest is to set north_vector equal to something else, (a lot
>> of times i just use np.array([0., 0., 1.]) ) and try it again. Another
>> option would be to set it equal to Lperp, which will put Lperp pointing
>> "north" or "up" in the image plane. Then when you rotate you wouldn't even
>> need to supply the rot_vector keyword, as it defaults to rotating around
>> the north vector.
>>
>> Let us know if specifying a different north_vector works.
>>
>> Sam
>>
>>
>> On Mon, Nov 18, 2013 at 11:29 AM, John Regan <johnanthonyregan at gmail.com>wrote:
>>
>>> Hi Sam,
>>>
>>> Thanks for looking at this.
>>> c does change at every time step as I want the densest point to always
>>> be at the centre.
>>> What I think might be happening and I'm running a run now to check is
>>> that the north vector is messing things up. What should that be? I've set
>>> it to L for this run while before I just set it to something arbitrary.
>>>
>>> The script is:
>>>
>>> ts =
>>> TimeSeriesData.from_filenames("/wrk/regan/Stats/Halo8/HighRes/HighRes_Ref26_Reg1_All/DMSplit/MovieOutputs/DD*/*.hierarchy",
>>> parallel = True)
>>> comm = MPI.COMM_WORLD
>>>
>>> FileNames =
>>> glob.glob("/wrk/regan/Stats/Halo8/HighRes/HighRes_Ref26_Reg1_All/DMSplit/MovieOutputs/DD*/*.hierarchy")
>>> FileNames.sort()
>>> firstoutputnum = GetSubString(FileNames[0], '\d\d\d\d+')
>>> firstoutputnum = int(firstoutputnum[-1])
>>> #Pre-calculated L
>>> L = [-0.808823, -0.58630473, -0.04530025]
>>> Lperp = []
>>> if comm.rank == 0:
>>> Lperp = CalcPerpen(L)
>>> comm.barrier()
>>> Lperp = comm.bcast(Lperp, root=0)
>>> print "Lperp = ", Lperp
>>> # W is the width of the plot in enzo boxsize units
>>> # 1 would be the whole domain
>>> #
>>> SphereSize = 10000 #pc
>>> W = 0.05 #domain units
>>> N = 1024 # Pixels (512^2)
>>> up = [1.,0.,0.]
>>>
>>> #And zoom each time.
>>> startW = W
>>> endW = 1e-7
>>> deltaW = (startW - endW)/70
>>> rotation = 2*na.pi/70.0
>>>
>>>
>>> for pf in ts.piter():
>>> rank = comm.Get_rank()
>>> result_id = int(pf.parameter_filename[-4::])
>>> if(result_id > 70):
>>> continue
>>>
>>> filenum = result_id - firstoutputnum
>>> sp = pf.h.sphere("max", (SphereSize, "pc"))
>>> MaxDen, c = pf.h.find_max('Density')
>>> W = startW - filenum*deltaW
>>> le = c - W
>>> re = c + W
>>> rmi, rma = sp.quantities['Extrema']('Density')[0]
>>> rmi, rma = na.log10(rmi), na.log10(rma)
>>> print "File %s: Real min and max = (%f, %f)" %
>>> (pf.parameter_filename, rmi, rma)
>>> ma = rma - 2
>>> mi = rmi + 2.5
>>>
>>> # Construct transfer function, pad the TF space by a bit so that
>>> # gaussians sampling the data range don't hit the edge.
>>> tf = ColorTransferFunction((mi, ma))
>>> tf.add_layers(6, w=0.01, colormap="spectral")
>>> # Create the camera object
>>> cam = pf.h.camera(c, L, W, (N,N), transfer_function=tf,
>>> north_vector=L,
>>> no_ghost=True, steady_north=True)
>>> #Rotate about the "Lperp" vector
>>> theta = rotation*filenum
>>> cam.rotate(theta, rot_vector=Lperp)
>>>
>>>
>>>
>>>
>>>
>>> On 18 November 2013 20:10, Sam Skillman <samskillman at gmail.com> wrote:
>>>
>>>> Hi John,
>>>>
>>>> I'm a bit confused how this could be happening. Is it at all possible
>>>> that either c or Lperp are calculated differently for different timesteps?
>>>> My only other thought would be that somehow Lperp is very close to the
>>>> north_vector, and some dot products over time are building up some sort of
>>>> error.
>>>>
>>>> If c isn't changing as a function of timestep, could you paste more/all
>>>> of your script just in case there's another piece that's messing around
>>>> with things?
>>>>
>>>> Best,
>>>> Sam
>>>>
>>>>
>>>> On Mon, Nov 18, 2013 at 7:13 AM, John Regan <johnanthonyregan at gmail.com
>>>> > wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> Just a quick question on rotation of the camera object. When I rotate
>>>>> the camera I notice that the
>>>>> center no longer stays at the focus. I'm running a script which zooms
>>>>> and rotates an object in a timeseries fashion.
>>>>>
>>>>> # Code snippet
>>>>> cam = pf.h.camera(c, L, W, (N,N), transfer_function=tf,
>>>>> north_vector=up,
>>>>> no_ghost=True, steady_north=True)
>>>>> #Rotate about the "Lperp" vector
>>>>> theta = rotation*filenum
>>>>> cam.rotate(theta, rot_vector=Lperp)
>>>>>
>>>>>
>>>>> This pretty much works as I want but after a while a get an output
>>>>> like the one attached with the central density no longer at the center. Is
>>>>> there a way to keep the focus at "c".
>>>>>
>>>>> Cheers,
>>>>> John
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>>
>
> _______________________________________________
> 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/20131118/4077c07e/attachment.html>
More information about the yt-users
mailing list