Code Monkey home page Code Monkey logo

cam's Introduction

CAM: The Community Atmosphere Model

CAM code is stored in this repository on branches other than main. The details are explained below.

Please see the wiki for complete documentation on CAM, getting started with git and how to contribute to CAM's development.

This repository has four officially-supported branches:

  • main - contains this readme and the Code of Conduct information
  • cam_cesm2_2_rel - contains the current CESM2.2 CAM code
  • cam_cesm2_1_rel - contains the current CESM2.1 CAM code
  • cam_development - contains the current CAM development code (see the important note below before using this branch)

There are other branches in this repo that have a zz_ prefix which are used for special projects. Please note that use of these branches is not-supported and may very likely produce un-scientific results in certain configurations.

How to checkout and use CAM:

The instructions below assume you have cloned this repository and are in the repository directory. For example:

git clone https://github.com/ESCOMP/CAM
cd CAM

To run CAM compatible with the CESM2.2 release:

git checkout cam_cesm2_2_rel_02
./manage_externals/checkout_externals

To run CAM compatible with the CESM2.1 release:

git checkout cam_cesm2_1_rel_41
./manage_externals/checkout_externals

To view the release branches in Github, go to the "Branch:main" pulldown menu and select the appropriate branch.

To use unsupported CAM development code:

NOTE: This is unsupported development code and is subject to the CESM developer's agreement.

git checkout cam6_3_162
./bin/git-fleximod update

cam's People

Contributors

cacraigucar avatar gold2718 avatar nusbaume avatar peverwhee avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cam's Issues

Two new proposed labels

As Francis and I were talking about his pull requests this morning, and I went to review what was pending, I realized that it makes sense (at least to me) for us to have two labels (cam_release and cam_development) which could be applied to each issue/pull request that pertains to one or both CAM branches.  We can visually open each pull request and see which branch it is addressing, but it might be nice to be able to sort on the label.  As for issues, we don't see if it applies to a single or both branches (unless someone puts it in their text).

I propose two labels:
cam_release
cam_development

When a user opens an issue/pull request they will select one or both if they are appropriate.

Thoughts?
@fvitt @fischer-ncar @brian-eaton @gold2718 @nusbaume

Bugzilla 2263 - Incorrect local time processing for fields output on V-stagger grid

Opened: Steve Goldhaber 2015-12-30 15:05:29 MST
Local-time processing (the 'L' flag in addfld, add_default, avgflag_pertape or a fincl entry) uses the local time at each column to decide whether or not to process an outfld call for that column. To do this, it uses the longitude for the column to determine local time. However, for the FV dycore, these longitudes are hard-coded to the cell-centered values. If calling outfld with a variable defined on the V-stagger grid, the longitude values used for the time calculation are incorrect.

Comment 1: Steve Goldhaber 2015-12-30 15:07:42 MST
This could be fixed either by passing the grid index (the 'decomp') to the longitude-retrieval function (dyn_grid_get_elem_coords) or by using longitude values from the grid object associated with the field.

Frierson gray radiation

Patrick Callaghan is working on incorporating the gray radiation simple model into CAM. Once his work has been completed, Cheryl Craig needs to work on bringing it onto a branch destined for the CAM trunk and doing any necessary cleanup.

WACCMX ionosphere to CAM physics coupling

Refactor how WACCMX ionosphere couples to CAM physics to be independent of dynamical core. The existing code is dependent on the FV dycore. To be independent of choice of dycore, ESMF regridding methods will be used to regrid state variables between CAM physics state, a magnetic grid used in electrodynamo module, and a regular latitude longitude grid used in ion transport.

Bugzilla 2044 - Add (optional) state input to subcol_x_avg

Opened: Steve Goldhaber 2014-09-12 15:30:41 MDT
In order to average fields or tendencies in a way which avoids conservation issues, some state fields may be required by some subcolumn schemes (e.g., SILHS). Subcolumn schemes which do not need this information can ignore the input. While making this an optional input will lessen the workload of implementing it, there is no other reason not to require it.

Comment 1: Cheryl Craig 2016-05-04 13:45:05 MDT
This requires a use case before it can be implemented

Improvements to aerosol wet removal scheme

