Allow CAM compsets "out-of-the-box" to specify CLM namelist options for specific F compsets #842
Comments
|
Can cams buildnml update the user_nl_clm and would that be adequate? |
|
Hi Cheryl
Having CAM update the CLM user_nl_clm sounds iffy to me. It makes me
nervous that CAM would be modifying a file that the user expects they have
total control over.
Seems like this would be worth having a small meeting over....
*Erik Kluzek, (CGD at NCAR)*
*National Center for Atmospheric Research*
*Boulder CO, *
*(off) (303)497-1326 (fax) (303)497-1348*
*(skype) ekluzek (cell) (303)859-0183*
*Pronouns: he/his/him*
*------------------ Home page ------------------------*
* http://www.cgd.ucar.edu/~erik <http://www.cgd.ucar.edu/~erik>*
* https://staff.ucar.edu/users/erik
<https://staff.ucar.edu/users/erik>*
*!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!*
…On Tue, Nov 29, 2016 at 11:02 AM, jedwards4b ***@***.***> wrote:
Can cams buildnml update the user_nl_clm and would that be adequate?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#842 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ALAswDINxFWTiwsrFF3hTXokGHSRUeRdks5rDGimgaJpZM4K_OiN>
.
|
|
This is already what a user mod does, you seem to be saying that cam should not be allowed to adjust the clm namelist at all? |
|
It seems to me that CLM needs to provide an appropriate build-namelist use
case for this particular compset.
-Francis
…On Tue, Nov 29, 2016 at 11:21 AM, jedwards4b ***@***.***> wrote:
This is already what a user mod does, you seem to be saying that cam
should not be allowed to adjust the clm namelist at all?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#842 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AI6Kpk2wVi1y10ozfWGtu5SD4mpfqAIPks5rDG09gaJpZM4K_OiN>
.
|
|
A user mod under the appropriate test list is something that a developer puts together. When a user selects one of them they are applying those changes to their case and they assume the developer that created it knew what they were doing. The user then could add additional changes on top of that starting point. I'm nervous about the idea of CAM changing the user_nl_clm in a way that the user doesn't realize. I like Francis's idea of having CLM provide a use-case or a test mod that makes sense for these compsets. Then CLM is responsible for it, and if CLM changes namelist options in a given version -- it's up to CLM to fix it for that case to work. That way CAM isn't tied into specific versions of CLM. In general we want to make components independent of each other whenever possible. CAM having to know about the internal namelist settings of CLM operates against that principle. But, I'm also not sure I understand this entire issue and it seems to me having a quick in person meeting might be more productive than lots of online chat. |
|
To clarify our final purpose.
Basically, we want to have a spin up land initial condition for our F2000 compset. The purpose of this compset is to do 5-year runs so we cannot do a cold start for the land. This is why we need this compset to get a spunup file for finidat. More importantly, we want this coming out of the box.
So the final purpose of this discussion is how to achieve this. I.e. F2000 starts out of the box from a spunup land
ps this compset is called F2000_DEV for the time being but will be renamed F2000 later on.
…Sent from my iPhone
On Nov 29, 2016, at 11:37 AM, Erik Kluzek ***@***.***> wrote:
A user mod under the appropriate test list is something that a developer puts together. When a user selects one of them they are applying those changes to their case and they assume the developer that created it knew what they were doing. The user then could add additional changes on top of that starting point. I'm nervous about the idea of CAM changing the user_nl_clm in a way that the user doesn't realize.
I like Francis's idea of having CLM provide a use-case or a test mod that makes sense for these compsets. Then CLM is responsible for it, and if CLM changes namelist options in a given version -- it's up to CLM to fix it for that case to work. That way CAM isn't tied into specific versions of CLM. In general we want to make components independent of each other whenever possible. CAM having to know about the internal namelist settings of CLM operates against that principle.
But, I'm also not sure I understand this entire issue and it seems to me having a quick in person meeting might be more productive than lots of online chat.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
What if you just define a new compset called F2000S? We did something similar in ACME to distinquish between compsets with and without a spun-up ocean. |
|
My initial reaction is that you should use user_mods for this. Then CAM has complete control. Also, I have never liked the use_cases in CLM, and don't like the idea of adding more. (I find it confusing to have this totally separate way of setting defaults.) But I also hear the desire to not have to remember an extra argument, which makes sense to me too. How about this solution, which I believe would be easy to implement: Add a USER_MODS_DIR xml variable in env_case. Then a given compset could set the value of this variable (which I guess would be relative to SRCROOT, or maybe relative to the relevant cime_config directory). Then, in scripts/create_newcase, change this code: if user_mods_dir is not None:to also check the case's value of USER_MODS_DIR. For now, it throws an error if both the compset specifies USER_MODS_DIR and also the user tries to specify this on the command line. |
|
There is already a USER_MODS_DIR in env_case.xml |
|
Oh, so can we have the compset set it? I realized there may be some complexity in terms of ensuring that two components don't both try to set this variable... I don't know how this is handled for other xml variables that could potentially be set by multiple components. |
|
Isn't the correct solution here for the cam developers to ask the clm developers to |
I don't like having CLM have information specific to a particular CAM compset, particularly in this case where the expectation is that there will be frequent changes (at least, that's my understanding) - since every time CAM wants to change this, it would require a new CLM tag. That said, I don't feel strongly about this. |
|
Well, I feel more strongly about it. The whole reason we moved the component-specific compsets into the respective component repositories is to allow each component full control over its compsets. Any solution that requires a CLM change before a change can be made in an F compset breaks this. |
|
The problem is that F-cases aren't really standalone CAM-only cases. They are coupled land-atmosphere cases that happen to live in cam/cime_config. So you have to coordinate the changes. But CLM doesn't need to know anything about what F-case its being used in. Suppose the current F2000 has this in its longname: CLM has to create a phys option called: |
|
Sure, CAM can't take advantage of non-existent CLM features but it should be able to use existing feature combinations without changes to CLM. |
|
I stand by my original request that a user should be able to use an F compset without needing to specify a CLM namelist. For testing purposes, when we use create_test we can specify these in a use_case. When a user uses create_newcase, there is no way that CAM has control over the CLM namelist settings for our F compset (and Cecile is still manually setting these every time she runs). How do we convey to the user that they need to set specific CLM namelists to duplicate the scientifically supported F2000 runs? |
|
@cacraigucar we added a feature in CLM via an xml variable called LND_TUNING_MODE. And then we removed it, but now we are adding it back in. The options it can be set to right now are: clm4_0_default,clm5_0_cam5.5,clm5_0_GSW3P,clm4_5_CRUNCEP so the idea is the CLM version and then the atmosphere forcing it's coupled to. We currently aren't doing anything different for a B compset than a F compset. I think this is the kind of thing you want. But, any changes to the clm5_0_cam5.5 settings would need to go into a CLM tag. So it's likely to be out of date, but obviously we should be able to get it right for the CESM2.0 release. But, the good thing is that CAM's compsets could set this XML variable as appropriate. |
|
After talking with Jim and Erik, CAM is able to set CLM_NAMELIST_OPTS in our cime_config/config_compsets.xml. This will allow us to set the CLM namelist settings that Cecile is using for her tests to the same settings in our CAM F compsets. Once we have this setup, users will no longer need to copy Cecile's user_nl_clm files for their runs. I am closing this issue |
Currently the F2000_DEV compset requires three CLM namelist options to be specified in order to run properly. We want a way to be able to have this CAM compset run out-of-the-box without the user needing to know that a specific CLM user_mods file needs to be included. Previous email discussions included @fvitt, @jedwards4b , @mvertens, @cecilehannay, @cacraigucar
Previous email discussion:
Mariana Vertenstein mvertens@ucar.edu
Oct 13
Reply
to Jim, me, Francis, Cecile
I think this is the cleanest way forwards for now. We can start thinking of linking in a user_mods directory to a compset - which we cannot do right now. But this method gives you the greatest flexibility of bringing in namelist changes from other components cleanly in a cam compset.
On Thu, Oct 13, 2016 at 3:18 PM, Jim Edwards jedwards@ucar.edu wrote:
I think Cheryl said that they already do it for testing but wanted to extend it to
user mods. I suggested user_mods but Cheryl didn't like the idea of having an additional command line argument to create_newcase.
On Thu, Oct 13, 2016 at 3:06 PM, Mariana Vertenstein mvertens@ucar.edu wrote:
One more question - do we only want this for testing? That is my understanding - so this could to in testmods.
On Thu, Oct 13, 2016 at 3:04 PM, Mariana Vertenstein mvertens@ucar.edu wrote:
I think we need to do this with user_mods for this compset. I think this is the most general way forwards to do this. Let me talk to Jim today/tomorrow before I leave to see if we can come up with a process that would be general moving forwards.
Mariana
On Thu, Oct 13, 2016 at 3:00 PM, Cheryl Craig cacraig@ucar.edu wrote:
Mariana-
Cecile is running with three CLM namelist options which are required for F2000_DEV to give the results that she is currently getting. We want to add these into CAM so that anyone using the F2000_DEV compset gets these settings (but it doesn't affect any B compsets).
I spoke with Jim and he thought that I would not be able to put a CLM_NML_USE_CASE in CAM's config_component.xml as he believes that only the primary component retrieves the use_case from its own config_component.xml. He thought I'd need to ask CLM to put this change into their trunk, but suggested I ask you.
Is there a way that CAM can put this into our trunk and control it as we see fit? Not that it probably matters, the namelist parameters we want to set are: use_init_interp, finidat and init_interp_fill_missing_with_natveg.
Thanks,
Cheryl
The text was updated successfully, but these errors were encountered: