New URBPARM_LCZ.TBL parameters adapted for Paris

[jesusff]

These have been provided by Sun (@SiuSunChun):

We conducted an analysis of the building height distribution and found that the default building height distribution differs from our Open Street (OS) 100m map analysis for France. As a result, we updated our URBPARM_LCZ.TBL file

[jesusff]

@SiuSunChun, thank you this valuable input! You can provide here any further detail of the procedure/input data you used.

@SiuSunChun, in the plots above, "default" (histograms) refers to the generic file released with WRF v4.5.1? or our default in the FPS? The latter was adapted for Madrid and already differed quite a bit from the generic parameters.

Note that the differences that you see in this pull request are with respect to the URBPARM_LCZ-Madrid.TBL

[jesusff]

An e-mail thread regarding this PR:

@oscarbrousse wrote:

If I may take the opportunity to make a point. Some of the classes may be misclassified as open high rise when they should be open mid-rise; which is what you observe eventually. The distribution of heights is not wrong, it’s simply another class.

What one could do would be to update the LCZs map based on this building height information you found and run the python W2W to build up other _geoem files. But then you will face questions of why that product more than another, as products of building heights greatly differ in their estimations and accuracies.

I think it can be a nice point of discussion if we find that performance of the model is worse in LCZ 4, or even indifferent to other classes, for example. But I would not worry about it that much. One could do a what if scenario replacing LCZ 4 by LCZ 5, but the question is about how informative that would be for the project.

How many LCZ 4 pixels do we have anyway? I guess there are only a few, right?

@yoselita wrote:

I am not sure if w2w tool actually uses the data from the URBPARM_LCZ.TBL. The w2w tool I use after running geogrid.exe in the WPS folder, and the table is not at the same location (it is in wrf/run folder). It seems that w2w tool bases its info in urban parameters in geo_em file on the LCZ_UCP_default.csv. I would guess that the URBAPARM_LCZ.TBL is read but the bep+bem scheme (??). Sorry if I miss something here.

Here are the lines from the readme file of the W2W tool I found: https://github.com/matthiasdemuzere/w2w/blob/84f7d80/JOSS/paper.md#step-4-assign-urban-canopy-parameters

@LluisFB wrote:

We performed a re-classification of all the LCZs for Buenos Aires city in Argentina. We combine different local sources to compile a new .tiff at 100 m of horizontal resolution and then pipe it with w2w to modify the geo_em. The new tiff with its new 11 LCZs was re-classified using locally-based histograms of buildings (to reclassify, high, mid and low) and vertices per grid area (to reclassify, compact, open). Even we force the green areas and the slump sides as the LCZ 7 (open low rise). We already presented it into the FPS URB RCC meeting. According to that, we also modify the URBPARAM_LCZ.TBL to accommodate the new classification

Any data from our reclassification was used as input for the URB_2D variable in the geofile which keeps being with 0 values. Therefore, all the 135 values are directly taken from the URBPARAM_LCZ.TBL

With the w2w tool we found some issues regarding the fraction of LCZs per grid cell. Since, w2w seems to only provide values for the LCZ with the largest fraction of presence. Any way, that is not an issue, because BEP, BEM seem to work only with the values from LU_INDEX (the largest LCZ per grid) instead of LANDUSEF.

@oscarbrousse wrote:

That is a weird outcome Lluis. Normally your FRC_URB_2D should be above 0 and spatially explicit. You should also have a percentage of building heights (fields > 130 in the URB_PARAM variable if I remember well) that varies in space. If those fields are properly provided then BEP-BEM will look at these and not at the URBPARAM_LCZ.TBL, of that I am sure.

BEP-BEM does only work with LU_INDEX but LANDUSEF is used by the land surface model (Noah LSM or Noah-MP).

@yoselita wrote:

To my knowledge, Noah uses LANDUSEF, but Noah-MP does not. Noah has an option of _sf_surfacemosaic = 1, which Noah-MP does not have. So I guess Noah-MP defines an urban gird according to LU_INDEX, as indicated by Lluis, in which urban scheme starts to operate if is it turned on.

So @oscarbrousse, if I got it right, you suggest that if URB_PARAM is provided in geo_em file, URBPARAM_LCZ.TBL is not used? If this is the case, then I guess we have a problem, as the updates in the URBPARAM tables will not affect the simulation. I am not sure how the URB_PARAM enter in the forcing files. Which variables should I look in wrfinput or wrflowinp?

I was checking the forcing files, and it could be the case that FRC_URB_2D affects VEGFRA variable in wrflowinp files (I have not found any other variable), which is being used in Noah-MP. And FRC_URB_2D in geo_em file that we use in our STAGE-0 runs is not set to zero (see below).

@LluisFB wrote:

Just to add, as far I understand, URB_PARAM (130 variables) only gets filled by geogrid.exe if there is data in the geog/ folder. My understanding is that there is only data from the NUDAPT data-base which only covers North America. So, everywhere else, will have 0 values.

If this variable has 0 values, WRF reads the variables from the .TBL

@yoselita wrote:

Thank you @oscarbrousse. So I guess something is used from URB_PARAM and something from the table. I am still not sure how URB_PARAM affect the simulation. I guess we should find out which variables are based on URB_PARAM in the forcing files created after running real.exe. Is it only the VEGRAC?

I am thinking the same Lluis, and probably this does not come out from running geogrid.exe. But I think this is filled with w2w tool, as some of the parameters in URB_PARAM are not equal to 0 (as mentioned by Oscar). This is an example for the parameter 120.

@SiuSunChun wrote:

W2W has this look up table https://github.com/matthiasdemuzere/w2w/blob/84f7d802f/w2w/resources/LCZ_UCP_lookup.csv

@oscarbrousse wrote:

Yes, and that is fine. That is the standard look up table for WRF simulations. I wouldn’t worry too much about it honestly.

[jesusff]

Not sure about the final conclusion. Shall we use the new file prepared by Sun? or shall we try a new LCZ reclassification based on the available data for Paris? I guess these are two different issues. We could go on with Sun's file as a first approach and work on the reclassification separately.

There are some new parameter values that were just fixed for v4.6 that we could include in this PR. They have to do with unrealistic road widths