Feature: standard config selected by validator based on nlayer value

[dayantur]

This PR addresses issue #707 by proposing a logic in the validator that selects a specific sample config (with a specific structure) based on nlayer value.

This PR is also directly related to PR #690 and should be merged after that.

Main changes

• Edited validate_config.py to detect nlayer from user YAML to select appropriate sample config
• Added detect_nlayer_from_user_yaml to orchestrator.py
• Edited phase_a_parameter_update.py and phase_b_science_check.py accordingly
• Added sample_config_1.yml and sample_config_3.yml to meson.build

Further implementations

• Added n=2,4,5,6 cases
• Added comprehensive tests

Future implementations
A more elegant feature that implements a rule/logic to check yaml structure based on user nlayer value and independently from sample_config standard will be addressed in a separate PR.

[github-actions]

🔍 Schema Preview Deployed

Preview URLs:

• 🆕 Preview schemas: https://umep-dev.github.io/SUEWS/preview/pr-712/schemas/suews-config/
• 📋 Preview landing: https://umep-dev.github.io/SUEWS/preview/pr-712/

Production URLs (unchanged):

• ✅ Production schemas: https://umep-dev.github.io/SUEWS/schemas/suews-config/
• 🏠 Production landing: https://umep-dev.github.io/SUEWS/

---

⚠️ Important: Preview schemas are in a subdirectory and do not affect production. The preview pages include warning banners to prevent accidental use in production configs.

[github-actions]

🤖 I've automatically formatted the code in this PR using:

• Python: ruff v0.8.6
• Fortran: fprettify v0.3.7

Please pull the latest changes before making further edits.

[github-actions]

🤖 I've automatically formatted the code in this PR using:

• Python: ruff v0.8.6
• Fortran: fprettify v0.3.7

Please pull the latest changes before making further edits.

[github-actions]

🤖 I've automatically formatted the code in this PR using:

• Python: ruff v0.8.6
• Fortran: fprettify v0.3.7

Please pull the latest changes before making further edits.

[sunt05]

Thanks @dayantur - but isn't #707 already addressed?
Please clarify what this PR is for.

[dayantur]

hi @sunt05 :)

At the moment, all user configs are validated against sample_config.yml, which has nlayer==3.

When user has nlayer≠3:
- nlayer > 3 (e.g., 5 layers): Phase A can't check elements [4] and [5] because the standard only has 3 elements →
incomplete validation
- nlayer < 3 (e.g., 1 layer): Phase A tries to compare against 3 elements, so it adds dummy values for missing
elements [2] and [3] → pollutes user config with fake data

This PR addresses a practical but not yet very elegant solution proposing to:

• Detect nlayer from user config
• Select matching sample_config_{nlayer}.yml (1-7)
• Then validate expected structure: nlayer=5 config → sample_config_5.yml

[sunt05]

I understand your point, but we need a cleaner solution. We shouldn't keep adding sample files to address this. Let's consider another plan.

[dayantur]

I understand your point, but we need a cleaner solution. We shouldn't keep adding sample files to address this. Let's consider another plan.

I agree with you :( This strategy does not work well in the long term.

One idea could be to add rules to phase A associated with nlayer number.
If nlayer is equal to n, then we have some constraints for specific parameters (i.e. array dimensions equal to n or n+1, roofs and walls substructures repeated n times, etc.)

[dayantur]

I understand your point, but we need a cleaner solution. We shouldn't keep adding sample files to address this. Let's consider another plan.

I agree with you :( This strategy does not work well in the long term.

One idea could be to add rules to phase A associated with nlayer number. If nlayer is equal to n, then we have some constraints for specific parameters (i.e. array dimensions equal to n or n+1, roofs and walls substructures repeated n times, etc.)

Hi @sunt05 :) I am succesfully implementing the idea above in draft PR #731 . I will let you know there once ready for a review :)

[sunt05]

Hello @dayantur - it looks like this has been dealt with in #731? if so, shall we close this one?

[dayantur]

this has ben resolved in #731