The Wang code is trying to do convective transport and wet removal of aerosols at the same time, so that the wet removal can happen on the aerosols activated by convection. The changes by Yunpeng are mostly to change the way aerosols are released when rain evaporates. In Wang a fraction of aerosol is released each time some of the rain evaporates and it is released into the same mode it came from. In Yunpeng’s changes, the aerosols are not released until all the rain has evaporated and it is released into the largest size mode.

Need github action to automatically close issues

The current repository configuration for CAM means that most pull requests (PRs) will not automatically close issues via keywords, which is usually a standard github feature, because most pull requests are to the non-default branch.

To alleviate this problem, and thus make the CAM repository easier to manage, a github action should be created which, using the github API, automatically closes issues and PRs when referenced via keywords in pull requests that are merged to a non-default branch.

Lunar tidal forcings

Add lunar tide forcing for the M2 gravitational lunar tide based on the empirical formula of Champman and Lindzen (1970) and as implemented in Pedatella, Liu, and Richmond (2012, JGR)

Update CLUBB library

Details from Brian Griffin at UWM in email to Cheryl Craig:

Hi Cheryl,

I have updated CLUBB and CAM so that there will be no need to "revert to NCAR settings" in CLUBB.  This was accomplished by adding a few variables to the CAM namelist.

With that said, we have a new tagged version of CLUBB/SILHS for you.  I tagged version b76a124 (dated 2/20/2020) of the clubb_release repository (master branch).  The tag is named "clubb_release_b76a124_20200220".  You can obtain the code by checking out the clubb_release repository on GitHub:

git clone https://github.com/larson-group/clubb_release.git
git checkout clubb_release_b76a124_20200220 (alternatively, git checkout b76a124 does the same thing).

The files found in the src/CLUBB_core folder are meant for the https://github.com/ESCOMP/CLUBB_CESM repository, while the files in the src/SILHS folder are ticketed for the https://github.com/ESCOMP/SILHS_CESM repository.

Making these changes to CLUBB/SILHS meant that we needed to change 5 files on the CAM side of things.  They are listed as follows:
  1. bld/build-namelist

  2. bld/namelist_files/namelist_defaults_cam.xml

  3. bld/namelist_files/namelist_definition.xml

  4. src/physics/cam/clubb_intr.F90

  5. src/physics/cam/subcol_SILHS.F90

    Our CAM code is found on GitHub in the https://github.com/larson-group/cam.git repository. Our code is found in the clubb_silhs_devel branch (which should be checked out by default when your download the repository). The version of this code as of the time I write this (which works with the CLUBB/SILHS tag I gave you) is 0fb1439, so this version can simply be obtained by:

git clone https://github.com/larson-group/cam.git
git checkout 0fb1439

 Yesterday, I merged the clubb_silhs_devel branch up to the head of the cam_development branch (version aee778a; dated 2/19/2020).  Please let me know if there's anything else you need.

Have a good weekend,

Brian Griffin

Updates to CLUBB/SILHS

. Modify SILHS to address conservation issues.
. Move CLUBB PDF parameters out of physics buffer to address a performance
problem identified by John Dennis.
. Answers change for SILHS configurations only.

Bugzilla 2234 - pbuf_global_allocate=.false. option broken

Opened: Brian Eaton 2015-10-23 08:53:48 MDT
The namelist variable pbuf_global_allocate was not being read, so our regression tests were not actually testing this option. I have left the fix for the namelist read commented out for the moment until we can get the option working again.

Comment 1: Cheryl Craig 2016-05-04 13:26:33 MDT
Brian commented out code in runtime_opts until this is fixed. At that time, this code needs to be uncommented.

Microphysics Cleanup

Greetings,

I've found two mistakes in the mg3 microphysics: neither answer changing, but they should be fixed.

  1. micro_mg_utils.F90: There are two comments on the size distribution calculation for liquid that are incorrect, because the formula was updated for CAM6 but the comment was not: The comment on eta calculation is changed to refer to Liu and Rostayn, 2003 NOT martin.

  2. micro_mg3_0.F90: mg3 actually will work with do_hail and do_graupel both true. However, there was a mix of which was the LAST one called. I switched size distribution calls to be graupel last so if both do_graupel and do hail are set, answers will be identical to do_graupel.

