Coupling between ECH and Spartacus result in too low Qs-values

[biglimp]

I started a new notebook for us to test things.

https://github.com/gusbacos/SUEWS_DB_Typology_test/blob/main/code/test-coupling_SS_ECH.ipynb

[sunt05]

• using "default" settings as in the above notebook:

• after modifying several building properties (see this notebook):
  • increase building facet depth
  • increase inner surface temperature

Further tweaks could be attempted, but I'm wondering if the above looks OK to us?

[biglimp]

Thanks. I will have a look soon and come back...

[biglimp]

• Hard to see which one of your changes (albedo, thickness, T_in) that influence Qs. I will run them separately to check.
• So you can separate Qs output for each land cover type? nice! That makes it easier to investigate.
• I am not comfortable to change the input values (albedo, thickness etc.) I assumed they were "real values". We should check with the others.

[sunt05]

• Hard to see which one of your changes (albedo, thickness, T_in) that influence Qs. I will run them separately to check.

thE results seem to more sensitive to thickness.

• I am not comfortable to change the input values (albedo, thickness etc.) I assumed they were "real values". We should check with the others.

I've noticed the default parameters come from the layout namelist file, mostly test values from when I first developed the EHC module. These aren't quite reasonable, particularly thickness. The modified ones seem more sensible to me.

[biglimp]

Did you see the values for buildings that Meg presented in her pptx from our last meeting (slide 7)? SUEWS_Issues_26.02.24.pptx

Where values are aggregated (Lindberg et al. 2020) and not so useful but for KCL we could use ESTM-code 801 from SUEWS_ESTMCoefficients.txt:

Code	Surf_thick1	Surf_k1	Surf_rhoCp1	Surf_thick2	Surf_k2	Surf_rhoCp2	Surf_thick3	Surf_k3	Surf_rhoCp3	Surf_thick4	Surf_k4	Surf_rhoCp4	Surf_thick5	Surf_k5	Surf_rhoCp5	Wall_thick1	Wall_k1	Wall_rhoCp1	Wall_thick2	Wall_k2	Wall_rhoCp2	Wall_thick3	Wall_k3	Wall_rhoCp3	Wall_thick4	Wall_k4	Wall_rhoCp4	Wall_thick5	Wall_k5	Wall_rhoCp5	Internal_thick1	Internal_k1	Internal_rhoCp1	Internal_thick2	Internal_k2	Internal_rhoCp2	Internal_thick3	Internal_k3	Internal_rhoCp3	Internal_thick4	Internal_k4	Internal_rhoCp4	Internal_thick5	Internal_k5	Internal_rhoCp5	nroom	Internal_albedo	Internal_emissivity	Internal_CHwall	Internal_CHroof	Internal_CHbld
801	0.05	1.142	1606620	0.15	0.93	1500000	0.12	0.05	290000	-999	-999	-999	-999	-999	-999	0.087	0.760645	1046908.363	0.0497	0.93	1500000	0.0497	0.93	1500000	-999	-999	-999	-999	-999	-999	0.035	0.93	1500000	0.035	0.93	1500000	0.035	0.93	1500000	-999	-999	-999	-999	-999	-999	10	0.5	1	0.0015	0.0015	0.0015

original text as in the ESTM table

``` Code Surf_thick1 Surf_k1 Surf_rhoCp1 Surf_thick2 Surf_k2 Surf_rhoCp2 Surf_thick3 Surf_k3 Surf_rhoCp3 Surf_thick4 Surf_k4 Surf_rhoCp4 Surf_thick5 Surf_k5 Surf_rhoCp5 Wall_thick1 Wall_k1 Wall_rhoCp1 Wall_thick2 Wall_k2 Wall_rhoCp2 Wall_thick3 Wall_k3 Wall_rhoCp3 Wall_thick4 Wall_k4 Wall_rhoCp4 Wall_thick5 Wall_k5 Wall_rhoCp5 Internal_thick1 Internal_k1 Internal_rhoCp1 Internal_thick2 Internal_k2 Internal_rhoCp2 Internal_thick3 Internal_k3 Internal_rhoCp3 Internal_thick4 Internal_k4 Internal_rhoCp4 Internal_thick5 Internal_k5 Internal_rhoCp5 nroom Internal_albedo Internal_emissivity Internal_CHwall Internal_CHroof Internal_CHbld ! 801 0.05 1.142 1606620 0.15 0.93 1500000 0.12 0.05 290000 -999 -999 -999 -999 -999 -999 0.087 0.760645 1046908.363 0.0497 0.93 1500000 0.0497 0.93 1500000 -999 -999 -999 -999 -999 -999 0.035 0.93 1500000 0.035 0.93 1500000 0.035 0.93 1500000 -999 -999 -999 -999 -999 -999 10 0.5 1 0.0015 0.0015 0.0015 ! GLA Urban fabric >80 London GLA ```

