You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are currently two options to build-namelist for changing how initial conditions (finidat files) are selected. -ignore_ic_date and -ignore_ic_year. I don't think users normally actually set either of them, they are picked for you in buildnml. They came from how CAM was doing IC selection, but doesn't quite work with what CTSM needs to do. For CAM the starting year usually meant nothing, so having it as default made some sense. For CTSM with Crop though ignore_ic_date, is problematic because of the counters that determine crop management. So you can't really use that for crop. And for CTSM for transient cases, the year is meaningful, since that's what the landuse should be set to. But, for control cases, the year is meaningless, and you need to go by the "sim_year". So these should be set for you, rather than expecting the user to be able to figure this all out. It's possible there might be a reason for the user to override it -- but I'm not convinced on that.
So the ignore settings are one thing, another is how the IC selection is done. It needs to be done in such a way that you get the right land-use year, and we want that to be solid for both transient and control cases.
This is related to #544 and really is the underlying cause of it.
General bug information
CTSM version you are using: ctsm1.0.dev13
Does this bug cause significantly incorrect results in the model's science? No
Configurations affected: The problem in #544 has to do with cases coupled to CAM.
Details of bug
The ignore command line settings should be moved to internal to CLM buildnamelist. We should decide if the user really would ever have a reason to override them or not. If not, they should be removed as a user setting. Then we need to make sure the mechanism to pick the land-use year is robust and works for both control and transient. Then I think there's some code cleanup that can happen to make the logic clearer as well as more robust.
Important details of your setup / configuration so we can reproduce the bug
Brief summary of bug
There are currently two options to build-namelist for changing how initial conditions (finidat files) are selected. -ignore_ic_date and -ignore_ic_year. I don't think users normally actually set either of them, they are picked for you in buildnml. They came from how CAM was doing IC selection, but doesn't quite work with what CTSM needs to do. For CAM the starting year usually meant nothing, so having it as default made some sense. For CTSM with Crop though ignore_ic_date, is problematic because of the counters that determine crop management. So you can't really use that for crop. And for CTSM for transient cases, the year is meaningful, since that's what the landuse should be set to. But, for control cases, the year is meaningless, and you need to go by the "sim_year". So these should be set for you, rather than expecting the user to be able to figure this all out. It's possible there might be a reason for the user to override it -- but I'm not convinced on that.
So the ignore settings are one thing, another is how the IC selection is done. It needs to be done in such a way that you get the right land-use year, and we want that to be solid for both transient and control cases.
This is related to #544 and really is the underlying cause of it.
General bug information
CTSM version you are using: ctsm1.0.dev13
Does this bug cause significantly incorrect results in the model's science? No
Configurations affected: The problem in #544 has to do with cases coupled to CAM.
Details of bug
The ignore command line settings should be moved to internal to CLM buildnamelist. We should decide if the user really would ever have a reason to override them or not. If not, they should be removed as a user setting. Then we need to make sure the mechanism to pick the land-use year is robust and works for both control and transient. Then I think there's some code cleanup that can happen to make the logic clearer as well as more robust.
Important details of your setup / configuration so we can reproduce the bug
See #544
The text was updated successfully, but these errors were encountered: