Modifications to improve WRF-CTSM coupling

[negin513]

TYPE: enhancement

KEYWORDS: WRF-CTSM coupling, Community Terrestrial Systems Model (CTSM), Community Land Model (CLM),
coupled land-atmosphere models

SOURCE: Negin Sobhani ¹ , Dave Lawrence ¹ , Sam Levis ² , Bill Sacks¹

¹ National Center for Atmospheric Research (NCAR)
² SLevis Consulting

DESCRIPTION OF CHANGES:
This PR includes some modifications that improve WRF-CTSM coupling including the capability to handle lake points by CTSM instead of WRF.

Problem:
Previously lake points were not handled by the CTSM model; however, the CTSM community prefers lake points to be handled by CTSM lake model. This PR adds the capability to handle lake points by CTSM model.

Solution:
For solving this problem in module_surface_driver.F, we used xland(i,j) .gt. 1.5 .and. ht(i,j).gt.lake_min_elev lakemask(i,j).eq.1. logic. For CTSM cases we changed a local copy of xland (called ctsm_xland) for the lake points to 1, so that CTSM receives the lake points.

LIST OF MODIFIED FILES:
M phys/module_surface_driver.F
M share/module_soil_pre.F

TESTS CONDUCTED:

1. Following are a couple of figures, depicting a particular period's lakemask over CONUS, for both the input and theWRF model output. Specifically, the Great Lakes were part of the concern with this PR, and they are indeed represented as part of the lake identified cells.

Model input:

Model output:

2. Figures of low-level temperature and moisture for a 1-week simulation, without spectral nudging.

2-meter temperature: Here is the plot showing ΔT2 for the first week of 2013-04. ΔT2 is old version-new version.
The new version contains the local xland mods requested by the WRF committee.

2-meter RH. There is ~ a 5-10% difference in RH at 2m between the old and new versions over all the inland lakes.
ΔRH2 is old version-new version. This means that over the lakes, the new version is 5-10% dryer than the old version.

3. Jenkins tests are passing.

[davegill]

@negin513 @mgduda @dudhia @weiwangncar
Negin,
Michael has had a "lake identifier" index in the metgrid output for years. We turn that into just a water category in real for passing into WRF. We could provide a switch that controls an extra 2d array of a lake mask, which would be packaged with the existing CTSM option.

[dudhia]

I had an email response that seems to have failed to be delivered to github. This was as follows.
Is this not using the lake mask because you want to include the Great Lakes?
The reason for not using lake mask could be mentioned.

[negin513]

I had an email response that seems to have failed to be delivered to github. This was as follows.
Is this not using the lake mask because you want to include the Great Lakes?
The reason for not using lake mask could be mentioned.

Thanks @dudhia for your comment.
We are still using the lake mask from WRF, but we are letting CTSM handle lake points.

For more clarification, I've added a few lines of comments to the code.

WRF/phys/module_surface_driver.F

Lines 3898 to 3901 in 1acbe6a

	!For WRF-CTSM simulations, we would like the land model (CTSM)
	! to handle inland lake points.
	! Here, we are changing xland to include lake points, so that
	! CTSM can handle it.

Specifically about the great lakes, before they were treated as ocean but now they are going through CTSM lake model.

[davegill]

@weiwangncar @dudhia @smileMchen
Folks,
How do we get the lakemask field that I was recommending that Negin use?
In the Registry.EM, LAKEMASK is an i1 for I/O, so it is supposed to come into real from metgrid.
I do not see this field in a few of the met_em* files that I have.
Do we have to input geogrid static data that includes lakes?

[dudhia]

Yes, this mask should come with the correct geogrid MODIS choice. 21-category, I think.

…

On Fri, Feb 19, 2021 at 8:13 AM Dave Gill ***@***.***> wrote: @weiwangncar <https://github.com/weiwangncar> @dudhia <https://github.com/dudhia> @smileMchen <https://github.com/smileMchen> Folks, How do we get the lakemask field that I was recommending that Negin use? In the Registry.EM, LAKEMASK is an i1 for I/O, so it is supposed to come into real from metgrid. I do not see this field in a few of the met_em* files that I have. Do we have to input geogrid static data that includes lakes? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1355 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77HCUTAUJ4BFRBGI4B3S7Z5YZANCNFSM4VORKOEQ> .

