SST update on the lakes

[francescomaicu]

Dear all,
I was reading this post and wanted to join the discussion, but the thread is disables.
I am running WRF on a large domain and I have some enclosed basins (such as the Black Sea and the Azov Sea) that are considered lakes in the nectcfd of the domain.
I have to simulate the development of a cyclone over that areas.
I am wondering about the SST update.
I am running with sst_update = 1 and prescribing an evolving SST covering that areas. I am NOT running with sf_lake_physics=1.
My question is whether the SST update is effective even though the lake mask = 1 over that areas. I guess so reading the manual, but I am not sure, and I do not know how to check that in the results.
If I run with sf_lake_physics=1 the skin_T (not sure exactly which variable is prognosed) is updated with the lake module if all the necessary data are found.
Thank you for any help.

 

[Ming Chen]

SST_UPDATE only works over water points, i.e., those grid points where landmask =0. Those points with lakemask =1 should correspond to points with landmask=0, and thus sst_update should apply to such points.

 

[francescomaicu]

Dear Ming,
thank you very much for your definitive and very helpful clarification.
It is a bit weired that the Black Sea and Azov Sea are mapped as lakes in the modis_landuse_20class_15s_with_lakes dataset.
Do you have any comment about that?
Anyway, I tried to avoid the problem in advance changing the LU_INDEX from 21 to 17 in the domain file and correspondingly the LAKEMASK. This is needed for me because that domain will bw coupled with an active ocean model, so that areas should be recognised as ocean to make the coupling effective.

 

[Ming Chen]

Sorry I have no explanation why MODIS treats Black Sea and Azov Sea as inland lakes. We use MODIS data as is.
Your modification is definitely necessary if you couple WRF with ocean model.

 

[francescomaicu]

Hi Ming what do you think if couple WRF and NEMO everywhere exept in the Azov Sea and swith on the lake module?
I guess the coupling will be effective on the CPL_MASK which will not consider the Azov Sea, where the lake module will update the skin temp.
Would it work ?

 

[Ming Chen]

I would say it is better to couple WRF and NEMO everywhere including the Azov Sea. This is because the lake module assumes a water depth of 50m with a prescribed spatially invariant temperature profile. This is way too simple to describe the physical/dynamical processes over the ocean.

 

[francescomaicu]

Dear Ming, I would like to discuss the following finding.
I run two experiments with and without sf_lake_physics. Please find the namelists attached.
The initial and boundary conditions are the same as well as the bottom boundary condition for the SST update.
The run with the sf_lake_physics calculated correctly an evolving lake temperature, please see T_LAKE3D in the map attached.
I decided to NOT use the lake_depth field and set a default lake depth of 20m, i.e. the water depth of the Azov Sea.
I found differences of the T2 between the two runs (with/without lakes physics) and I wanted to understand where they come from.
I started to analyse the TSK: please tale a look at the differences (without lakes - with lakes) during the third day of the run.
You can download the file here, and see how large difefrences in TSK develops over the land in the easter part of the domain.
I would not expect these differences, exept over the lakes (as it is on the Azov Sea).
Please can you help me in understand these differences or if there is an errore I made?
Thank you very much.

 

[Ming Chen]

Hi,
I looked the file TSK_diff_2021-08-12_00_00_00.nc and the result seems reasonable. ncview shows that the difference is mostly below 3, and large differences are found over the lake area, which is understandable. As for the differences in other areas like the east part of the domain, I would say that the differences between the two runs over the lake may feedback to the atmosphere, affecting other meteorological elements and leading to the TSK differences. if you look at cloud cover, radiation etc, you may find similar differences, too.
This result shows the typical model behavior, i.e., local changes can result in small differences that spread over the entire model domain.

 

[francescomaicu]

Hi,
I looked the file TSK_diff_2021-08-12_00_00_00.nc and the result seems reasonable. ncview shows that the difference is mostly below 3, and large differences are found over the lake area, which is understandable. As for the differences in other areas like the east part of the domain, I would say that the differences between the two runs over the lake may feedback to the atmosphere, affecting other meteorological elements and leading to the TSK differences. if you look at cloud cover, radiation etc, you may find similar differences, too.
This result shows the typical model behavior, i.e., local changes can result in small differences that spread over the entire model domain.

Hi Ming,
I perfectly understand your point. I was not completely sure such small variations could spread troughout all the domain. I am still a bit confused how it is possible to find differences in the Atlas region (TSK_001 no lakes in that area) or in the Iberian Peninsula (TSK_006)
Thank you

 

[francescomaicu]

Dear Ming,
I did several tests with the coupled model and the lake module on/off. I am not definitely sure of the results so I kindly ask a confirm.
Starting from the wrflowinput file, this contains the SST (it is stored in the SST_INPUT field) that can be merged with the SST from the coupler according to the CPLMASK.
My first CPLMASK is 1 everywhere, meaning that the SST_INPUT from the wrflowinput is not effective. I understand that if the wrflowinput file is in namelist it is read and data stored according to sst_update (0 = first time stamp repeated, 1 evolving in time).
My concern is about the SST over the lakes.
Suppose coupling is off. The SST (=SST_INPUT) covers also the lakes (from ECMWF the SSt covers the Azov Sea). Do this mean that the variables over the lakes (HFX for istance) are diagnosed from the SST instead of being diagnosed from the lake temperature (T_LAKE3D) from the lake module? I see in the lake module that the heat fluxes are calculated there, so I guess the daignosed variables are merged in the surface driver module. If I understand correct, wether the SST is inputed or not, wether the coupling is on or off, if the lake module is on, the fluxes are calculated in the lake module and outputed from there.
Is this correct?
thank you

 

[Ming Chen]

I would like to clarify the lake issues in WRF:
(1) If lake module is turned on, then TSK over the lake is calculated by the lake module. It also effects sensible and later heat fluxes over lake
(2) If lake module is turned off, the points over lake are treated as water points. If sst_upadte = 0, then TSK over these lake points will remain unchanged (same as that in wfinout). If sst_update =1, then TSK over these points will be updated based in data in wrflowinp.
(3) To answer your question: if the lake module is on, the surface fluxes are calculated in the lake module and output. These fluxes are later used in PBL scheme.

 

[francescomaicu]

Thank you very much this definitely clarifies my doubts.

 

[haiqingsong]

I would like to clarify the lake issues in WRF:
(1) If lake module is turned on, then TSK over the lake is calculated by the lake module. It also effects sensible and later heat fluxes over lake
(2) If lake module is turned off, the points over lake are treated as water points. If sst_upadte = 0, then TSK over these lake points will remain unchanged (same as that in wfinout). If sst_update =1, then TSK over these points will be updated based in data in wrflowinp.
(3) To answer your question: if the lake module is on, the surface fluxes are calculated in the lake module and output. These fluxes are later used in PBL scheme.

Is there any observed SST（Fine resolution） data to WRF？

 

[francescomaicu]

I would say two satellite products: OISST by NOAA and OSTIA by UKMO

 

[Ming Chen]

Hi,

You are right that, if the lake module is activated, then surface fluxed will be calculated by the lake module.

If the lake module is turned off, then. surface flux over the lake points are calculated based on SST in the input datafile (either wrfinput or wrflowinp, depending on the sst_update option).