[yt-users] light ray woes

Cameron Hummels chummels at gmail.com
Sun May 29 07:31:08 PDT 2016 

I'm traveling right now, but I may have time to look at this prior to
Britton's return.  I was going to delve into the LightRay infrastructure
this week anyway, so I can attempt to allow elongated traversals too.  I'll
keep you both up to date if things on this progress.

Cameron

On Fri, May 27, 2016 at 4:37 PM, Stephanie Tonnesen <stonnes at gmail.com>
wrote:

> Hi Britton,
>
> I might end up waiting for you and work on some other things, although if
> I decide to dive in I will send an email letting people know.
>
> Enjoy your holiday!
>
> Best,
> Stephanie
>
>
> --
> Dr. Stephanie Tonnesen
> Alvin E. Nashman Postdoctoral Fellow
> Carnegie Observatories, Pasadena, CA
> stonnes at gmail.com
>
> On Fri, May 27, 2016 at 11:40 AM, Britton Smith <brittonsmith at gmail.com>
> wrote:
>
>> Hi Stephanie,
>>
>> Ah yes, I meant to mention the error message and totally forgot.  I
>> completely agree, it's not at all informative in the way it should be.  We
>> should definitely fix this.
>>
>> As for changing yt to allow sub-segments longer than the box, this seems
>> worth doing.  I would be happy to take a crack at it, but I'm just now
>> heading off on a two week holiday.  I can have a look when I get back, but
>> if you or anyone else would like to check it out, please feel free.  I may
>> be able to provide some assistance while I'm away, but probably somewhat
>> infrequently.
>>
>> Britton
>>
>> On Fri, May 27, 2016 at 5:50 PM, Stephanie Tonnesen <stonnes at gmail.com>
>> wrote:
>>
>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>
>


-- 
Cameron Hummels
NSF Postdoctoral Fellow
Department of Astronomy
California Institute of Technology
http://chummels.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20160529/76249e3f/attachment.html>

More information about the yt-users mailing list