Preserve model namelist variable names using component namespaces
Summary
Instead of enforcing a common variable naming convention across all model components, the workflow engine should use the variable names exactly as they are defined in each model's namelist. To avoid naming conflicts between components, variables should be qualified with a predefined component identifier or prefix.
Details
The current approach requires variables from different model components to follow a unified naming convention. While this avoids duplicate names, it also introduces translation between the workflow engine and the model configuration. After conversation with @jjokella , I agree that this can lead to confusion.
Each model already defines a well-established set of variable names in its namelist. Reusing these names directly would make the workflow configuration more intuitive.
By combining the original namelist variable name with a component identifier, duplicate variable names can be avoided without requiring all components to adopt a shared naming scheme.
The workflow engine would need to resolve variables based on their component namespace. This change would not be backward compatible! As a result, migrating to this approach would require adapting every existing Simulation-Experiment.
In total I would opt for the change in the naming scheme.
Proposed Approach
Use the original variable names from each model's namelist and qualify them with a predefined component identifier.
For example:
clm.hist_nhtfrqicon.output_intervalparflow.TimingInfo.StopTime
(or an equivalent syntax).
The important point is that:
- variable names remain identical to those used in the model namelist,
- each component has its own namespace,
- uniqueness is achieved through the component identifier rather than by unified variables.
Benefits
- Eliminates unnecessary mapping between workflow variables and model namelist variables.
- Makes workflow configurations easier to understand for users familiar with the individual model components.
- Reduces maintenance when model namelists evolve.
Preserve model namelist variable names using component namespaces
Summary
Instead of enforcing a common variable naming convention across all model components, the workflow engine should use the variable names exactly as they are defined in each model's namelist. To avoid naming conflicts between components, variables should be qualified with a predefined component identifier or prefix.
Details
The current approach requires variables from different model components to follow a unified naming convention. While this avoids duplicate names, it also introduces translation between the workflow engine and the model configuration. After conversation with @jjokella , I agree that this can lead to confusion.
Each model already defines a well-established set of variable names in its namelist. Reusing these names directly would make the workflow configuration more intuitive.
By combining the original namelist variable name with a component identifier, duplicate variable names can be avoided without requiring all components to adopt a shared naming scheme.
The workflow engine would need to resolve variables based on their component namespace. This change would not be backward compatible! As a result, migrating to this approach would require adapting every existing Simulation-Experiment.
In total I would opt for the change in the naming scheme.
Proposed Approach
Use the original variable names from each model's namelist and qualify them with a predefined component identifier.
For example:
clm.hist_nhtfrqicon.output_intervalparflow.TimingInfo.StopTime(or an equivalent syntax).
The important point is that:
Benefits