List of required input data

[j08lue]

I am trying to compile a list of required input data.

short name	description	GEE
MOD09GA.006	Surface Reflectance Daily L2G Global	yes
MOD11A1.006 & MYD11A1.006	Land Surface Temperature/Emissivity Daily L3 Global	yes
MOD13A2.006	Vegetation Indices 16-Day L3 Global	yes, GEE has A1 (500 m instead of 1 km)
MCD15A2H.006	Leaf Area Index/FPAR 8-Day L4 Global	yes, GEE has MCD15A3H.006 (500 m)
MCD43B2.005	BRDF-Albedo Quality 16-Day L3 Global	no
MCD43B3.005	Albedo 16-Day L3 Global	yes
ERA Interim forecast 134.128	forecast air temp, wind dir and dew point temp	no
ERA Interim analysis 134.128	analysis air temp, wind dir and dew point temp	no
ETA Interim forecast 2t	2m air temperature	no
ERA Interim forecast tp	Precipitation	no
ERA Interim forecast 169.128	forecast downward and total-clear-sky solar radiation	no

Please let me know if anything is missing.

[buwuyou]

Albedo Substitutes?: GEE has MCD43A3.006 MODIS Albedo Daily 500m and MCD43A2.006 MODIS BRDF-Albedo Quality Daily 500m.

If I was right, there are plenty of rainfall datasets to replace ERA precipitation. It's up to the temporal coverage.

Could we check this one in replace of many ERA inputs? https://code.earthengine.google.com/dataset/NOAA/GFS0P25 , but only available for a short time period (2015-2018).

There is surface air temperature from MODIS or NCEP (1948-2017). I'm not sure how does either of it fit with the model in replacement of 'forecast/analysis/ dew point' air temperature, which are very specific parameters.

The the specific dew point temp is available for US only.

[j08lue]

Dew point temperature can be calculated from 2m air temperature and relative humidity - if we can get relative humidity...

[j08lue]

if we can get relative humidity...

Seems like we can: from https://explorer.earthengine.google.com/#detail/NOAA%2FCFSV2%2FFOR6H or https://explorer.earthengine.google.com/#detail/NOAA%2FGFS0P25

[buwuyou]

An update on where we are for the data preparation: The GFS was used as the climate forecast data (2015-2018), the only one on GEE allows to derived dew point temperature. We have now the GFS forecast air temp, wind dir (https://stackoverflow.com/questions/21484558/how-to-calculate-wind-direction-from-u-and-v-wind-components-in-r), dew point temp (https://iridl.ldeo.columbia.edu/dochelp/QA/Basic/dewpoint.html), 2m air temp, precip and downward shortwave radiation flux.

Q1: Compared to the era interim, should the wind direction be the direction the wind is coming from or the direction the wind is blowing? Q2: In general, how do you think on using GFS to replace ERA-interim?

All required MODIS inputs were coded for reprojection and quality assessment using the QA flags.

Q3: which temporal and spatial resolution we are aiming at?

[j08lue]

All required MODIS inputs were coded for reprojection and quality assessment using the QA flags.

Excellent!

Q1: Compared to the era interim, should the wind direction be the direction the wind is coming from or the direction the wind is blowing?

Usually in meteorology, wind direction is the direction the wind is coming from (while it is the opposite with ocean currents). So I would expect that to be the case.

Q2: In general, how do you think on using GFS to replace ERA-interim?

I'll ask the authors at our meeting next week.

Q3: which temporal and spatial resolution we are aiming at?

What is the native resolution of the inputs? I think we should stick to that to begin with, I guess we can always add resampling later on?

[buwuyou]

Apart from NDVI, we also need SAVI:

https://github.com/DHI-GRAS/forward-et/blob/a88934e1e024220834e8ed491b629dbe8c37aed6/forward_et/download/Prepare_input_data.py#L243

[mads-gras]

"standard" guidelines for estimating relative humidity / dew point temperature / actual water pressure can be found in the FAO56 guidelines, which can be found e.g. here: https://www.kimberly.uidaho.edu/water/fao56/fao56.pdf

[mads-gras]

this page seems to have the right equations to do the conversion needed in order to use GLDAS data: https://planetcalc.com/2167/

[buwuyou]

So, just checked through the python model, I didn't find a place requiring 'dew point temperature', which further requires humidity in the calculation. Please check whether it is true. If so, we don't need to convert things. What we really need are Mean Temperature, Net Short Wave Radiation and Net Long Wave Radiation, which are corresponding to 'Tmean', 'RSnet', 'RLnet' in the model codes, and to the bands of 'AvgSurfTsfc', 'SWnetsfc', 'LWnetsfc' if we use GLDAS-2 at 25 km resolution. Please check whether it is true. If we agreed to use GLDAS-2 3-HOUR datasets, how to use it in context of the daily input? If we want to calculate the net radiation from incoming and outcoming radiation, we will again need extra inputs such as sun hours, Tairmax, Tairmin...

Otherwise, we are now one step further on the UI with an interactive extent selection either from user coords input or click-on drawing.

[j08lue]

So, just checked through the python model, I didn't find a place requiring 'dew point temperature', which further requires humidity in the calculation. Please check whether it is true. If so, we don't need to convert things.

@gmendiguren, can you answer this one?

If we want to calculate the net radiation from incoming and outcoming radiation, we will again need extra inputs such as sun hours, Tairmax, Tairmin...

No calculating, we just get those from GLDAS. :-)

