Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

replacement of VEGFRAC/ALBEDO/LAI and EMISSIVITY

This post was from a previous version of the WRF&MPAS-A Support Forum. New replies have been disabled and if you have follow up questions related to this post, then please start a new thread from the forum home page.

lslrsgis

Member
Dear WRF Community,

I have a question on substitution of ALB/LAI/GVF in WRF V4.0. As for these three, I can replace the equivalent fields through usemonalb = true, rdlai2d = true, and sst_update=1 in namelist.input.

Question 01: if sst_update = 0, usemonalb = false, rdlai2d = false in namelist.input, then:
we are using albedo from TBL, lai from TBL, but GVF (VEGFRAC) from monthly MODIS. This is verified from wrfout* files. Is there a control/switch for GVF (VEGFRAC) from TBL?

Question 02: if I wish to substitute additional fields, such as emissivity, what should I do? The wrflowinp.d0*.nc files do not contain corresponding field.

Question 03: Noah-Unified is used as Land Surface Model. Hence, relative modules to digest these fields are in /phys/module_sf_noahdrv.F?

Thanks in advance.
 
Hi,
1) The Noah LSM uses the VEGPARM.TBL, and VEGFRA is not something that is included in the table, meaning there is also no namelist switch to use it from the table.

2) Can you be specific about a particular variable you would like to modify? Do you have other data that you would like to incorporate, or are you just wanting to play around with the values?

3) All code related to the Noah LSM is found in module_sf_noahlsm.F, which is then called by module_sf_noahdriv.F.
 
Thanks for the quick reply.

1) The Noah LSM uses the VEGPARM.TBL, and VEGFRA is not something that is included in the table, meaning there is also no namelist switch to use it from the table.

=> I found the following folders in static GEOG package, whose path one has to specify in namelist.wps for pre-processing.
/albedo_modis /lai_modis_10m /maxsnowalb_modis /greenfrac_fpar_modis /lai_modis_30s /modis_landuse_20class_30s_with_lakes

Question (a) LAI/albedo/VEGFRAC are originally derived from these binary static files?
Question (b) Where can I get the description or reference on the procedure of generating these fields from MODIS products? (one year MODIS product, might be 2006, is used? How the 8 day/16 day products are processed to generate monthly snow-free gap-filled LAI/albedo/VEGFRAC?)



2) Can you be specific about a particular variable you would like to modify? Do you have other data that you would like to incorporate, or are you just wanting to play around with the values?

==> Specifically, I have other data to incorporate and wish to substitute the variable EMISS (surface emissivity). The WRF default surface emissivity seems to be derived from .TBL values, I assume.

float EMISS(Time, south_north, west_east) ;
EMISS:description = "SURFACE EMISSIVITY" ;
EMISS:units = "" ;



3) All code related to the Noah LSM is found in module_sf_noahlsm.F, which is then called by module_sf_noahdriv.F.


=> I wish to know what did WRF source code read wrflowinp* files to update LAI, albedo, VEGFRAC fields.

Thanks very much.
 
Answers to your questions:
1a) Yes
1b) See this FAQ regarding references to the static data: https://forum.mmm.ucar.edu/phpBB3/viewtopic.php?f=75&t=168

2) We don’t know of anyone who has done this before, but think it can likely be done, though it will take some work on your part. I'm not sure of the frequency of your alternate EMISS data, but let's assume that you have daily values. The easiest way to get this to work out in the long run, is to treat them like the other atmospheric data, i.e., you will want to have a value for every boundary time period. So if you have 6-hourly atmospheric/sfc files, you will want to write the EMISS data into the same interval. It is probably best to just use the same values for every 6 hour period, over the course of the 24 hour period. Otherwise you will need to figure out a way to interpolate the value between two 24-hour periods, but physically, that may not even make much sense. You will need to write the files into intermediate format:
http://www2.mmm.ucar.edu/wrf/users/docs/user_guide_V3.9/users_guide_chap3.html#_Writing_Meteorological_Data

I'm not sure of the format of your EMISS files, but in case they are in netcdf format, you can find an example template to help you to write from netcdf format, into intermediate format here:
http://www2.mmm.ucar.edu/wrf/users/special_code.html
(just keep in mind you’ll need to modify it to make sense with your data). You will need to call the field something slightly different than “EMISS” since that is already used by the wrf model, and is scripted to be read in monthly (and stays the same each year). You can choose a name in the intermediate process and just stick with that through wrf.

Once you have it in intermediate format, you will then run metgrid to include both your sfc/atmopsheric files, and your EMISS files. You will need to modify the METGRID.TBL so that it will look for these EMISS data. You can use any of the other fields that seem reasonable to copy and modify for the EMISS variable. It shouldn’t need to use masked interpolation.

After running metgrid, EMISS should be included in the met_em* files. You’ll then need to modify the Registry/Registry.EM_COMMON file to add the new variable in. You’ll want it to output to stream 4. You can use the variable ‘ALBBCK’ as guidance. Having it output to stream 4 will put it in the wrflowinp_d* file when you run real.exe, and this will allow it to update every time period. You will also need to make sure you have sst_update turned on in your namelist.input. Additionally, set ‘usemonalb = .true.’ so that the noah LSM will not use the EMISS values from the table.

I would suggest taking it very slowly, testing things as you go, so as to not do a lot of work and then not know where an error is occurring later.
Again, this hasn't been done before, to our knowledge, so this may take some playing around and may take you becoming a bit familiar with the WRF code.

3) This should be found in phys/module_surface_driver.F, where it does a test for 'sst_update.'
 
Thanks very much for the detailed reply. It shows me a good way to solve my problem. I still have two questions:

Question 1(a): The link demonstrates clearly where the static files (landuse) are derived from. However, I wish to know further, such as LAI, VEGFRAC, ALBEDO. How these three snow-free and gap-filled data records are generated from original MODIS 8/16 day products? Which year of MODIS is used? How the maximum snow albedo is generated?

Question 2: If I wish to replace LAI, ALBEDO, VEGFRAC and EMISS together, then ALBBCK field in wrflowinp* files migh not be used. Is there a method to add an additional field in wrflowinp* files?

Thanks again.
 
To answer your questions:

1) Unfortunately what we provide in that link is all that we know. These data were provided to us and passed along over time. We have tried to gather more information, but this is all that we have come up with. I would suggest perhaps reaching out to the the MODIS group, if possible, to get more information.

2) The method that I discussed in my previous post should give you guidance for adding an additional variable in the wrflowinp files. Perhaps that description (that is specific to the wrflowinp* files), along with one or more of these FAQ's will help you to add a new variable:
https://forum.mmm.ucar.edu/phpBB3/viewforum.php?f=74
 
Top