CompaSO reader needs to handle origin output which contains some extra information available to the user

[boryanah]

The value of the origin field in the LC catalogs tells both from which copy of the box the halo came (0, 1, 2) and also whether it was interpolated (i.e. there was available merger tree info for it) or whether its location was taken as is (which might suggest that the fields pos,vel_avg are more valuable than pos,vel_interp). Need to decide way to output this info to the user.

[boryanah]

@lgarrison I wanted to ask your opinion of this.
To explain what the problem is: the origin field can output values of 0, 1, 2, 3, 4, 5 for each halo where 0 and 3 refer to the LightConeOrigin0, 1 and 4 to LightConeOrigin1, and 2 and 5 to LightConeOrigin2. If origin > 2, then this halo did not have merger tree information and its position/velocity/mass (pos_interp/etc.) are simply x_L2com/etc. In the case of the huge simulations we have the values 0 and 3 having the same function.
There are two ways to address this:

1. The straightforward thing to do would be to get rid of that extra bit of info by outputting:
   table['origin'] = table['origin']%3 instead of just table['origin'] when reading halo light cone catalogs using the CompaSO reader, since this extra information was only used internally when creating the halo light cone catalogs.
2. However, it might be useful since for halos that were not interpolated (since there was no merger tree info), one might prefer to use the light-cone particle-averaged quantities (pos_avg, vel_avg) since the particle trajectories are interpolated even if the halo's isn't. So we could imagine getting rid of pos_avg and vel_avg (with a message to the user) and simply outputting pos_interp and vel_interp, which take the values of pos_avg and vel_avg when the halo trajectory is not interpolated (origin > 2). What do you think?

[Lehman Garrison]

I think providing the user with a flag to use option 2 makes a lot of sense! But just to understand what you're proposing:

• all halos have pos/vel_avg
• halos with merger info have pos/vel_interp, otherwise it's filled with a non-interpolated value
• the flag would fill pos/vel_interp with pos/vel_avg for halos without merger info

Did I get that right, or were you saying that pos/vel_interp already have pos/vel_avg as the default value if there is no merger info?

[boryanah]

You got it completely right! How should we add that flag? Does it make sense to just do that as the default and still keeping pos_avg, vel_avg as available outputs, but just by default substituting the pos_interp and vel_interp for halos with origin > 2?

[Lehman Garrison]

Sorry for the late reply on this, but yes, I think it would be fine to have a flag that does that by default.

[boryanah]

addressed in branch fix-periodic