[yt-users] cam.rotate

Sam Skillman samskillman at gmail.com
Mon Nov 18 11:42:50 PST 2013


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20131118/28f62f2f/attachment.html>


More information about the yt-users mailing list