Neither changes answers. I have fixed these on a fork in the repository. Let's see if I have done it right.

Cheyenne jobs randomly failing with deallocation

In some instances cheyenne jobs just fail with an unhelpful message that a deallocation is invalid as the pointer has not been allocated. In some instances the job can fail on the first timestep and other times it can be later. This different behavior can all happen with the exact same code base.

The jobs which fail with a traceback indicate that the deallocate at line 267 in rrtmg_state.F90 is failing. While this appears to be valid code, there is something which is causing cheyenne to have random issues.

A couple of suggestions that could solve the random issue:

  • Remove the pointer attribute for the rstate variable
  • Introduce an "if allocated(rstate)" prior to the deallocate.

Dynamic generation of met_data_file names prevents check_input_data from downloading needed data

This issue started in the forums:

https://xenforo.cgd.ucar.edu/cesm/threads/issue-downloading-merra-files-during-testing.4952/

The problem seems to be that CAM's namelist lists a single met_data_file, e.g.

met_data_file		= '2000/MERRA2_1.9x2.5_20000101.nc'

and then other file names (with other dates) are generated dynamically at run time.

However, this means that check_input_data does not know about these other files, so they are not automatically downloaded (even though they do exist in the input data repository).

This should be changed in some way to allow check_input_data to work properly, downloading all needed files for a case. Two options that come to mind are:

(1) All file names can be generated and listed at build-namelist time

(2) check_input_data can be enhanced to understand that, in some cases (like this one) it needs to get all files from a given directory, rather than just the specific listed file.

I have reproduced this error both in CESM2.0.1 (where the user reported the issue) and in a recent version of the cesm2.1 alphabranch. I reproduced it by running

./create_test --no-build SMS_Ld1.f19_f19_mg16.FXSD.bishorn_gnu.cam-outfrq1d (where bishorn is my local machine), then running ./preview_namelists followed by ./check_input_data, and noting that only one of the MERRA files is considered by check_input_data.

filepaths not updated to build new usr_mech file

ChemPreprocess.pm has old hardcoded paths referencing $cam_root/components/cam.

fix is to replace cam_root with cam_dir cfg_ref variable that is set properly during cam configure.

++ my $cam_dir = $cfg_ref->get('cam_dir');

-- my $chem_preprocessor = "$cam_root/components/cam/chem_proc";
++ my $chem_preprocessor = "$cam_dir/chem_proc";

-- $usr_mech_infile = "$cam_root/components/cam/src/chemistry/pp_${chem_pkg}/chem_mech.in";
++ $usr_mech_infile = "$cam_dir/src/chemistry/pp_${chem_pkg}/chem_mech.in";

I've run a smoke test to make sure nothing is broken and also verified that the fix does enable cesm to correctly build the Buildconf/camconf/chem_proc/cam.subs.tar file which wasn't being created before. I will make a pull request.

jt

Bugzilla 1977 - Allow subcolumn history output with non-instantaneous processing

Opened: Steve Goldhaber 2014-05-15 14:29:52 MDT
If there is a history output field that is defined on subcolumns (a subcol field) and its processing type is not instantaneous (e.g., 'A' instead of 'I'), it ends up in the restart history file but restart crashes because the 'psubcols' history coordinate is not yet defined during a restart run.

Proposed action is to allow all history processing functions for subcolumn fields by reimplementing the CAM restart process. In particular, major parts of phys_init need to be called before read_restart_physics.

Comment 1: Brian Eaton 2014-05-16 08:12:33 MDT
Sounds like there's info missing from the restart file. The history buffers are unpacked and so the only info needed for a subcol dimension is psubcols (not nsubcols). I'm not seeing what's special about subcols that would require a reordering of the restart process.

Comment 2: Cheryl Craig 2016-05-04 14:00:52 MDT
This will be fixed as part of the CAM initialization refactor.

Comment 3: Cheryl Craig 2016-05-04 14:04:15 MDT
Bug 1976 has been marked as a duplicate of this bug.

Replace AQP11 with AQPCONST

Putting in this issue again to test projects automation

Discussions among scientists implementing the RCE code has led to the decision to change AQP11 to AQPCONST .

Use Heelis E-Potential model in WACCM

