[Feature Req.] Ability to access all perturbed velocity components (also alternate line-of-sight direction)

[BradGreig]

Is your feature request related to a problem? Please describe.
Presently, lightcone quantities are fixed along the z-direction. Which means perturb_field.velocity can only return the z-component of the velocity. Related to #167.

Describe the solution you'd like
Obtaining all 3 components (x, y, z) of the perturbed velocity field should be accessible. However, it is best to avoid having all 3 components accessible at all times (for memory reasons). Thus there should be an option to keep all three components when required, otherwise only keep the line-of-sight direction for constructing lightcones.

Equally, it should be theoretically possible to construct lightcones along any direction, not just the z-direction. Default should be the z-direction, but the user should have the ability to define the preferred direction, i.e. x-, y- or z- direction.

[steven-murray]

@BradGreig I thought there was already a global parameter for choosing the direction?

Definitely can optionally save all directions as part of our memory usage upgrades.

[BradGreig]

@steven-murray, the original 21cmFAST definitely had this option, however, it appears I didn't port that over (for whatever reason).

That is likely the most sensible way to do it (in regard to choosing line-of-sight direction). However, we will have to make sure this is accurately applied throughout the code. For example, in _interpolate_in_redshift and application of subcell RSDs we need to make sure the correct axis is being interpolated along (and possibly others, but I'll need to double check).

[steven-murray]

I'm thinking the best place to put the option is in `user_params` -- does that make sense? And yeah, we'll have to be careful in all the functions.

…

On Mon, Sep 21, 2020 at 5:42 PM BradGreig ***@***.***> wrote: @steven-murray <https://github.com/steven-murray>, the original 21cmFAST definitely had this option, however, it appears I didn't port that over (for whatever reason). That is likely the most sensible way to do it (in regard to choosing line-of-sight direction). However, we will have to make sure this is accurately applied throughout the code. For example, in _interpolate_in_redshift and application of subcell RSDs we need to make sure the correct axis is being interpolated along (and possibly others, but I'll need to double check). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#168 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJWRXTSG22TAVDI2NWY5MLSG7XHJANCNFSM4RPXRKPQ> .

[BradGreig]

Are you talking of one or two options (one for line-of-sight direction and one for keeping all velocity components). I'd like to try and limit too many options, preferring the same functionality with less options. If that makes sense.

[steven-murray]

I guess it would need two options. Perhaps the option to keep all vel components could be an extra standalone parameter?

…

On Tue, Sep 22, 2020 at 6:12 PM BradGreig ***@***.***> wrote: Are you talking of one or two options (one for line-of-sight direction and one for keeping all velocity components). I'd like to try and limit too many options, preferring the same functionality with less options. If that makes sense. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#168 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJWRXS5O5J6WWXCW3BVIX3SHFDOZANCNFSM4RPXRKPQ> .

[BradGreig]

I suspect these may be less frequently used that other options. Thus, should they be in UserParams or are they better served in the global_params? I was under the impression that less frequently used things should be in global_params.

[steven-murray]

I would overall like to keep as many options *out* of `global_params` as possible. They are harder to deal with overall, in terms of caching. I do think that there's place for some global params for parameters that are really hardly ever used, or are extremely arcane. Maybe this fits into that category. But I think these are easy to understand. It doesn't hurt to have extra parameters in the parameter structs, as long as they are not overlapping or inter-dependent. If they are easy to understand, and self-contained, I think it's fine to have a whole list of them (as long as they're well documented).

[BradGreig]

Ok, no problems, if that is the logic of the UserParams/global_params divide then two additional flags makes sense to me.