If we agreed to use GLDAS-2 3-HOUR datasets, how to use it in context of the daily input?

I guess we need to aggregate in time to get daily values. Does GEE not have functionality for that? We need to use daily mean for temperature and sum for radiative fluxes.

[buwuyou]

Cool! 'sum for radiative fluxes' is the info I need;)

[j08lue]

Actually, what units are the fluxes in? W/m2 or W (aggregated over grid cell / pixel area)? And with which units do they enter the equation? On second thought, we probably need to use the daily mean anyways, since the rate is instantaneous.

[gmendiguren]

So, just checked through the python model, I didn't find a place requiring 'dew point temperature', which further requires humidity in the calculation. Please check whether it is true. If so, we don't need to convert things.

@gmendiguren, can you answer this one?

Xiaoye is right. We did not include in the MODIS set up the relative humidity/dew point.

If we want to calculate the net radiation from incoming and outcoming radiation, we will again need extra inputs such as sun hours, Tairmax, Tairmin...

No calculating, we just get those from GLDAS. :-)

Right!

If we agreed to use GLDAS-2 3-HOUR datasets, how to use it in context of the daily input?

I guess we need to aggregate in time to get daily values. Does GEE not have functionality for that? We need to use daily mean for temperature and sum for radiative fluxes.

We might need to check how to aggregate them. Might be the case that even if they are at a time step of three hours, are still daily accumulated values. Something similar to the ERA-Interim data. I will try to find some documentation on that.

[buwuyou]

Booming the progress! Thank you! @gmendiguren

We might need to check how to aggregate them. Might be the case that even if they are at a time step of three hours, are still daily accumulated values. Something similar to the ERA-Interim data. I will try to find some documentation on that.

It is really great you point it out. GLDAS Provider's Note: the names with extension _tavg are variables averaged over the past 3-hours, the names with extension '_acc' are variables accumulated over the past 3-hours, the names with extension '_inst' are instantaneous variables, and the names with '_f' are forcing variables. Correspondingly, temperature, net SW radiation and net LW radiation are provided only as ['AvgSurfT_inst', 'Swnet_tavg', 'Lwnet_tavg'] by GEE GLDAS. Should we thus use averaged daily SW/LW radiation? What does it mean by 'instantaneous variables', how does it matter to daily temperature?