Use Heelis high-latitude electric potential model in WACCM rather than Weimer96 which is used for joule heating and ion drag. This will make the WACCM electric potential more consistent with WACCMX which uses Heelis as the default and has the option to use Weimer05. WACCMX does not use Weimer96.

Bugzilla 2547 - A test sets "queue" in the testlist, but cime can't handle changing the queue

Opened: Erik Kluzek 2018-06-02 17:54:15 MDT
As a result of working on a cime issue I found that CAM has an <option name="queue" setting in it's test list for one test. The problem with this is that cime can't actually do that change, so it doesn't actually do anything. So it either should be removed, or cime changed so that it can handle a queue change. From looking into cime, changing the queue would be a more difficult change than some of the other things that are set.

Comment 1: Brian Eaton 2019-08-21 11:00:25 MDT
I assume that option can be removed. Reassigning to Steve since I believe FHIST_DARTC6 is something he created.

WACCM physics efield module compiled with intel/19.0.2

WACCM physics efield module produces NaNs in the electric field components over the poles in some configurations compiled with intel/19.0.2 at O2 optimization level on cheyenne. Example configuartions: FW2000climo compset on grids ne30_ne30_mg17 and ne30pg3_ne30pg3_mg17.

Add Pull Request template?

Should we add a pull request (PR) template to this repo, or at least the cam_development branch? We could have the PR template just be the ChangeLog template, which would not only make contributors fill out a ChangeLog, but would also add the ChangLog entry directly to the git log itself anytime a PR was merged.

Thoughts or opinions? I can implement this if we decide to do so.

SE updates; new analytic IC functionality.

. SE updates for stability of WACCM and CONUS runs.

. Implement a new analytic_ic_type which sets u=v=0, a vertical
temperature profile based on the US Standard Atmosphere, and PS in
hydrostatic equilibrium with topography. PHIS is an input argument in
this case. It is expected that this IC will be most useful for starting
up full physics runs when a spunup initial file is not available.

. Modify interfaces of the analytic_ic code to allow for PHIS to be
either an intent(in) or an intent(out) argument. Current code assumes
PHIS is always an output and will overwrite the PHIS read from a topo
file if used in conjunction with analytic ICs.

. Allow use of analytic ICs together with reading constituents from the
initial file. Current code logic only allows using the default
constituent ICs when using the analytic_ic option.

Bug in Meta Data for MG microphysics

This is an error in the metadata for micro_mg_cam.F90

It currently says:
   call addfld ('ADRAIN',      (/ 'lev' /),  'A', 'Micron',   'Average rain effective Diameter'                                   )
   call addfld ('ADSNOW',      (/ 'lev' /),  'A', 'Micron',   'Average snow effective Diameter'                              )

And it should be 
   call addfld ('ADRAIN',      (/ 'lev' /),  'A', 'm',   'Average rain Diameter'                                   )
   call addfld ('ADSNOW',      (/ 'lev' /),  'A', 'm',   'Average snow Diameter'                              )

To reflect what is currently in the MG3 code (bug affects MG2 and release code).

Found By Rachel Atlas, UW

MG3 edge cases need to be addressed

Currently, the MG3 code on the CAM trunk only runs with graupel on (micro_mg_do_hail = true or micro_mg_do_graupel = true). This is enforced by build-namelist. However, there is the possibility that users (or future developers) might want to run MG3 without hail or graupel (to ensure that it produces the same answers as an MG2 run). And MG4 should support the ability to run without hail and graupel. Thus, there are a few "if" statements in the current trunk code that are not quite restrictive enough. There are a handful that are only "if (mg_version > 2)" and they should be "if (mg_version > 2 .and. (do_hail .or. do_graupel))".

This should be an easy patch to apply to the trunk, but I'm not sure how to go forward with the new Github infrastructure. Please advise. This fix could also be combined with issue #10 , as I would be happy to make that fix too.

part of cam6_2_014: Remove unused "use" statement

After testing of cam_snapshot was completed, an unused use statement was discovered and it should be removed.

src/physics/cam/physics_types.F90: "use cam_history, only: outfld' is not used and should be removed.

Update setting SE grid parameters

