StephanieBest,Enjoy your holiday!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.stonnes@gmail.comCarnegie Observatories, Pasadena, CA--Alvin E. Nashman Postdoctoral Fellow
Dr. Stephanie TonnesenOn Fri, May 27, 2016 at 11:40 AM, Britton Smith <brittonsmith@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.BrittonOn Fri, May 27, 2016 at 5:50 PM, Stephanie Tonnesen <stonnes@gmail.com> wrote:StephanieThanks again for looking at this,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!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.stonnes@gmail.comCarnegie Observatories, Pasadena, CA--Alvin E. Nashman Postdoctoral Fellow
Dr. Stephanie TonnesenOn Fri, May 27, 2016 at 6:27 AM, Britton Smith <brittonsmith@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:I get this as the ideal redshift spacing to never exceed one box length:CosmologyOutputRedshift[0] = 0.400CosmologyOutputRedshift[1] = 0.352CosmologyOutputRedshift[2] = 0.306CosmologyOutputRedshift[3] = 0.261CosmologyOutputRedshift[4] = 0.217CosmologyOutputRedshift[5] = 0.174CosmologyOutputRedshift[6] = 0.132It 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.BrittonOn Thu, May 26, 2016 at 5:29 PM, Stephanie Tonnesen <stonnes@gmail.com> wrote:StephanieThank you for looking into this!See attached. Just in case, I am also attaching the redshiftoutput file that I used.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.stonnes@gmail.comCarnegie Observatories, Pasadena, CA--Alvin E. Nashman Postdoctoral Fellow
Dr. Stephanie TonnesenOn Thu, May 26, 2016 at 4:20 AM, Britton Smith <brittonsmith@gmail.com> wrote:Hi Stephanie,Could you send along the Enzo parameter file that you're using with this light ray?BrittonOn Thu, May 26, 2016 at 4:41 AM, Cameron Hummels <chummels@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_rayCameronOn Wed, May 25, 2016 at 1:47 PM, Stephanie Tonnesen <stonnes@gmail.com> wrote:_______________________________________________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.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)I do only have redshift dumps to work with, but I think that those should be used since redshift_data=TrueDoes anyone have any advice for making this work?Thanks,Stephaniestonnes@gmail.comCarnegie Observatories, Pasadena, CA--Alvin E. Nashman Postdoctoral Fellow
Dr. Stephanie Tonnesen
yt-users mailing list
yt-users@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
--Cameron HummelsNSF Postdoctoral FellowDepartment of AstronomyCalifornia Institute of Technology
_______________________________________________
yt-users mailing list
yt-users@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________
yt-users mailing list
yt-users@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________
yt-users mailing list
yt-users@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________
yt-users mailing list
yt-users@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________
yt-users mailing list
yt-users@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________
yt-users mailing list
yt-users@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________
yt-users mailing list
yt-users@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org