Save memory by using int32 for connectivity instead of int64 or np.intp?

[Sevans711]

It may be possible to save a significant amount of memory if connectivity variables are stored as int32 instead of int64. Right now it looks like the default for connectivity is INT_DYPE = np.intp, which resolves to np.int64 on 64-bit machines, and np.int32 on 32-bit machines.

int32 can store values up to roughly 2.1 billion, which is likely sufficient even in most (all?) large use cases. Could also check something like "are there <2.1 billion faces, nodes, and edges? If yes, use int32, else use int64" to be safe. For reference, the 3km MPAS grid has roughly 65 million faces, which should fit comfortably into int32.

Advantages of int32:

• Cut memory costs in half for connectivity variables. Every grid has at least one of these (e.g. face_node_connectivity) and it is usually has a sizeable memory cost due to having two dimensions (e.g. n_face, n_max_face_nodes)

Possible disadvantages:

• It looks like using an integer array directly for indexing in numpy type casts to np.intp if not already that type (e.g.: mydata[grid.face_node_connectivity] casts grid.face_node_connectivity to int64 on 64-bit machines). Although, indexing by connectivity directly is tricky anyway since faces have differing numbers of nodes. I think most internal uxarray code uses numba when utilizing connectivity variables, not numpy indexing. I believe numba wouldn't do any surprising type-casting like this.
• Code might get more complicated, with branching logic for "fits in int32" versus "needs int64".

Questions:

1. Is there any interest in swapping to int32 instead of forcing int64?
2. Does uxarray already use int32 for large grids sometimes? It is hard for me to tell. In the example grids I've worked with so far at least, it looks like connectivity data has always been int64.
3. If implementing this, should it be enabled by default or opt-in with some global options (e.g., something like uxarray.set_options(connectivity_can_use_int32=True))?
4. I noticed that INT_FILL_VALUE is derived from INT_DTYPE will be different on 32 bit and 64 bit machines. Is this behavior expected or surprising?

[cmdupuis3]

I think it's a good idea, or at least to have INT_DTYPE = np.intp as a default package option. I doubt ultra-high res situations are happening often, int64 would only be needed below 1km or so. Or are we worried about multi-D cases or something?

INT_FILL_VALUE is basically a NaN when I've seen it. If it's being set to 1 or something, that's dangerous.