. This change is to allow adding new SE grids to the CESM system without
needing to update CAM's horiz_grid.xml file. It is the only CAM specific
item that's been identified to make it easier to use variable resolution
grids in the CESM.

QPRCEMIP no longer sets seq_flux namelists properly

On both the development branch and the release branch, when QPRCEMIP is used, the following namelists should be set:

seq_flux_atmonc_minwind=1.0
seq_flux_mct_albdif = 0.7

Currently they are being set to 0.5 and 0.6 respectively.

Bug fix for Q925 in cam_diagnostics.

Bug was reported on bulletin board. The fix is in cam_diagnostics.F90 at line 1413.

if (hist_fld_active('THE9251000')) then

should be

if (hist_fld_active('THE9251000') .or. &
    hist_fld_active('Q925')) then

SE grid updates and sponge-layer bug fix

This issue is to be associated with a PR for grid updates in CAM-SE from my vr-arctic branch off of tag cam6_2_010 (cc @brian-eaton). Two additional grids w/ refinement over the arctic have been implemented. The arctic grids (pdf's of grids attached) are eventually to become part of a cesm2 release of CAM-SE, along with CONUS, and are also a part of the planned SIMAv0 Polar release. The arctic grids were developed for the CESM community (cross-WG) project "Development of a CESM Arctic Prediction System (CAPS)." These new grids will require a CIME PR, which @fischer-ncar is in the process of doing.

  1. Added two new variable resolution grids w/ refinement in the ARCTIC.
  • Only needed to modify bld/namelist_files/namelist_defaults.xml
  • bld/config_files/horiz_grids.xml did not have to be modified since I branch off the latest tag( cam6_2_010 tag).
  1. Updated bnd_topo, ncdata files and dycore time stepping for the CONUS grid.
  • new topo file using vr topo software recently updated by @PeterHjortLauritzen and I.
  • set dycore time-stepping to be consistent with the corresponding CIME PR, in which the physics time-step is reduced to 225 s (i.e., ATM_NCPL=384), after consulting w/ @PeterHjortLauritzen.
  1. Added missing drydep_srf_files for ne30pg2 and ne120pg2 grids.
  • These files were created to parallel the CIME PR, which is not only to implement the arctic grids, but also to allow for ne30pg2 and ne120pg2 to be ran in an F compset. These grids are being considered as part of AMPs dycore intercomparison to determine the next default dycore in CAM.
  1. Fixed bug in time-stepping for sponge-layer hyperviscosity

All four of these changes have been tested in an F2000climo compset, described in the ChangeLog. This is my first PR, so please let me know if I am overlooking something here.

squadgen-lowerconn-arctic-2x-13043-grid.pdf
squadgen-lowerconn-arctic-3x-16931-grid.pdf

cam6_2_002: misc waccm(x) updates

  • issue #14 misc waccm(x) updates

  • adjust Nitric Oxide deactivation rate (in NO cooling)

  • zero the EPP forcings above the input data

  • 2-degree capability for FC6XSD compset

  • some support for half-degree WACCMX

  • bug fix in WACCMX ring filter for half-degree resolution

  • adjustments to FWmaSD 2-degree namelist settings

COSP2 updates

. Fix bug for reversed vertical order in several outputs with cosp_ht
vertical coordinate.
. Update to COSP v2.1.6.
. Add Cloudsat diagnostics

These changes need to go on both dev and release branches.

bugz 1997 -- OCS + OH

Michael Mills 2014-06-12 18:16:04 MDT
The waccm_mozart_sulfur chemistry mechanism includes the following reaction:

OCS + OH -> SO2 + C + H

Although this reaction appears to be balanced, the product C is not included in the mechanism. It should be replaced with CO, as follows:

OCS + OH -> SO2 + CO + H

The source modules in pp_waccm_mozart_sulfur should be replaced accordingly.

[reply] [−] Comment 1 Francis Vitt 2017-05-11 10:06:27 MDT
this was fixed in cam tag cam5_4_68

[reply] [−] Comment 2 Michael Mills 2017-05-11 10:26:03 MDT
That's good that it is fixed for CESM2. The bug is in the CESM1.2.2 release. If there is another release of CESM1.2, this should be fixed.

Bugzilla 1972: add_hist_coord - look into misleading overloading

Opened: Cheryl Craig 2014-05-08 14:12:48 MDT
add_hist_coord has 3 overloaded specific routines.

The actual minimal user interface is (name, value, label). If a user neglects to specify 3 values and only gives two (name, value), one of the overloaded routines (add_hist_coord_regonly) is called and value is overwritten with index.

This is misleading and should probably look at whether add_hist_coord_regonly should be part of the add_hist_coord overloading or not.

Reviewed: Cheryl Craig 2016-05-04 14:12:07 MDT
This might go away with the refactor.

Move microphysics to an external

Because of the on-going goal to use various forms of the MG microphysics (including the next generation PUMAS) in different models, we would like to move the microphysics code out of the src/physics/cam repo and into its own GitHub repository, to be accessed as a CAM external. The PUMAS Github repo has been started here:

https://github.com/ESCOMP/PUMAS

We will maintain a CAM release branch in this repository to be used as the CAM external. This branch has been created (https://github.com/ESCOMP/PUMAS/tree/release/cam) and contains the source from the most recent cam_development tags. I have a prototype of the changes needed on a branch of my CAM fork (https://github.com/Katetc/CAM/tree/cam_pumas_development). This is out of date and points to the PUMAS master and not the release branch. But, it does build and run with MG as an external.

So, the following work still needs to be done:

  1. Update my fork branch to the most recent cam_development, and point to proper release branch for testing and pull request.
  2. Add more MG tests to use for future updates. We have a good amount of optimizations and updates coming in, and we don't want these to break anything along the way. We could use more tests targeted to various MG options and configurations for these. They would not have to be included in CAM regression, alpha or beta tests.

So, timeframe on the PR to address this issue is still a couple of weeks out. Maybe early March. I wanted to post the issue to give everybody a heads-up for planning. Thanks!

Bugzilla 1974 - Cannot use flag_xyfill option with subcolumns

Opened : Steve Goldhaber 2014-05-15 14:19:33 MDT
If you call addfld with flag_xyfill = .true. for a field with subcolumns, calls to outfld will crash if any column has nsubcol < psubcols.
Proposed action is to call endrun at addfld time to avoid crashing later in the run.

Comment 1: Steve Goldhaber 2014-05-15 15:54:53 MDT
To fix this, we have to first move some code:

In addfld (cam_history), move this code:

!
! Whether to apply xy fillvalue: default is false
!
if (present(flag_xyfill)) then
listentry%field%flag_xyfill = flag_xyfill
else
listentry%field%flag_xyfill = .false.
end if

below the if block that begins with:
if(present(mdimnames)) then

Then add logic after the line:
listentry%field%flag_xyfill = flag_xyfill

to the tune of:
if (listentry%field%is_subcol .and. flag_xyfill) then
call endrun('addfld: flag_xyfill not supported for subcolumn fields')
end if

Comment 2: Brian Eaton 2014-05-16 07:58:53 MDT
It looks like subcol_unpack deals with adding a fillvalue to the subcols from nsubcol+1 to psubcols. What is the actual problem?

Comment 3: Cheryl Craig 2016-05-04 14:06:29 MDT
Bug 1975 has been marked as a duplicate of this bug.

Discussion on git commit requirements

From email by @gold2718

I still do not understand the logic of mashing together unrelated commits. The GitHub workflow is smoother and issues are easier to track (and debug) when made separately.
Using this issue and #20 as an example, say for the sake of argument that issue #20 introduced a change (AQP11 to AQPCONST) which is incompatible with my current work. Because there is no separate commit with issue #22 alone, I cannot easily use that while avoiding the #20 change as well.
Merging #20 as a separate PR with a couple of simple tests (already made by @nusbaume) would make no difference in the testing required to merge #20 and make a tag. On the other hand, it makes needed changes available more quickly.
If anyone still disagrees, please add some compelling arguments here.

AM conservation updates

Updates from NorESM (Toniazzo) should be applied to release code. These updates are for the angular momentum correction and fixer code which is implemented in the FV dycore. Answers are only affected when the AM conservation options are turned on. They are off by default.

These mods were applied to the development code at tag cam6_1_029.

Update manage_externals

Per Bill Sacks recommendations, we need to update manage_externals. Update to tag manic-v1.1.8.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.