Is your feature request related to a problem?
SimBoard currently groups simulations under a Case using the case name derived from the E3SM timing file. This is not guaranteed to be globally unique or stable. Different users can reuse the same case name for distinct experiments, and configuration changes across submissions may not be reliably detected.
There is a risk of incorrectly grouping unrelated executions or failing to distinguish configuration drift within a logical case.
Describe the solution you'd like
Evaluate adopting CASE_HASH (from env_case.xml) as the primary identifier for Case grouping.
Key points to validate:
CASE_HASH is expected to remain consistent across executions of the same logical case.CASE_HASH should be unique across distinct E3SM cases.- Observed differences in
CASE_HASH across submissions may indicate configuration changes or case regeneration (related comment)
-
- Confirm expected behavior across multiple submissions before formalizing it as the grouping key.
If validated, use CASE_HASH as the canonical Case identifier instead of relying solely on case name.
Edge Cases
There may be some instances where executions are performed within a case using a new execution command with CIME, resulting a new CASE HASH.
We need to be handle these cases appropriately by falling back to the case name derived from the E3SM timing file.
Describe alternatives you've considered
- Continue grouping by case name only.
- Use case name as primary key with
CASE_HASH as a validation or secondary consistency check.
- Hybrid approach: prefer
CASE_HASH, fall back to case name when missing.
Additional context
CASE_HASH is generated from case parameters in env_case.xml and is intended to uniquely represent a case configuration. It may provide a more reliable grouping key than case name alone, but requires verification across real-world submissions before adoption.
Is your feature request related to a problem?
SimBoard currently groups simulations under a Case using the case name derived from the E3SM timing file. This is not guaranteed to be globally unique or stable. Different users can reuse the same case name for distinct experiments, and configuration changes across submissions may not be reliably detected.
There is a risk of incorrectly grouping unrelated executions or failing to distinguish configuration drift within a logical case.
Describe the solution you'd like
Evaluate adopting
CASE_HASH(fromenv_case.xml) as the primary identifier for Case grouping.Key points to validate:
CASE_HASHis expected to remain consistent across executions of the same logical case.CASE_HASHshould be unique across distinct E3SM cases.CASE_HASHacross submissions may indicate configuration changes or case regeneration (related comment)If validated, use
CASE_HASHas the canonical Case identifier instead of relying solely on case name.Edge Cases
There may be some instances where executions are performed within a case using a new execution command with CIME, resulting a new CASE HASH.
We need to be handle these cases appropriately by falling back to the case name derived from the E3SM timing file.
Describe alternatives you've considered
CASE_HASHas a validation or secondary consistency check.CASE_HASH, fall back to case name when missing.Additional context
CASE_HASHis generated from case parameters inenv_case.xmland is intended to uniquely represent a case configuration. It may provide a more reliable grouping key than case name alone, but requires verification across real-world submissions before adoption.