Replies: 3 comments
-
I think it's because we would constantly find that list to be out of date and need revision. Attempting to do something similar, cesm introduced a --run-unsupported flag to create_newcase and maintains a list of supported compsets and resolutions (based on the list of tested configurations). However this usefulness of this flag is debatable since many users, once they learn of the flag, always use it. |
Beta Was this translation helpful? Give feedback.
-
Seems like this issue is related: #4754 |
Beta Was this translation helpful? Give feedback.
-
Thanks for making that connection, @jedwards4b . #4754 is along similar lines as this, though addressing a different problem: What combination of components are valid in the system? i.e., what is a valid compset at this high level? I do feel like, if we want a moderately user-friendly system, it's important to think about how we can take knowledge that currently mainly exists in the heads of a handful of experts and present that knowledge in a way that's useful for users. I do sympathize with @jedwards4b 's point, though, that we want to do this in a way that won't be too hard to maintain. To me, the "valid compset" problem feels easier in this respect than the compset-grid compatibility problem, since the former tends to change more slowly than the latter. See also this issue in the CESM repo that is closely related to this discussion: ESCOMP/CESM#188 |
Beta Was this translation helpful? Give feedback.
-
One "feature" of CIME is that you can create a case with any available compset and gridset even if has never been tried or validated and you would only get an error if an initial condition file for the specified resolution was missing.
Why did CIME never implement some kind of list of allowed combinations of compset and gridset that would flag an error at create_newcase stage if it wasn't found?
Beta Was this translation helpful? Give feedback.
All reactions