Varying results / NaN for 'T2' in different grid cells

[fbriegel]

Dear all, I run SuPy for multiple grid cells (> 200) and I am interested in the 'T2' output. However, SuPy returns only NaN for 'T2' for some grid cells. The initial grid cell states differ in surface fraction, building and tree heights, roughness and zero displacement length, frontal area index, and population density. Forcing data are the same for all grid cells. I attached the corresponding pickle files with two exemplary grid cells as zip file.

SuPy runs without any errors.

Thank you. Ferdi

Screenshots Initial state differences of grid cells:

## surface fraction
>> df_state.loc[:, 'sfr'] 

ind_dim   (0,)   (1,)  (2,)   (3,)   (4,)  (5,)   (6,)
grid                                                  
170      0.353  0.106     0  0.247  0.294   0.0  0.000
171      0.241  0.335     0  0.294  0.128   0.0  0.002

## tree and building heights
>> df_state.loc[:, ['dectreeh','evetreeh','bldgh']]

var     dectreeh evetreeh  bldgh
ind_dim        0        0      0
grid                            
170         7.18     7.18  11.67
171         8.33     8.33  13.77

## roughness and zero displacement length
>> df_state.loc[:, ['z0m_in','zdm_in']]

var     z0m_in zdm_in
ind_dim      0      0
grid                 
170       1.18  10.68
171       1.36  20.78

## frontal area index
>> df_state.loc[:, ['faibldg','faidectree','faievetree']]

var     faibldg faidectree faievetree
ind_dim       0          0          0
grid                                 
170        0.12       0.09       0.09
171        0.21       0.22       0.22

Output:

df_output_suews.loc[:, 'T2'].isna()
Out[41]: 
grid  datetime           
170   2006-01-01 02:00:00     True
      2006-01-01 03:00:00     True
      2006-01-01 04:00:00     True
      2006-01-01 05:00:00     True
      2006-01-01 06:00:00     True

171   2006-12-31 19:00:00    False
      2006-12-31 20:00:00    False
      2006-12-31 21:00:00    False
      2006-12-31 22:00:00    False
      2006-12-31 23:00:00    False
Name: T2, Length: 17516, dtype: bool

Additional context Version:

SuPy versions
-------------
supy: 2021.7.22 
supy_driver: 2021a2

=================
SYSTEM DEPENDENCY

INSTALLED VERSIONS
------------------
commit           : 2cb96529396d93b46abab7bbc73a208e708c642e
python           : 3.7.10.final.0
python-bits      : 64
OS               : Windows
OS-release       : 10
Version          : 10.0.17763
machine          : AMD64
processor        : Intel64 Family 6 Model 158 Stepping 13, GenuineIntel
byteorder        : little
LC_ALL           : None
LANG             : en
LOCALE           : None.None

pandas           : 1.2.4
numpy            : 1.20.1
pytz             : 2021.1
dateutil         : 2.8.1
pip              : 21.0.1
setuptools       : 52.0.0.post20210125
Cython           : 0.29.23
pytest           : 6.2.3
hypothesis       : None
sphinx           : 4.0.1
blosc            : None
feather          : None
xlsxwriter       : 1.3.8
lxml.etree       : 4.6.3
html5lib         : 1.1
pymysql          : None
psycopg2         : None
jinja2           : 2.11.3
IPython          : 7.22.0
pandas_datareader: None
bs4              : 4.9.3
bottleneck       : 1.3.2
fsspec           : 0.9.0
fastparquet      : None
gcsfs            : None
matplotlib       : 3.3.4
numexpr          : 2.7.3
odfpy            : None
openpyxl         : 3.0.7
pandas_gbq       : None
pyarrow          : None
pyxlsb           : None
s3fs             : None
scipy            : 1.6.2
sqlalchemy       : 1.4.7
tables           : None
tabulate         : None
xarray           : 0.17.0
xlrd             : 2.0.1
xlwt             : 1.3.0
numba            : 0.53.1

GitHub_Issue.zip

[sunt05]

Hi @fbriegel , sorry to learn the T2 issue. I had a look at your results (thanks for your detailed report and files: very considerate) and found the issue was caused by the small FAI in your grid 170: a small FAI along with other morphological settings would lead SUEWS to use the MOST scheme to near surface diagnostic calculations rather than RSL (see here for details); so, as you can see, the zdm of grid 170 is much higher than 2 m – anything below zdm makes no sense under the MOST framework – and hence the NaNs in your results.

To proceed for valid T2 results, please adjust your frontal area index values in grid 170 (I notice those for trees are rather small: i.e. < 0.1).

Hope the above is helpful to you.

[fbriegel]

Hi Ting,

thank you for the fast response and the explanations. It helped a lot to understand the behavior of SUEWS. I changed the FAI value to 0.2 and indeed, it worked for grid cell 170 (but not for other ones - e.g. 168 see below).

So, if I am right, the problem with T2 predictions is given by the dfinition of flag_RSL which depends on FAI, land cover fractions and building heights. This means that there are several ways to make SUEWS use the MOST scheme. Using the MOST scheme, on the other hand, leads to NaN values below zdm.
Could it be a solution to set zdm to e.g. 1, if land cover fractions of buildings or FAI is low? As the impact of buildings is possibly negligible in this case?

E.g. grid cells 168 and 169:

>> df_state.loc[:, 'sfr'] 

