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.

[hkershaw-brown]

Note there are perturb routines that assume state variables are contiguous var = state(startindex:endindex)