Add a NUOPC cap #133
Comments
|
Note this is both a CICE5 and CICE6 NUOPC cap. How are we going to handle the CAP for CICE5? The plan was not really to update the old SVN trunk part of github. Thoughts? |
|
We will add a cap to CICE6 in the github repo. If others want to use older versions of CICE with NUOPC, it's up to them to implement and support a cap. I don't see any reason to provide this for the community with CICE5 at this point. NEMS already has a cap for CICE5, and CESM has a cap for CICE5. RASM is using the colpkg version and does not have plans to go to NUOPC anytime sooner. I believe ACME will not be using NUOPC anytime soon. So, I think we can support a NUOPC cap in CICE6. It's likely to be easy to migrate that to CICE5 or CICE colpkg if other groups want that. There are versions of a NUOPC cap for CICE5 already floating around for reuse in the community. Ultimately, I think we want to encourage users to migrate to CICE6. Maybe not including a supported NUOPC cap with earlier versions is one way to do that. Just my opinion, I know there may be others. |
|
I talked to Cecilia Deluca about this. I think we will keep the NUOPC cap for CICE5 in the ESCOMP repository of CESM-CICE5. Dave |
|
I'll suggest we add a directory at same level as cicecore called something like nuopc_caps and use that analogously to how, say, the cicecore/drivers has multiple descendants for specializations. NUOPC caps seem more dependent on the systems they're coupled to than ideal, so we are likely to need noaa_nws, noaa_oar, nrl, lanl, cesm, ... variants. |
|
DMI need to develop one as well. It will most likely be close to the NRL version or maybe the same as we couple to the same ocean model. |
|
We are working with NOAA and NRL to develop a common NUOPC cap for CICE5 in CESM. They are trying to do this for MOM6. |
|
I'm not sure what's in a NUOPC cap. Is it a set of scripts? Fortran code? Is it basically just a coupling interface? If so, would it eventually replace the cesm driver that we have now? If that's the case, then it could make sense to put them in the drivers directory. We have been moving away from modeling-center-specific support... To the extent possible, I'd prefer the the Consortium support the common parts and let the centers support the codes specific to them, since we can't test all of that. Someone who understands the different flavors of NUOPC caps across centers, please create a design document for discussion, with requirements and potential solutions. Volunteers? |
|
This is a timely discussion. I am currently working on bringing in CICE6 to CESM2. I have started with the MCT cap that @apcraig has already created for RASM. So, my thought was to rename drivers/cesm to drivers/mct and then have a drivers/nuopc area. These will contain only the CICE specific driver code needed to couple CICE into a model, sometimes referred to as a cap. The overall scripts to build and run CICE within a model will be a level above. I have created a CESM_CICE wrapper area that includes the CESM specific information. A subdirectory of this will be src where the code from the ESCOMP fork of CICE will sit. We will use a package called manage_externals that will know how to do the clone of the ESCOMP/CICE fork. Again, this is CESM specific and will not change anything in the CICE Consortium area. If I do have changes to CICE/Icepack I will issue pull requests from the ESCOMP forks of these. |
|
I agree that we might want to rethink the names of the various drivers. And I think it's good to encourage various coupled model to keep a copy of the coupling interface in the consortium repo. They often serve as a good resource for other modeling groups and sometimes can be used directly. At this point, I am aware of at least the following driver/coupling interfaces. I don't know that all are unique, but we want to make sure if they are, there is a place for them rasm/mct (based on cesm1.2) While it would be great if we could have a single mct and a single nuopc interface, I'm not sure that will work. This is what I'd propose at this point. The drivers/cesm is working for rasm with mct. If Dave can use that in cesm2/mct with changes that don't break rasm, then lets just leave it called drivers/cesm. If Dave needs a new directory, lets call it drivers/cesm2. We need to figure out where the NUOPC caps are. I am pretty sure cesm2 and NEMS are NOT using the caps and have different strategies for handling the cap. There is a plan to merge the caps and for NEMS to even use the CESM coupler, but we're not there yet. I don't know whether we should check in the cice5/cesm/nuopc cap and the cice5/nems/nuopc cap as well in some driver directory as place holders. They probably won't work with cice6 directly but are a starting point. Do we wait until they merge their nuopc caps and have cice6 working? How do we provide some flexible driver naming conventions to support whatever may happen in the future. We really don't know that there will be a single mct and a single nuopc cap. Even if there is some unification among some groups, it's still possible someone will want to have their own nuopc cap with a slightly different implementation. I think one thing we can do is try to unify the init/run/finalize code. I did that for the cice and cesm drivers. If you diff those codes, you should see minimal differences (I hope). I guess the question is whether we can further separate that code from the drivers and provide a unified init/run/finalize type interface that could be used by all driver implementation. It's always hard to know where to draw the line between common model code and distinct coupling interface code. At any rate, I think we should have some thoughtful discussions about what we need/want here. My hope is that what we decide can support the community nicely for a while. |
|
We discussed the NUOPC cap situation on the Consortium monthly meeting today. The summary is that NOAA and NCAR are working to build a unified CICE5 NUOPC cap. At the same time, @dabail10 is working on coupling CICE6 into CESM with the mct cap. Once CICE6 is running in CESM and the CICE5 NUOPC cap is relatively mature (we should be close for both), we can start to test CICE6 with the CICE5-ish NUOPC cap in CESM, at least on a technical level. I think there are some proposals for where the cap should go. I would argue everything should go under cicecore/drivers and that nothing that exists there should be removed or renamed. Right now, we have
My feeling is that we should keep all the current and future caps next to each other, and we should NOT break backwards compatibility for what's there now (as that places unnecessary risk/burden on the current coupled models build/scripts). We can easily continue to add caps/drivers under the cicecore/drivers directory. We can name those directories in any way we choose. Once something exists in the drivers directory, we should not get rid of it until it's clear it's completely obsolete and that nobody is using it. The CICE consortium will not be responsible for maintaining and testing these caps in general because it cannot. In some ways, this is location where different coupled system can place their coupling interfaces. On the separate issue, I think there are still benefits to reviewing the code reuse of the init/run/final code that exists in the drivers and NOW would be a good time to consider refactoring that, before we add new caps/drivers. If we can move some of the init/run/final code out of the drivers directory and elsewhere for improved reuse, that might be nice. That would reduce the maintenance burden when those parts of the model are updated. On the other hand, we don't want to move too much code into the reuse category that is limits what different groups can do. |
We want to add a NUOPC cap to CICE to support coupling within NUOPC coupled frameworks. This should probably come after validation with the mct cap in RASM.
The text was updated successfully, but these errors were encountered: