- Mail actions: [ respond to this message ] [ mail a new topic ]
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]

From: Volker Springel <vspringel_at_MPA-Garching.MPG.DE>

Date: Mon, 9 May 2022 21:52:12 +0200

Dear Yucheng,

Let me perhaps first try to clarify the type=3 lightcone option. This is still a normal lightcone in the sense that all particles you get are at locations where they are overrun by the spherical backwards light-surface with respect to a fiducial observer position. The collection of all these particles in comoving coordinates (out to some maximum redshift) would fill a spherical ball around the fiducial observer. Keeping them all would give you an all-sky redshift survey, keeping only a cone gives you a pencil beam, and cutting everything away except for a disk-like region in comoving coordinates is what type=3 yields. This is mostly interesting for visualization purposes only.

Sure, you could create a fiducial lightcone in which light propagation is treated as parallel in the way you imagine. This could be accomplished by modifying/replacing the functions lightcone_test_for_particle_addition() and lightcone_is_cone_member_basic(). The code to setup the BoxList[] array should also be changed to only enumerate the replicas that are needed in this case. I think such a thing might perhaps be most useful for simulations where a light cone output already stops at high redshift, for example for simulations studying cosmic reionization. If the simulation box covers only a small viewing angle at high z, then the parallel approximation would be natural and could be realized much more efficiently than the spherical lightcone.

Best,

Volker

*> On 15. Apr 2022, at 06:46, Yucheng Zhang <yucheng.zhang_at_nyu.edu> wrote:
*

*>
*

*> Dear Volker and Gadget users,
*

*>
*

*> I have been wondering if it's possible to generate lightcone output with a flat backward surface (i.e. assuming that light travels in parallel to a certain direction instead of a point observer)?
*

*> In the documentation, the type=3 (disk) seems to be a similar option but I'm a bit confused about what's the relation between (a_start, a_end) and the additional thickness parameter.
*

*>
*

*> The reason this might be useful is that we can then run the simulation in a long box assuming that the lightcone backward surface is moving from one end to the other.
*

*> Then the output lightcone is simply the same box including all the particles with the long side being the redshift.
*

*> Compared to pencil beams, in some discussions where geometry is not very important, this simplification could be more efficient.
*

*>
*

*> Thanks in advance for any help or suggestions!
*

*>
*

*> Best regards,
*

*> Yucheng
*

*>
*

*>
*

*> --
*

*> Yucheng Zhang
*

*> Ph.D. Candidate | CCPP | Physics | NYU
*

*>
*

*> -----------------------------------------------------------
*

*>
*

*> If you wish to unsubscribe from this mailing, send mail to
*

*> minimalist_at_MPA-Garching.MPG.de with a subject of: unsubscribe gadget-list
*

*> A web-archive of this mailing list is available here:
*

*> http://www.mpa-garching.mpg.de/gadget/gadget-list
*

Received on 2022-05-09 21:52:13

Date: Mon, 9 May 2022 21:52:12 +0200

Dear Yucheng,

Let me perhaps first try to clarify the type=3 lightcone option. This is still a normal lightcone in the sense that all particles you get are at locations where they are overrun by the spherical backwards light-surface with respect to a fiducial observer position. The collection of all these particles in comoving coordinates (out to some maximum redshift) would fill a spherical ball around the fiducial observer. Keeping them all would give you an all-sky redshift survey, keeping only a cone gives you a pencil beam, and cutting everything away except for a disk-like region in comoving coordinates is what type=3 yields. This is mostly interesting for visualization purposes only.

Sure, you could create a fiducial lightcone in which light propagation is treated as parallel in the way you imagine. This could be accomplished by modifying/replacing the functions lightcone_test_for_particle_addition() and lightcone_is_cone_member_basic(). The code to setup the BoxList[] array should also be changed to only enumerate the replicas that are needed in this case. I think such a thing might perhaps be most useful for simulations where a light cone output already stops at high redshift, for example for simulations studying cosmic reionization. If the simulation box covers only a small viewing angle at high z, then the parallel approximation would be natural and could be realized much more efficiently than the spherical lightcone.

Best,

Volker

Received on 2022-05-09 21:52:13

*
This archive was generated by hypermail 2.3.0
: 2022-09-01 14:03:43 CEST
*