[weiwangncar]

@davegill @dudhia It is in real that the field LAKEMASK is created, and it is created based on LU_INDEX:
IF ( grid%lu_index(i,j) .NE. grid%islake ) THEN
grid%lakemask(i,j) = 0
ELSE
grid%lakemask(i,j) = 1
END IF
So this appears to available in the model regardless of whether you use the lake option or not.

[davegill]

@negin513
Negin,
Do you have any figures that show the impact of with vs without these mods in your CTSM system?

Even small diffs show:

1. The coupled model is stable
2. The diffs do indeed make an impact

[negin513]

@davegill

Here is the plot showing ΔT2 for the first week of 2013-04:

ΔT2 is old version-new version. The new version contains the mods that WRF committee asked.
p.s.: These results are WRF-CTSM not using spectral nudging.

[negin513]

@davegill and @dudhia :
The following plot is similar to the above but for RH at 2m. There is ~ a 5-10% difference in RH at 2m between the old and new versions over all the inland lakes. Does that look okay to you?

ΔT2 is old version-new version. The new version contains the mods that WRF committee asked. This means that over the lakes the new version is 5-10% dryer than the old version.

[negin513]

@davegill and @dudhia :
The following plot is similar to the above but for RH at 2m. There is ~ a 5-10% difference in RH at 2m between the old and new versions over all the inland lakes. Does that look okay to you?

ΔT2 is old version-new version. The new version contains the mods that WRF committee asked. This means that over the lakes the new version is 5-10% dryer than the old version.

Just for sanity check, I compared RH at 2m from both the old version and the new version of WRF-CTSM ( with and without recent mods) with NOAH-MP and this is the results:

By the "old" version of WRF-CTSM, I mean the version where xland = 1 was changed to 1 over the lakes. The new version of WRF-CTSM, we did not modify xland and instead we used a temporary local parameter called (xland_ctsm) in the CTSM driver which is 1 for the lake points.

[weiwangncar]

I'm ok with this PR.

[negin513]

Summary Part 1

Here is a summary of discussions and thoughts on this PR.
Since most parts of the discussions on this PR were in meetings and over calls rather than in the comments of this PR, I am making this summary for future reference.

@dlawrenncar and Fei Chen suggested that they would like CTSM lake model to handle lake points rather than WRF slab model. ESCOMP/CTSM#1092

At first, we used the logic xland(i,j) .gt. 1.5 .and. ht(i,j).gt.lake_min_elev .and. lakemask(i,j).eq.1. in the module_surface_driver.F to identify lakes and changed xland to 1 for lake points. In WRF-CTSM coupling infrastructure only land points are passed from WRF to CTSM; therefore, by changing xland (land mask) to include lake points we can pass lake points to CTSM. Similar logic for identifying lake was used in module_surface_driver.F.

At this point the code looked like the following:

WRF/phys/module_surface_driver.F

Lines 3898 to 3910 in 15981e1

	!For WRF-CTSM simulations, we would like the land model (CTSM)
	! to handle inland lake points.
	! Here, we are changing xland to include lake points, so that
	! CTSM can handle it.
	DO j=j_start(ij),j_end(ij)
	DO i=i_start(ij),i_end(ij)
	IF (lakemask(i,j).EQ.1. .AND. xland(i,j).GT.1.5 .AND. ht(i,j).GT.lake_min_elev) THEN
	WRITE( message,* ) 'WRF-CTSM: for great lakes xland ==1'
	CALL wrf_message ( message )
	xland (i,j) = 1
	ENDIF
	ENDDO
	ENDDO

Next, @davegill recommended not using the first two parts of the logic (xland(i,j) .gt. 1.5 .and. ht(i,j).gt.lake_min_ele) As this was an older method for identifying lake points.

The value lake_min_elev has a default value set to 5 m. The idea is IF this is a water point AND the elevation of the grid cell is >= this minimum elevation, THEN this must be a lake point. This is likely an older way of identifying a lake point.

