Model_mods which use their own structure to keep track of state variables

[hkershaw-brown]

progvar type:
* mpas_ocn (does not compile)
* mpas_atm
* NCOMMAS (does not compile)
* NAAPS (does not compile)

• wrf has type wrf_static_data_for_dart

• wrf_hydro is making assumptions about the indexing.

• clm has metadata arrays that are the same size as the state:
  607 allocate(lonixy(model_size), latjxy(model_size), levels(model_size), landarea(model_size))
  this you don't want to access with dart_index (i.e. assume the state structure), but instead f(x,y,z,variable).
  Same for the small models have state-length metadata storage. Any model that adds a domain like this dom_id = add_domain(model_size). 9-var has unpack9var.

hot take: I don't think model_mods should have access to dart_index at all.

Some models have their own get_varid_from_kind
POP
CICE
bgrid_solo

I think you can flush out if a non-toy model_mod is assuming the state order by reversing the order of the variables in the state_structure_mod. i = num_vars, 1, -1, run filter/model_mod_check/whatever and seeing if your results change.

Who cares?

Possible reasons to care:

• General implementation of squished state (Ed's siparcs 2022) project
• Remove missing_r8 from the state so assim_tools, quad_utils can assume all state is valid.
  - same across the ensemble, e.g. POP
  - different across the ensemble, e.g. CLM
  I don't think ensemble manager can stop checking for missing_r8 because a missing_r8 result for a forward operator is valid.
• For wrf, adding a new quantity means updating the model_mod.