[yt-users] light ray woes

Fri May 27 09:50:06 PDT 2016

Hi Britton,

I suspected that this would be a problem, I just expected the error to say
something like "the spacing has to be 0.048 and we find the spacing between
data dumps to be 0.05" instead of the 0.048 and 0.3 that the error message
states.

This is a very expensive run, so unfortunately, rerunning is not an option
for me.  I, personally, vote YES to allowing the ray sub-segments to be
longer than the box!

Thanks again for looking at this,

Stephanie

--
Dr. Stephanie Tonnesen
Alvin E. Nashman Postdoctoral Fellow
Carnegie Observatories, Pasadena, CA
stonnes at gmail.com

On Fri, May 27, 2016 at 6:27 AM, Britton Smith <brittonsmith at gmail.com>
wrote:

> Hi Stephanie,
>
> I've looked into this and the main issue is that the combination of the
> box size and the spacing of the datadumps is not sufficient to traverse the
> redshift interval from z = 0.4 to z = 0.1 without letting the ray
> sub-segments be longer than the length of the box.  When this part of the
> code was first built, it seemed imperative that ray sub-segments never be
> longer than one box length so as to avoid sampling the same structure more
> than once.  This could probably be relaxed a bit since ray trajectories
> aren't typically aligned with the axes, but this is currently what the code
> is doing.
>
> For your simulation, the box is only just a bit too small.  Running the
> following script:
> http://paste.yt-project.org/show/6565/
> I get this as the ideal redshift spacing to never exceed one box length:
> CosmologyOutputRedshift[0] = 0.400
> CosmologyOutputRedshift[1] = 0.352
> CosmologyOutputRedshift[2] = 0.306
> CosmologyOutputRedshift[3] = 0.261
> CosmologyOutputRedshift[4] = 0.217
> CosmologyOutputRedshift[5] = 0.174
> CosmologyOutputRedshift[6] = 0.132
>
> It gets worse as you go to lower redshift, but not by much.  As to what to
> do about this, if the simulation is too expensive to re-run with the above
> outputs, then the only thing to do would be to allow the code to make
> sub-segments that are longer than the box length.  Before this happens,
> it's probably worth discussing whether or not this is a good idea.  Would
> people like to see this change made?
>
> Finally, as for the outputs appearing to be grabbed out of order, that is
> yt figuring out which datasets actually exist on disk through a glob
> operation.  This is triggered with the find_outputs=True keyword, but it's
> not a problem.  Once yt figures out what datasets are out there, it resorts
> the list by time/redshift.
>
> Britton
>
>
> On Thu, May 26, 2016 at 5:29 PM, Stephanie Tonnesen <stonnes at gmail.com>
> wrote:
>
>> OH yeah, that is the other funky thing about what I am doing...(I am
>> rolling my eyes at myself for not mentioning this right away...)
>>
>> I am using another person's enzo run, and he cannot find the parameter
>> file.  I made one as best as I could from copying a redshift output into
>> what I thought the format should be, but there could be some problems
>> there.
>>
>> See attached.  Just in case, I am also attaching the redshiftoutput file
>> that I used.
>>
>> Thank you for looking into this!
>>
>> Stephanie
>>
>> --
>> Dr. Stephanie Tonnesen
>> Alvin E. Nashman Postdoctoral Fellow
>> Carnegie Observatories, Pasadena, CA
>> stonnes at gmail.com
>>
>> On Thu, May 26, 2016 at 4:20 AM, Britton Smith <brittonsmith at gmail.com>
>> wrote:
>>
>>> Hi Stephanie,
>>>
>>> Could you send along the Enzo parameter file that you're using with this
>>> light ray?
>>>
>>> Britton
>>>
>>> On Thu, May 26, 2016 at 4:41 AM, Cameron Hummels <chummels at gmail.com>
>>> wrote:
>>>
>>>> Stephanie,
>>>>
>>>> It looks like there are two problems you're encountering.  One, you're
>>>> trying to include a field "velocity", when there is no such field in your
>>>> dataset, only 3 scalar fields for "velocity_x", "velocity_y"...  These will
>>>> be included by default when you set use_peculiar_velocity=True as you are
>>>> doing.  So for one, remove the velocity field from your list of fields.
>>>> The second problem, as you quite rightly identify, is that yt is messing up
>>>> the order that it's getting the redshifts of the outputs, so it's jumping
>>>> straight from 0.4 to 0.1.  I can't dig into the code right now to see why
>>>> it is ordering it weirdly, but I might be able to look at it in the next
>>>> day or two.  Britton may also have an idea on what is going on here.
>>>>
>>>> Also of note is that there are some nice wrapper functions on the
>>>> LightRay functionality in the new Trident code.  In particular, the
>>>> make_compound_ray function wraps this cleanly.  That said, it will not fix
>>>> this problem, as it is just using the underlying yt LightRay
>>>> infrastructure:
>>>> http://trident.readthedocs.io/en/latest/generated/trident.make_compound_ray.html#trident.make_compound_ray
>>>>
>>>> Cameron
>>>>
>>>> On Wed, May 25, 2016 at 1:47 PM, Stephanie Tonnesen <stonnes at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am trying to make a light ray using a few redshift outputs from
>>>>> z=0.4 to z=0.1.  Right now I just have two commands in my code taken
>>>>> basically directly from the docs:
>>>>>
>>>>> lr = LightRay("CBOX.enzo",simulation_type="Enzo",near_redshift=0.1,
>>>>>
>>>>> far_redshift=0.4,time_data=False,redshift_data=True,find_outputs=True)
>>>>>
>>>>>
>>>>> lr.make_light_ray(seed=8934876,fields=['temperature','density','velocity'],use_peculiar_velocity=True)
>>>>>
>>>>> My current problem is that the first command "LightRay" doesn't seem
>>>>> to be using any of my outputs between 0.4 and 0.1!  I am attaching the
>>>>> error file, and you can see that it finds 9 outputs, 7 of which are between
>>>>> and including 0.4 to 0.1.  However, then it claims that I am asking it to
>>>>> go straight from 0.399996 to 0.1.
>>>>>
>>>>> I do only have redshift dumps to work with, but I think that those
>>>>> should be used since redshift_data=True
>>>>>
>>>>> Does anyone have any advice for making this work?
>>>>>
>>>>> Thanks,
>>>>> Stephanie
>>>>> --
>>>>> Dr. Stephanie Tonnesen
>>>>> Alvin E. Nashman Postdoctoral Fellow
>>>>> Carnegie Observatories, Pasadena, CA
>>>>> stonnes at gmail.com
>>>>>
>>>>> _______________________________________________
>>>>> yt-users mailing list
>>>>> yt-users at lists.spacepope.org
>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Cameron Hummels
>>>> NSF Postdoctoral Fellow
>>>> Department of Astronomy
>>>> California Institute of Technology
>>>> http://chummels.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/20160527/99b80030/attachment.html>