Dear WRF support team,
I am running WRF simulations over the Arctic for the period from 2020-06-01 00:00 UTC to 2020-07-29 23:00 UTC. My analysis focuses on the MOSAiC observation trajectory, which was located over sea ice during this period.
I extracted SST and TSK from the WRF output by nearest-neighbor matching the d02 wrfout fields to the hourly MOSAiC observation locations. The MOSAiC expedition was a drifting observational campaign based on a research vessel frozen into Arctic sea ice, so the observation sites were located on and moved with the sea ice. After interpolation to the MOSAiC trajectory, I found that both SST and TSK show very little temporal variation. They are almost flat time series.
I understand now why SST is nearly constant. I checked the ERA5 initial/metgrid fields using the same nearest-neighbor matching method along the MOSAiC trajectory. The SST in the ERA5/met_em fields is already nearly constant at the MOSAiC locations, likely because the observation points are located over sea ice.
However, I am confused about TSK. In the ERA5/met_em fields, SKINTEMP/TSK along the MOSAiC trajectory shows clear temporal variation. But in the WRF output, TSK shows only very small variation and is almost constant, similar to SST. Therefore, I am trying to understand why the time-varying SKINTEMP information in the input/met_em fields does not appear as similar temporal variation in wrfout TSK over sea ice.
My questions are:
1. In WRF, how is TSK treated over sea ice? Is it predicted by the surface scheme/sea-ice treatment, constrained by SST, initialized from SKINTEMP only, or updated during the simulation?
2. Is it expected that WRF TSK has very small temporal variation at sea-ice-covered grid points?
3. Could this phenomenon be related to the fact that the MOSAiC trajectory is located over sea ice?
For reference, I will also attach the following materials:
I am running WRF simulations over the Arctic for the period from 2020-06-01 00:00 UTC to 2020-07-29 23:00 UTC. My analysis focuses on the MOSAiC observation trajectory, which was located over sea ice during this period.
I extracted SST and TSK from the WRF output by nearest-neighbor matching the d02 wrfout fields to the hourly MOSAiC observation locations. The MOSAiC expedition was a drifting observational campaign based on a research vessel frozen into Arctic sea ice, so the observation sites were located on and moved with the sea ice. After interpolation to the MOSAiC trajectory, I found that both SST and TSK show very little temporal variation. They are almost flat time series.
I understand now why SST is nearly constant. I checked the ERA5 initial/metgrid fields using the same nearest-neighbor matching method along the MOSAiC trajectory. The SST in the ERA5/met_em fields is already nearly constant at the MOSAiC locations, likely because the observation points are located over sea ice.
However, I am confused about TSK. In the ERA5/met_em fields, SKINTEMP/TSK along the MOSAiC trajectory shows clear temporal variation. But in the WRF output, TSK shows only very small variation and is almost constant, similar to SST. Therefore, I am trying to understand why the time-varying SKINTEMP information in the input/met_em fields does not appear as similar temporal variation in wrfout TSK over sea ice.
My questions are:
1. In WRF, how is TSK treated over sea ice? Is it predicted by the surface scheme/sea-ice treatment, constrained by SST, initialized from SKINTEMP only, or updated during the simulation?
2. Is it expected that WRF TSK has very small temporal variation at sea-ice-covered grid points?
3. Could this phenomenon be related to the fact that the MOSAiC trajectory is located over sea ice?
For reference, I will also attach the following materials:
- Figure 1: The WRF simulation domain and the corresponding MOSAiC trajectory during the study period.

- Figure 2: Time series of SST and TSK along the MOSAiC trajectory from PolarWRF, WRF, ERA5 (using the same nearest-neighbor matching method), together with the MOSAiC observations.

- My WRF namelist configuration file.