[sunt05]

The parameter values in this line seem largely fine, except for the thickness of generic surfaces (surf_thickX), which is too thin and doesn't align with other land surface models. The total should be ~2 m (e.g. this NOAH example).

[biglimp]

I was thinking about the walls.

[sunt05]

Walls seem a bit thin but are acceptable (I'd increase them to ~25 cm). Other thermal properties are satisfactory.

[biglimp]

hm, now I am confused. Where is roof coefficients for ESTM? Did we use same as for walls? Is Surf_thick1 etc. roofs for e.g. code 801?

Code 807 should be used for paved.

One more questiion. What is the best strategy to fill all five layers in a wall with values if you only have data for three layers?

[sunt05]

One more questiion. What is the best strategy to fill all five layers in a wall with values if you only have data for three layers?

We may simply split the thick layer in half and assign identical thermal properties.

[biglimp]

hm, now I am confused. Where is roof coefficients for ESTM? Did we use same as for walls? Is Surf_thick1 etc. roofs for e.g. code 801?

Found the answer

Code 807 should be used for paved.

These values are abit different from the values used now. Will be interesting to see what effect they have

[biglimp]

@sunt05 , I got an idea over the weekend. How about adding a very small building fraction and one layer in Spartacus just to see how the coupling alters the values for the asphalt surface?

[sunt05]

Hi @biglimp, that sounds good - please give it a go!

[biglimp]

Pretty much the same result if i use Spartacus (1 % buildings, 3 meter high) instead of NARP. See below.

I noticed that the kernal breaks if you run with Spartacus and no buildings at all. I think Meg has also reported this.

[sunt05]

Great - thanks for the update.

Then, can we say EHC performs reasonably well?

BTW, EHC stands for "explicit heat conduction".

[biglimp]

I just want to test some more tweaking with the KCL-case before we report back to the others, by setting everything as we did for the URBANFLUXES-project, e.g., the paved used for Säve is the numbers we used for London paved etc. Try to do this today and report back.

[biglimp]

@sunt05 , tin_wall and tin_roof in Gridlayout, is that the constant indoor temperature of is it an initial value? If so, where do you set in indoor temperature?

We could consider using eq. 3 in Lindberg et al., to make indoor temperature vary based on outdoor temperature and indoor base temperature.

[sunt05]

That's the indoor temperature used as the lower boundary condition—a constant value for now.

A dynamic one sounds good—please submit an issue to the SUEWS repository so I can track it there.

[biglimp]

I will. So how is indoor temperature set at the moment and how does it evolve related to outdoor temperature? Is there an upper bounadry condition?

[sunt05]

So how is indoor temperature set at the moment and how does it evolve related to outdoor temperature?

Indoor air is not taken into account at the moment - so no indoor temperature is available for configuration.

Is there an upper bounadry condition?

Yes, it's coupled and updated with SUEWS.

[biglimp]

So how is indoor temperature set at the moment and how does it evolve related to outdoor temperature?

Indoor air is not taken into account at the moment - so no indoor temperature is available for configuration.

Then you need to explain to me how you do this. Energy (heat) is transported through the wall during daytime cos of a gradient that must be affected of the temperature at both sides (outside/inside) where indoor is one side. Same goes for nighttime.

Is there an upper boundary condition?

Yes, it's coupled and updated with SUEWS.

I mean an upper boundary condition for indoor temperature

[sunt05]

Indoor surface temperatures (i.e., ceilings and walls) are set by tin parameters - we mentioned above.

Outdoor temperatures are coupled with SUEWS and updated accordingly.

Thus, a gradient is present to allow heat conduction. Yet, currently, the heat is stored only in building materials, without indoor air being considered – a difference from ESTM.

[biglimp]

Not much difference when using settings from URBANFLUXES. I plotted all components on the energy balance. We still have too high Qh and too low Qs, especially on day with high Qn. I dont think we can get much further now. I upload the notebook I have been working on. You can have a look here to see if I did everything correct. Maybe it is time we should call in the others for a meeting to discuss how we move forward?

[sunt05]

Ok, to summarise what has been done so far:

• ECH without SS: results seem reasonable.
• ECH with SS: too low QS and too high QH.

Is the above correct?

If so, I'll have a look at your notebook and further investigate this later today.

[biglimp]

Correct apart from that ECH with SS show good agreement if there are no buildings (airport), but not if you have large fraction of buildings. I also come to wonder about the water fraction at KCL (14%). How is that considered when ECH/SS is used?

[sunt05]

Thank you for the confirmation. I'll take this forward.

Regarding water, the issue of heat conduction accounting for radiation extinction is acknowledged. While feasible, let's set it aside for the moment.

[sunt05]

From your notebook settings, I see no obvious issues – they seem fine.

While investigating the low QS, especially now that we're concentrating on London, @biglimp could you compare the EHC+SS modelled fluxes with the observed ones? This might help us understand how large the bias is.

What do you think?

[biglimp]

You mean observed from the canyon in Göteborg?

[sunt05]

Sorry about the confusion if I misunderstood the context - I meant the observed values for the fluxes modelled in the above figure.

[sunt05]

Sorry about the confusion if I misunderstood the context - I meant the observed values for the fluxes modelled in the above figure.

If this is London, then QH and QE should be available.

[biglimp]

No, this is just model output. Dont know where I can find that data. Better if you do that. I was thinking about the data we have for the Canyon that we used in Lindberg et al. 2020 where we have observed Qs.

[sunt05]

No, this is just model output. Dont know where I can find that data. Better if you do that.

OK, I should have the London data and will do it later.

I was thinking about the data we have for the Canyon that we used in Lindberg et al. 2020 where we have observed Qs.

Setting up SUEWS for your canyon would be great - it may give us the "truth" to align the model with.

[biglimp]

@sunt05 , at first examination we have low Qs in canyon also but I am having trouble plotting the data due to ValueError: cannot reindex on an axis with duplicate labels that I cant get to go away. Please help. The notebook is in issue6 branch (test-torgg.ipynd)

[sunt05]

the issue stems from the duplicate timestamps in the observational data. for example: https://github.com/gusbacos/SUEWS_DB_Typology_test/blob/5f82bb4319e5dc9a996a93b39f8997f16d2170af/data/canyon_gbg/GbgTorgg_canyon_QSresid.csv#L3380-L3381

Such cases must be resolved before merging the observations into df_comp.

BTW, do we expect duplicate timestamps, or should we reindex all records given the frequency (30 min, correct?)?

[biglimp]

the issue stems from the duplicate timestamps in the observational data. for example:

https://github.com/gusbacos/SUEWS_DB_Typology_test/blob/5f82bb4319e5dc9a996a93b39f8997f16d2170af/data/canyon_gbg/GbgTorgg_canyon_QSresid.csv#L3380-L3381

Such cases must be resolved before merging the observations into df_comp.

BTW, do we expect duplicate timestamps, or should we reindex all records given the frequency (30 min, correct?)?

Hm, I think this comes from too few decimal places. Yes, 30 minute would be good. Is it possible to resample the data to 30 min before creating an index?

[sunt05]

Hello! I revisited the CSV file and noticed that the issue might be more complex—the timestamps aren't just non-monotonic; they're identical. It seems like multiple sensors could be taking measurements simultaneously at certain intervals.

https://github.com/gusbacos/SUEWS_DB_Typology_test/blob/5f82bb4319e5dc9a996a93b39f8997f16d2170af/data/canyon_gbg/GbgTorgg_canyon_QSresid.csv#L3384-L3389

Maybe we should group the measurements by timestamp and calculate their averages?

[biglimp]

Hello! I revisited the CSV file and noticed that the issue might be more complex—the timestamps aren't just non-monotonic; they're identical. It seems like multiple sensors could be taking measurements simultaneously at certain intervals.

https://github.com/gusbacos/SUEWS_DB_Typology_test/blob/5f82bb4319e5dc9a996a93b39f8997f16d2170af/data/canyon_gbg/GbgTorgg_canyon_QSresid.csv#L3384-L3389

Maybe we should group the measurements by timestamp and calculate their averages?

There is something strange going on. Let me check if I can sort this out by asking Frans.

[biglimp]

I looked closer and it is a problem with the dectime column. I suggest we use the attached file and the new_datetime column as timesteps. GbgTorgg_canyon_QSresid_timecorrected.xlsx

[biglimp]

Here is a first comparison with observed data from Canyon GBG. We could probably tweek the model with better values but overall, it looks like we underestimate Qg, especially during hot days. This notebook is found here

[sunt05]

Thanks @biglimp for the interesting plots! Will look at the notebook after I wrap up my EGU trip this afternoon 😀