[yt-users] light ray woes

Stephanie Tonnesen stonnes at gmail.com
Fri May 27 13:37:49 PDT 2016 

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

More information about the yt-users mailing list