After applying this comment to the code, it looks like the following:

        !For WRF-CTSM simulations, we would like the land model (CTSM)
        ! to handle inland lake points.
        ! Here, we are changing xland to include lake points, so that
        ! CTSM can handle it. 
         DO j=j_start(ij),j_end(ij)
            DO i=i_start(ij),i_end(ij)
                IF (lakemask(i,j).eq.1. ) THEN
                    WRITE( message,* ) 'WRF-CTSM: for great lakes  xland ==1'
                    CALL wrf_message ( message )
                    xland (i,j)  = 1  
                ENDIF
            ENDDO
         ENDDO

At this point, @dudhia suggested making sure that the Great Lakes are indeed included in the lakemask.
For addressing this comment, I've provided plots from both wrfout and wrfinput showing that indeed lakemask=1 for the Great Lakes. Copied from the above:

It seems like lakemask=1 for the Great Lakes. I am attaching the plots from wrfout that I showed you in the previous meeting which shows Great Lakes in the lakemask:

This shows the lakemask for wrfinput:

[negin513]

Summary Part 2

---

Next, we had a meeting with the WRF committee (@davegill , @dudhia ,@weiwangncar, and @smileMchen) for approving this PR. In this meeting, Ming Chen and @weiwangncar suggested not modifying xland and instead passing a temporary local parameter into the CTSM driver which is 1 for the lake points. They mentioned that xland might be used in other places in the code and it is not advised to change it directly.

At this point, we introduced a new local parameter called ctsm_xland. ctsm_xland is exactly similar to xland but with 1 for the lake points. Next, we passed ctsm_xland to ctsm_run subroutine.

I accepted this change as I initially thought the results will be BFB.
However, the results showed differences compared to the original way (changing xland directly and passing it ctsm_run).

After discussions with @slevisconsulting and @davegill, I was convinced that the resulting change was normal and should have been expected.

Not changing the original xland and using the temporary ctsm_xland made sense as there might be other points in the code with special treatments over water points that still need to be done, and by modifying xland directly we are skipping those treatments.

Below shows the difference between T2 and RH for one week in 2013-04:

Here is the plot showing ΔT2 for the first week of 2013-04:

ΔT2 is old version-new version. The new version contains the mods that WRF committee asked.
p.s.: These results are WRF-CTSM not using spectral nudging.

The following plot is similar to the above but for RH at 2m. There is ~ a 5-10% difference in RH at 2m between the old and new versions over all the inland lakes. Does that look okay to you?

Just for a sanity check, I compared RH at 2m from both the old version and the new version of WRF-CTSM ( with and without recent mods) with NOAH-MP and this is the results:

By the "old" version of WRF-CTSM, I mean the version where xland = 1 was changed to 1 over the lakes. The new version of WRF-CTSM, we did not modify xland and instead we used a temporary local parameter called (xland_ctsm) in the CTSM driver which is 1 for the lake points.

---

This change was made because WRF will handle the transferred CTSM fluxes differently over water than over land points.
We would like CTSM fluxes over lake points in the WRF.

[negin513]

@davegill , @dudhia , @weiwangncar , @smileMchen, I would like to once again confirm if the followings are true with this change:

• With the current changes over the lake points, fluxes transferred from CTSM are being used in the WRF model.
• Based on your comments, there are not any additional treatments done over the lake points that need to be turned off when we are directly using CTSM fluxes.

[negin513]

For confirming that in the WRF-CTSM settings, CTSM values over lake points are being transferred correctly and not being over-written by WRF, @dlawrenncar suggested the following experiment:

In this experiment, over the lake points in CTSM initial conditions, we set values higher than ordinary (For example 60 °C = 333.15 K). If the fluxes from CTSM over lake points are being used in WRF, we should see its impact in the WRF output files.

Following this experiment, we can clearly see the fluxes from CTSM over the lake points in the WRF output, which confirms that CTSM values over the lake points are not being over-written by WRF.

Here I attached a few plots showing different variables.

First, the following plot shows upward heat flux at the surface (HFX) from wrfout files for a one-week of simulation (first week of 2013-04). Here we can clearly see the signals from CTSM initial conditions over lakes.

The following plot shows the temperature at 2m (T2) from wrfout files for a one-week simulation:

This plot shows skin surface temperature (TSK) from wrfout for one day of simulation:

In conclusion, we can confirm that WRF-CTSM coupling is working correctly over lakes and fluxes from CTSM over the lake points are being used in WRF.