There are various variables in the model that are only needed over certain landunits - e.g., patch-level variables only needed for crop patches, or variables only needed for urban. We could save memory by only allocating these variables over the landunits where they apply.

This should be possible, given the way memory is currently allocated for subgrid arrays: Each landunit is grouped together (rather than each gridcell being grouped together). However, note that this approach would no longer be feasible if we went back to the way this was done until a few years ago, where all landunits for gridcell 1 appeared first, then all landunits for gridcell 2, etc.; this tie-in to the current memory allocation is a possible argument against doing this.

I don't think anything would need to change in the body of science code to accommodate this: As long as code operates over filters that only include applicable points, then things should work the same if arrays are allocated with more restrictive bounds. However, care will be needed when specifying the lower bounds of arrays that are arguments to subroutines. One way to assist with this would be to add to the current variable suffix (_patch, _col, etc.) a designator specifying the first and last landunits over which this variable applies (if not landunit 1): e.g., _patch2_2 for crop-only variables, _lun7_9 for urban-only variables (landunit 7 is the first urban landunit), etc. The bounds object would be extended to have beg & end bounds for each landunit type.

One challenging part of this is handling output to history files and restart files, along with infrastructure like p2g that expects to have a full-extent array. I'm not sure off-hand how to handle that, but we could probably make this work by adding optional arguments to generic routines that give the starting and ending bounds of arrays.

I'm not sure if this is worth doing: it will take a fair amount of effort, so this only seems worthwhile if we have a lot of variables like this, and/or memory limitation is becoming a concern. This might have some small benefit in terms of time-efficiency, because our performance often seems memory-bound, but since we already order memory by landunit, I expect the time benefit to be small.