`coordinate_field` returns a reference to the coordinates, so modifying the resulting Field modifies the underlying space

[Sbozzolo]

using ClimaCore.CommonSpaces
using ClimaCore.Fields
space = ExtrudedCubedSphereSpace(;
           z_elem = 10,
           z_min = 0,
           z_max = 1,
           radius = 10,
           h_elem = 10,
           n_quad_points = 4,
           staggering = CellFace()
       )
field = Fields.coordinate_field(space)
fill!(field.z, NaN)

all(isnan, parent(space.grid.face_local_geometry.coordinates.z))
# true

I mean, I guess it makes sense considering how Fields are created, but I think this is dangerous.

I personally often use Fields.coordinate_field as a starting point to create new Fields (in particular, when I want to evaulate an analytical function of the coordinates) and I wasn't expecting that modifying this Field would change the underlying space.

At minimum, this should be documented.

[charleskawczynski]

I don't think that we want that function to create a copy-- it's a pointer to a field that is stored in the space, and users should not manipulate it.

The only thing that I can think of doing would be to wrap our space fields in a ReadOnlyArray, from ReadOnlyArrays.jl, but this seems a bit extreme, and would introduce another layer of abstraction.

Perhaps we should just improve our documentation on how to create arrays, and that getting things like coordinate_field and local_geometry_field gets pointers to fields in the space (and not copies)?

[Sbozzolo]

I agree that we should not create copies.

I don't think that we want that function to create a copy-- it's a pointer to a field that is stored in the space, and users should not manipulate it.

The docstring says

Construct a `Field` of the coordinates of the space.

It is really not clear that this returns a view of the space properties.

I think that this should be framed as an accessor

[charleskawczynski]

Yeah, that definitely needs to be fixed