ind_dim   (0,)   (1,)  (2,)   (3,)   (4,)  (5,)   (6,)
grid                                                  
168      0.244  0.076     0  0.115  0.565   0.0  0.000
169      0.378  0.077     0  0.031  0.514   0.0  0.000
170      0.353  0.106     0  0.247  0.294   0.0  0.000
171      0.241  0.335     0  0.294  0.128   0.0  0.002

>>df_state.loc[:, ['faibldg','faidectree','faievetree']]

var     faibldg faidectree faievetree
ind_dim       0          0          0
grid                                 
168        0.04       0.04       0.04
169        0.01       0.01       0.01
170        0.12       0.09       0.09
171        0.21       0.22       0.22

>>df_state.loc[:, ['dectreeh','evetreeh','bldgh']]

var     dectreeh evetreeh  bldgh
ind_dim        0        0      0
grid                            
168         6.54     6.54  10.89
169         5.09     5.09  12.04
170         7.18     7.18  11.67
171         8.33     8.33  13.77

Even using 0.2 for FAI leads to NaN. However, using the regular FAI values and setting zdm to 1, when FAI or land cover fractions getting to small, works for almost all grid cells.

Thanks, Ferdi

[sunt05]

Hi Ferdi, you can certainly do so – setting zdm to 1 – to avoid the numerical issue leading to NAN in T2. However, physically it depends on the environment to model: you need to justify if such a number is appropriate in your case. Similarly, the setting of FAI may need to be well justified/considered. Eventually, it is the interpretations of your simulation results that matters: if the settings, or any other input, are invalid, even though you get numerical results, then the results might not be useful as you would expect.

As such, please reconsider the choice of the parameter values. If you deem they are valid but SUEWS produce crazy values, please do get in touch; and I'm happy to work with you to resolve the issues at the model side.

Good luck!

Ting

[fbriegel]

Hi Ting,

thank you for this. I am mainly interessted in T2. I will check sensitvity and validity of the affected grid cells with varing zdm and FAI values. I will let you know if I run into any other issue.

Thanks, Ferdi

[fbriegel]

Hi Ting,

I came across another issue with T2. First, setting zdm to 1 when the FAI value becomes too small gives some useful results.

The other issue I ran into is that SUEWS produces extremely varying T2 values for some grid cells. For example, grid cells 242 and 209 have unlikely high T2 values in summer (July 2018). 'REA' = Forcing data.

In winter, these grid cells (and 204) have unlikely low T2 values (January 2018).

I think this issue is also related to the land cover class fractions and FAI and thus to QS and QH. However, changing the FAI values does not change the results.

df_state.loc[:, 'sfr']

ind_dim   (0,)   (1,)  (2,)   (3,)   (4,)  (5,)  (6,)
grid                                                 
204      0.009  0.000     0  0.989  0.002   0.0  0.00
242      0.124  0.060     0  0.739  0.067   0.0  0.01
299      0.379  0.338     0  0.231  0.052   0.0  0.00
309      0.169  0.138     0  0.655  0.038   0.0  0.00

df_state.loc[:, ['faibldg','faidectree','faievetree']]

var     faibldg faidectree faievetree
ind_dim       0          0          0
grid                                 
204        0.00       0.46       0.46
242        0.06       0.50       0.50
299        0.16       0.09       0.09
309        0.06       0.67       0.67

I attached the corresponding pickle files. Spin-Up time is two years. Thank you!

GitHub_Issue2.zip

[sunt05]

Hi Ferdi, Thanks for reporting the issue. flux-wise everything looks OK to me; I guess the abnormal results might have something to do with forcing wind speed: it is known that the current RSL scheme in SUEWS may run into issues if wind speed is very low (e.g., < 0.1 m s-1). Anyway, I'll have a look at your data later this week.

[fbriegel]

Hi Ting,

thank you very much.

I have another quick question regarding the measurement height. Is it the measurement height of wind speed or of all forcing variables?

In this table it is only mentioned for wind speed.

Thanks. Ferdi

[sunt05]

Hi Ferdi, It's actually for all forcing variables.

[fbriegel]

Dear Ting, I wanted to ask if there are any new findings regarding the issue? Thanks, Ferdi

[sunt05]

Hi Ferdi, I have no more new findings regarding the issues discussed above. If you have more questions/concerns, please let me know. Otherwise, please consider to close this issue.

Thanks! Ting

[suegrimmond]

@sunt05 Doesn’t the problem still exist? -Or there needs to be something added to the manual to indicate what to do

[fbriegel]

Yes, the problem still exists.

[sunt05]

Hi Ferdi, I just had another look at your results and re-ran your case: except for the low wind speed I mentioned above, nothing new I can think of to explain the "abnormal" values. Let's take grid 204 in a winter with the issue for example (hint: the plot below can be produced by supy.util.plot_rsl):

You can see the wind speed diagnosed by SUEWS (or more precisely, the RSL scheme) is quite low (<~0.1 m s-1) in the urban canopy, which may cause issues in other diagnostic variables (e.g., T2). And this is a common issue- low wind speed leads to unexpected diagnostics-for almost all PBL-related diagnostic schemes, including the RSL scheme in SUEWS.

So my suggestions would be: 1) double-check your forcing data and measurement height (currently I see a z=35 m is set in your case): see if they are appropriate for your case. To me, a forcing wind speed=0.3 [m s-1] at z=35 [m agl] would certainly lead the model to some issues. 2) double-check your urban morphology settings (building height, frontal area index, etc). And I think 1) is a major issue in this case.

Please let me know if more updates.

Best, Ting

[fbriegel]

Dear Ting,

thanky you for this. I will check it next week and let you know. Best, Ferdi

[github-actions[bot]]

Stale issue message