[yt-users] light ray woes

Britton Smith brittonsmith at gmail.com
Fri May 27 11:40:22 PDT 2016 

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

More information about the yt-users mailing list