[yt-users] cam.rotate
John Regan
johnanthonyregan at gmail.com
Mon Nov 18 11:46:00 PST 2013
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20131118/8cd9d7d5/attachment.htm>
More information about the yt-users
mailing list