Use case

Refactor the wrf model_mod to make it easier/possible to:

• add state variables
• swap between wrf v3 and v4
• not assume the structure of the state variable in model_mod.

Is your feature request related to a problem?

The WRF model_mod has wrf_static_data_for_dart which is replicating functionality available in state_structure_mod.

• Adding variable X to the state means altering the model_mod code to have a wrf%dom(id)%type_X, rather than simply adding a line in the model_nml::wrf_state_variables.

• WRF has its own integer types (qtys), replicating (but not quite) the DART qty functionality.
  

  DART/models/wrf/model_mod.f90

  Lines 323 to 332 in 7ee9ed9

  	! JPH local variables to hold type indices
  	integer :: type_u, type_v, type_w, type_t, type_qv, type_qr, type_hdiab, &
  	type_qndrp, type_qnsnow, type_qnrain, type_qngraupel, type_qnice, &
  	type_qc, type_qg, type_qi, type_qs, type_gz, type_refl, type_fall_spd, &
  	type_dref, type_spdp, type_qh, type_qnhail, type_qhvol, type_qgvol, &
  	type_cldfra
  	integer :: type_u10, type_v10, type_t2, type_th2, type_q2, &
  	type_ps, type_mu, type_tsk, type_tslb, type_sh2o, &
  	type_smois, type_2dflash

  
  so you see code like this:
  

  DART/models/wrf/model_mod.f90

  Lines 889 to 890 in 7ee9ed9

  	var_type = wrf%dom(id)%var_type(var_id)
  	dart_type = wrf%dom(id)%dart_kind(var_id)

• WRF v3 vs. v4 - it is not clear for users what to change when moving from WRF v3 to v4. If possible, it would be good for the model_mod to be able to check the WRF version from the netcdf file.

• Wider issue Model_mods which use their own structure to keep track of state variables #389. Moving control of the state vector to core dart modules allows us to have general solutions for things like compression, removing missing values (so dart core code can assume every element of the state is valid), and other cool stuff.

Describe your preferred solution

Remove the state vector information from wrf_static_data_for_dart

Describe any alternatives you have considered

I think the wrf_static_data_for_dart is a road block for core dart development, however wrf-dart is widely used and has a lot of additional user developed code in circulation. There is 8000 lines of code in for wrf model_mod (+ unknown user modifications) so the refactoring needs to be approached with this in mind.
I think it is possible to simplify the bounds checks for each grid (staggered and various flavors of periodic), but I do not think the bounds check affects development of core dart.