mpas skin temperature and seaice interpolation

[timhoar]

I was reviewing a pull request and noticed that the mpas_atm/model_mod.f90:model_interpolate() routine uses the skintemp variable that is read from the mpas 'shapefile' (the file specified by init_template_filename in the namelist). Ditto for seaice. That doesn't seem right to me. I would have guessed those variables are not the same for all ensemble members. Maybe seaice could be constant - if the same ocean file was used for the forcing of all ensemble members.

seaice and skintemp are read in the get_grid() routine, rather than as part of the extended state.

call compute_surface_data_with_barycentric(skintemp(:), location, expected_obs(1), istatus(1))

seaice is used in the get_surftype routine.

[nancycollins]

from soyoung:

You know, mpas/atmosphere_model is not coupled with the 'ocean' or the 'seaice' core (in the mpas model framework), so seaice is not changing. But it looks like skintemp evolves with time and across members, so Tim is right, we may need to pull it out of get_grid.

I guess that means we need to put it in the mpas_state_variables in &mpas_vars_nml?

this is a comment from nancy:

we might want to look at reading seaice from member 1 or (simpler) adding seaice to the model state and mark it as noupdate so it isn't written back. we generally do not use any data from the template file, so users might be surprised if they're using a template file that has a different seaice field compared to the ensemble members. (not sure if that's possible.)

[nancycollins]

from soyoung:

I've thought about this overnight and realized that we may need something better than just pulling skintemp out of get_grid.
In WRF/DART, we've had "replace_wrf_fields" to be able to update surface fields once in a while for long-enough cycling, and that's what we want in mpas/dart as well, especially for high-resolution and/or long cycling.
On the model side, MPAS has config_sst_update, which updates not only sst, but also xice, which is a fractional float number for ice fraction, as opposed to seaice that is a 0-or-1 flag.
So if users choose config_sst_update in the model, they may want to update sst and xice in the cycling as well. For such a case, as WRF is doing a similar thing, we've had "update_sst_in_tsk" in WRF_DART_utilities/ before, but I cannot find it any more. Not sure why that was deleted.
Anyhow, I feel like we should be able to update a dozen of surface fields including skintemp and for that, I may need to add another module like "update_surface_fields" as part of "update_mpas_state". I can quickly do it sometime later this week, if there's no objection from you guys. Any comments?

(edit to fix missing letter)

[nancycollins]

i thought that wrf updated those fields with the program you mentioned - replace_wrf_fields - because the file format is netcdf, so it's easy to move a field from one file to the other. in fact, that program is just an alternative to running some of the nco tools - but it had more specific error checking and was namelist driven so it integrated with the rest of the programs a bit more. i don't remember any update_sst_in_tsk program - maybe that was part of the mpas or jedi distribution?

[syha]

I think it's better to handle the update of surface fields in fortran based on an additional switch in namelist, than using "nco" commands. As update_mpas_state is already updating the restart file for each member, it would be efficient to call "update_surface_fields" inside the program, again based on the namelist switch, to update the restart file for all.
One issue to which we need to pay more attention is how to update "skintemp". We cannot simply update the whole field by updating it from say, GFS analysis, in the template file for all members, because we want to update it with sst only over the ocean. Even if we include the field in the dart's state vector, we don't have any obs to constrain it, so it runs freely over the cycles. Now we want to update it partially, meaning that we update it only once a while (e.g. once a day) and only over the ocean with the updated sst in the updated template file.
So what I'm proposing is basically to handle all the surface fields in one place named "update_surface_fields", as part of "update_mpas_states", taking care of such difference cases all at once. And I can easily modify the driver script to update the template file once a while.

[hkershaw-brown]

Converting this issue to a discussion.