There should be a cosmo_quantity analog to unyt_quantity

[kyleaoman]

Many of the unyt_array functions can return a unyt_quantity in at least some circumstances. For a cosmo_array, this leads to the extra attributes being silently dropped, and then potential unexpected results or errors when trying to access those or use the resulting unyt_quantity in a calculation where the user expected a cosmo_array-like output.

[JBorrow]

Hmm, interesting. The unyt quantity is actually just an unyt array with one element by a different name. Good suggestion but I don't know how we'd get the functions inside unyt to return our Cosmo-Ised versions

[kyleaoman]

I think it's not too difficult. I believe you have to wrap the functions one by one, but for the most part can be done with generic wrappers. Pretty sure unyt itself has to do pretty much the same thing with many of the numpy functions to make sure they return with units attached, maybe that could serve as a template. It's a bit of a long and tedious job, but should probably be done at some point.

[MatthieuSchaller]

How would you handle quantities with the same units but that transform differently? for instance velocities and sound speed?

[kyleaoman]

The transformation thing is I think a separate issue? This is just about having a scalar equivalent (cosmo_quantity) to the array type (cosmo_array).

[MatthieuSchaller]

You are right indeed; it's a separate problem.

[jchelly]

It would definitely be good to fix this. I've been trying to use cosmo_arrays to compute halo properties but many operations cause them to decay to unyt_arrays (e.g. functions returning scalars, as Kyle found) or lose their cosmo_factor and comoving attributes - e.g. np.sum, np.max, or arithmetic on arrays or array sections.

[jchelly]

Another approach would be to try to deal with factors of a just using the facilities provided by unyt so we don't need a sub class. We could make a dimensionless unit 'a' and include it in the units returned by swiftsimio, although reading multiple snapshots might be a problem then. Maybe each snapshot would need a separate unit system/registry so that a can have a different value?

[JBorrow]

The reason that we have a separate cosmo_array quantity, rather than using the usual a as a dimensionless unit, is to keep track of it when we've taken it away. So you can convert something to physical, and then back to co-moving. This then nicely also avoids the issues of things like needing separate unit registries for different snapshots.

I agree though, that having a cosmo_quantity analogue would be good.

[jchelly]

Ok, thanks, I hadn't thought of that. I knew there had to be a reason why you didn't do it that way.