The basic UI is almost there. Nodes of questions converge at the moment. What is the temporal resolution (of the output): Daily, 8-day or 16-day? It will determine the UI date selection, data interpolation/aggregation amongst MODIS and GLDAS.

[gmendiguren]

The model output should be daily, since the LST we are using is daily too and is the variable that controls most of the model results.

Regarding the forcing data we are thinking that perhaps using the 3 hour average data offers more capabilities. After talking with Monica we think that we could use the SWdown_f_avg closer in time to the LST observation from MODIS. The reason why we think is better is because we are deriving the LW net radiation based on the LST observation from MODIS. The J parameter can be calculated based on the ratio between SwInstantaneous/SwDaily and later used to calculate daily ET. I haven't tested yet how this would affect the results using this inputs. Regarding the extent we are using to run out tests, I attach you DEM in Geotiff where you can get the extent of the area. Don't take the pixel resolution as reference as this maps was generated to be used with the DASEMON dataset.

SRTM_Iberia.zip

[buwuyou]

Could you give formulas to get J by using GLDAS inputs? See below the code to get RnDaily WITHOUT J calculation. And also check whether I'm taking the right inputs for 'LWdown_f_tavg' and 'Swnet_tavg'.

function calc_NetRadiation(image) {
  var fimage = image.select(['LST_comp', 'DVT_comp', 'EMIS_comp',
                              'LWdown_f_tavg', 'Swnet_tavg'])
  //CalLongWave_Outgoing
  var Stef = ee.Image(5.67e-008).rename('Stef');
  var Rlw_out = fimage.expression(
        'Stef * (Emissivity) * (LST**4)', {
        'Stef': fimage.select('Stef'),
        'Emissivity': fimage.select('EMIS_comp'),
        'LST': fimage.select('LST_comp')
  }).rename('Rlw_out');
  var RLnet = fimage.select('LWdown_f_tavg').subtract(Rlw_out);
  //PTJPL_EVAPOTRANSPIRATION.py line 54-55
  var RSnetInstant = fimage.select('Swnet_tavg').divide(J);
  var RnDaily = (RSnetInstant.add(RLnet)).multiply(J).rename('RnDaily');
  return image.addBands(RnDaily);
}

What is the unit of Tmean?

[gmendiguren]

Hi, regarding the calculations of the Long wave radiation I think there are some things that need to be checked. The Long wave Out radiation is well calculated in the code, however, in out set up we calculate the incoming radiation based on the air temperature. Since we use MODIS and we need the air temperature at the acquisition time, we need to somehow estimate it. We use the following aproach from Parton and Logan: 1-s2.0-0002157181901059-main.pdf Check the function CalLongWave_Incoming_Parton_Logan(LST,ObsTime,N,AirMax,AirMin) under the Radiation_Functions.py file This approach needs the day Maximum and Minimum air temperature, the LST, the observation time and a N parameter that represents the day length in hours and that is one of the outputs from the function CalShortWaveIncomingRadiation. It is calculated based on Day of year (DOY) and latitude:

latRad=(Latitude*np.pi)/180
delta=0.409*np.sin(((Doy*2*np.pi)/365)-1.39)#Declination in radians
ws=np.arccos(-np.tan(latRad)*np.tan(delta))#; %sunset hour angle radians
N=(ws*24.)/np.pi#day length in hours

[buwuyou]

Alright! We come back to the input issue. The GLDAS from GEE doesn't have AirMax and AirMin. Could you check whether CFSV2 is ideal to use? https://code.earthengine.google.com/dataset/NOAA/CFSV2/FOR6H

What should be the latitude image?

[gmendiguren]

Can not be calculated based on the daily Airtemp observations? How many observation of Airtemp are per day? I am now sending an email to Mads to see if we can meet next Tuesday with you and solve all this issues. I talked to Monica and we think is going to be more efficeint that way.

[buwuyou]

haha, we thought the same;) Let's figure out the 5W1H for the meeting next week.

Now I see how to make use of the GLDAS data. It's every 3-hours.