Feat: add upper limit to nlayer to avoid run crashes

[dayantur]

At the moment, SPARTACUS has hardcoded dimension 15 for nlayer, and so that should be reflected in a upper limit in the nlayer input Pydantic class. This PR adds le to Field of nlayer in surface.py to prevent run crashes.

[github-actions]

CI Build Plan

Changed Files

Python source (2 files)

• src/supy/data_model/core/surface.py
• src/supy/data_model/validation/pipeline/phase_a.py

Documentation (2 files)

• src/supy/data_model/core/surface.py
• src/supy/data_model/validation/pipeline/phase_a.py

Build Configuration

	Configuration
Platforms	Linux x86_64
Python	3.9, 3.14
Test tier	standard (all except slow)
UMEP build	Skipped (no ABI changes)
PR status	Ready (standard matrix)

Rationale

• Python source changed -> single-platform build
• No compiled extension changes -> UMEP build skipped (nightly provides coverage)

---

_{Updated by CI on each push. See path-filters.yml for category definitions.}

[github-actions]

Preview Deployed

Content	Preview URL
Site	https://suews.io/preview/pr-1206/
Docs	https://suews.io/preview/pr-1206/docs/

Note

This preview is ephemeral. It will be lost when:

• Another PR with site/ or docs/ changes is pushed
• Changes are merged to master
• A manual workflow dispatch runs

To restore, push any commit to this PR.

[dayantur]

hi @sunt05 - I discovered this last week while discussing with other users that are doing dev and runs with SPARTACUS. I checked again this week while working on SPARTACUS veg and we actually have a limit in fortran code at 15 - so I added that to Pydantic. Minimal change but still let me know if this sounds good to you! I will add the CHANGELOG after approval.

[suegrimmond]

This should tell the user they will need to change the Fortran if > 15.

[sunt05]

Thanks for this @dayantur — one small addition needed, see inline comment.

[dayantur]

hi @sunt05 @suegrimmond

• I've added the ge=1 to the Pydantic Field
• I've added a guard in phase_a.py that warns user if entered nlayer>15

let me know if we are happy with the changes!

[sunt05]

We should probably frame this as a constraint rather than expecting the user to change the Fortran code, which doesn’t seem reasonable at this point, right?

[dayantur]

I agree. But shall we leave this as a NO ACTION NEEDED warning or enforce a proper stop/ACTION NEEDED?

I would suggest the first one, warning the user that the model will not run otherwise (as we also have an hard stop with the guard in Pydantic)

[sunt05]

Sounds good. Also please rephrase the warning message.

[suegrimmond]

We should probably frame this as a constraint rather than expecting the user to change the Fortran code, which doesn’t seem reasonable at this point, right?

• 15 stops the model - but if needed - as we have for some key tests - this can be adjusted in the FORTRAN - so we are not asking the user to do it - but is scientifically possible

[dayantur]

@sunt05 @suegrimmond what about something like:
nlayer={nlayer} exceeds the supported range [1, 15]. SUEWS will not run with this setting. Reduce nlayer to 15 or fewer layers; higher values are possible but need changes in the code.

Not sure if this phrasing would work. Otherwise, we can discuss this on Tue meeting :)

[sunt05]

Thanks, @dayantur. Just one minor comment on wording; otherwise, it looks good to me.

[sunt05]

Thanks @dayantur for this - I've updated the warning message to be clearer - merging this now.