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@gmail.com
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....
Cameron
On Wed, May 25, 2016 at 1:47 PM, Stephanie Tonnesen
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@gmail.com
_______________________________________________ yt-users mailing list yt-users@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
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
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....
Cameron
On Wed, May 25, 2016 at 1:47 PM, Stephanie Tonnesen
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@gmail.com
_______________________________________________ yt-users mailing list yt-users@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
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@gmail.com
On Thu, May 26, 2016 at 4:20 AM, Britton Smith
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
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....
Cameron
On Wed, May 25, 2016 at 1:47 PM, Stephanie Tonnesen
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@gmail.com
_______________________________________________ yt-users mailing list yt-users@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@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
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
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@gmail.com
On Thu, May 26, 2016 at 4:20 AM, Britton Smith
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
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....
Cameron
On Wed, May 25, 2016 at 1:47 PM, Stephanie Tonnesen
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@gmail.com
_______________________________________________ yt-users mailing list yt-users@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@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
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@gmail.com
On Fri, May 27, 2016 at 6:27 AM, Britton Smith
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
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@gmail.com
On Thu, May 26, 2016 at 4:20 AM, Britton Smith
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
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....
Cameron
On Wed, May 25, 2016 at 1:47 PM, Stephanie Tonnesen
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@gmail.com
_______________________________________________ yt-users mailing list yt-users@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@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
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
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@gmail.com
On Fri, May 27, 2016 at 6:27 AM, Britton Smith
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
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@gmail.com
On Thu, May 26, 2016 at 4:20 AM, Britton Smith
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
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....
Cameron
On Wed, May 25, 2016 at 1:47 PM, Stephanie Tonnesen
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@gmail.com
_______________________________________________ yt-users mailing list yt-users@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@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
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@gmail.com
On Fri, May 27, 2016 at 11:40 AM, Britton Smith
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
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@gmail.com
On Fri, May 27, 2016 at 6:27 AM, Britton Smith
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
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@gmail.com
On Thu, May 26, 2016 at 4:20 AM, Britton Smith
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
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....
Cameron
On Wed, May 25, 2016 at 1:47 PM, Stephanie Tonnesen < stonnes@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@gmail.com > > _______________________________________________ > yt-users mailing list > yt-users@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@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
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
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@gmail.com
On Fri, May 27, 2016 at 11:40 AM, Britton Smith
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
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@gmail.com
On Fri, May 27, 2016 at 6:27 AM, Britton Smith
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
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@gmail.com
On Thu, May 26, 2016 at 4:20 AM, Britton Smith
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
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.... > > Cameron > > On Wed, May 25, 2016 at 1:47 PM, Stephanie Tonnesen < > stonnes@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@gmail.com >> >> _______________________________________________ >> yt-users mailing list >> yt-users@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@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
-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
participants (3)
-
Britton Smith
-
Cameron Hummels
-
Stephanie Tonnesen