# Initial albedo values

**URL:** <https://community.suews.io/t/initial-albedo-values/153>\
**Category:** General\
**Created:** [20 August 2026 11:09 UTC](https://community.suews.io/t/initial-albedo-values/153 "2026-08-20T11:09:25Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Janka](https://avatars.discourse-cdn.com/v4/letter/j/df705f/32.png) [@Janka](https://community.suews.io/u/Janka)\
**Post date:** [20 August 2026 11:09 UTC](https://community.suews.io/t/initial-albedo-values/153/1 "2026-08-20T11:09:25Z")

</div>

Hi, yet another question - or rather flagging a potential issue with albedo values in SUEWS 2026.5 vs UMEP’s Database Prepare. In its reference table we have:

- Helsinki deciduous trees: alb\_min = alb\_max = 0.16 (ref ID 41240027), while the initial alb\_id is 0.12
- Helsinki grass: alb\_min = alb\_max = 0.19 (ref ID 41240029), while the initial alb\_id is 0.18

These therefore fall outside the allowed initial albedo range in 2026.5. All works fine with UK values.

Any tips on how to proceed (other than using UK albedo values:)?

Thanks in advance! /Janka

---

<div class="post-metadata">

**Author:** ![sunt05](https://dub1.discourse-cdn.com/flex014/user_avatar/community.suews.io/sunt05/32/5_2.png) [@sunt05](https://community.suews.io/u/sunt05)\
**Post date:** [20 August 2026 21:11 UTC](https://community.suews.io/t/initial-albedo-values/153/2 "2026-08-20T21:11:54Z")

</div>

Thanks for flagging this.

The Helsinki values themselves are fine: SUEWS allows `alb_min == alb_max` for a constant albedo, and only objects when `alb_min > alb_max`. The sample config does this for evergreen trees (both 0.1).

The error comes from `alb_id`, the initial albedo. In the sample config each surface’s `alb_id` is set to its `alb_min`, 0.12 for deciduous and 0.18 for grass. When you change `alb_min` and `alb_max`, `alb_id` is left pointing at the old range, and that is a hard error at config load rather than a warning.

The fix is to set `alb_id` to `null` on those two surfaces:

```yaml
initial_states:
  dectr:
    alb_id:
      value: null
  grass:
    alb_id:
      value: null

```

SUEWS then derives it from `lai_id` and the `alb_min`/`alb_max` pair, giving exactly 0.16 and 0.19, and the validation report lists it under NO ACTION NEEDED as auto-calculated. Setting it explicitly to 0.16 and 0.19 works too, since the check is inclusive. The field is documented on the [vegetation initial state page](https://docs.suews.io/stable/inputs/yaml/config-reference/initialstateveg.html).

One thing to avoid: do not delete the `alb_id` key altogether. The config itself is still valid, but the updated YAML that `suews validate` writes puts the key back at the wrong indentation, nested inside `decidcap_id`, and that file then fails to load. I have reproduced it and will get it fixed.

Worth noting separately that `alb_min == alb_max` switches off the seasonal albedo cycle for that surface, because the daily update scales the change by `(alb_max - alb_min)`. If 0.16 is a growing-season value, you may prefer it as `alb_max` with a lower leaf-off `alb_min`.

Your wider point is tracked in [#1007](https://github.com/UMEP-dev/SUEWS/issues/1007), and the auto-initialisation came out of that discussion ([#1132](https://github.com/UMEP-dev/SUEWS/issues/1132)). Useful evidence for that thread.

Did the 0.12 and 0.18 come from Database Prepare itself, or from the sample config you started from?