GithubHelp home page GithubHelp logo

geos-esm / rte-rrtmgp Goto Github PK

View Code? Open in Web Editor NEW

This project forked from earth-system-radiation/rte-rrtmgp

0.0 2.0 0.0 133.93 MB

RTE+RRTMGP is a set of codes for computing radiative fluxes in planetary atmospheres.

License: BSD 3-Clause "New" or "Revised" License

Makefile 0.68% Fortran 95.98% Shell 0.27% Python 0.85% C 2.23%

rte-rrtmgp's Introduction

Documentation

RTE+RRTMGP's GitHub Pages site contains a mix of automatically-generated documentation and hand-written descriptions. The documentation is incomplete and evolving. Thanks to the folks at Sourcery Institute for help in setting this up.

For the moment the Wiki may also be useful.

RTE+RRTMGP

This is the repository for RTE+RRTMGP, a set of codes for computing radiative fluxes in planetary atmospheres. RTE+RRTMGP is described in a paper in Journal of Advances in Modeling Earth Systems.

RRTMGP uses a k-distribution to provide an optical description (absorption and possibly Rayleigh optical depth) of the gaseous atmosphere, along with the relevant source functions, on a pre-determined spectral grid given temperatures, pressures, and gas concentration. The k-distribution currently distributed with this package is applicable to the Earth's atmosphere under present-day, pre-industrial, and 4xCO2 conditions.

RTE computes fluxes given spectrally-resolved optical descriptions and source functions. The fluxes are normally summarized or reduced via a user extensible class.

Building the libraries, examples, and unit-testing codes.

A description of building RTE+RRTMGP with an ad hoc homemade system is described in the documentation.

See also the autoconf branch for a Gnu autotools build system.

Examples

Two examples are provided in examples/, one for clear skies and one including clouds. Directory tests/ contains regression testing (e.g. to ensure that answers are independent of orientation) and unit testing (to be sure all the code paths are tested). See the README file and codes in each directory for further information.

Citing the code

Code releases are archived at Zenodo. All releases are available at DOI. The current release is available at: DOI

Please cite the code using these DOIs and the information in the CITATION.cff file in addition to the reference paper

Acknowledgements

The development of RTE+RRTMGP has been funded in the US by the Office of Naval Research, NASA, NOAA, and the Department of Energy. We are grateful for contributions from a range of collaborators at institutions including the Swiss Supercomputing Center, the German Climate Computing Center, and Nvidia.

rte-rrtmgp's People

Contributors

robertpincus avatar brhillman avatar skosukhin avatar mrnorman avatar mathomp4 avatar fomics avatar alexeedm avatar dependabot[bot] avatar mhbalsmeier avatar chiil avatar inpolonsky avatar dr0cloud avatar pernak18 avatar naromero77 avatar jussienko avatar gfacco avatar everythingfunctional avatar brian-eaton avatar climbfuji avatar m214089 avatar peterukk avatar rscohn2 avatar clementval avatar vectorflux avatar dustinswales avatar jdelamere avatar

Watchers

James Cloos avatar  avatar

rte-rrtmgp's Issues

Test using vectorized flags in RRTMGP

In #5 it was noted by me that in our CMakeLists.txt for RRTMGP we have:

# Use of the GEOS Vectorized flags in RRTMGP caused a segfault leading to
# line 726 of mo_gas_optics_kernels.F90. Moving to the "old" no-vect flags
# allows RRTMGP to run again.
if (CMAKE_Fortran_COMPILER_ID MATCHES Intel AND CMAKE_BUILD_TYPE MATCHES Release)
  set (CMAKE_Fortran_FLAGS_RELEASE "${GEOS_Fortran_FLAGS_NOVECT}")
endif ()

That is 2 years old so v1.5 time. We've long since moved to v1.6 and our vect flags have changed as well. So maybe this not needed anymore!

Let's do some tests:

  • v1.6 โ†’ Nope! Slower with Vect Flags (see below)
  • v1.7

Update to latest rte-rrtmgp (v1.7, main, develop)

We need to update this fork of rte-rrtmgp to be in line with the upstream repo, https://github.com/earth-system-radiation/rte-rrtmgp. This needs to be done carefully such that when we make a v1.7 tag here, it is equivalent to v1.7 plus the local changes from @dr0cloud.

Note: When this is done, we should make a PR to the mothership repo and get the one difference into it if @RobertPincus et al are amenable to taking sampled_urand_gen_max_ran. Then we'd pretty much be back to simply tracking the upstream.


Steps used to update repo

This document describes the process for updating the GEOS-ESM fork of rte-rrtmgp. The process is similar to the process for updating the GEOS-5 fork of rte-rrtmgp, but there are some differences.

The main issue is that the GEOS-ESM fork as an "additional" branch path to echo the official one that contains our edits.

Description of the problem

For example, assume origin is that of GEOS-ESM/rte-rrtmgp and upstream is that of the official rte-rrtmgp,
earth-system-radiation/rte-rrtmgp.

The upstream repo has two branches we care about:

  • main
  • develop

and two tags we are involved with:

  • v1.6
  • v1.7

Now in our origin repo, we have these branches:

  • main
  • develop
  • geos/main
  • geos/develop

where geos/main and geos/develop are the branches that contain our edits. We want to keep them in line with the official branches, just with our edit.

We also have some extra tags:

  • geos/v1.6+1.0.0
  • geos/v1.6+1.1.0

The geos/v1.6+1.0.0 tag is the same as the v1.6 tag in the upstream, with no changes. The geos/v1.6+1.1.0 tag is the same as the v1.6 tag in the upstream, with our changes.

What we need in the end is a geos/v1.7+1.0.0 tag that is identical to the v1.7 tag in the upstream with our edits. Eventually we then need to pass this change back to the upstream.

Updating the fork

We can't use the "Sync branch" button on GitHub because of this complexity. Instead, we have to do it manually.

Clone the fork

Using gh clone, clone the fork to your local machine.

$ gh repo clone GEOS-ESM/rte-rrtmgp
Cloning into 'rte-rrtmgp'...
remote: Enumerating objects: 4179, done.
remote: Counting objects: 100% (154/154), done.
remote: Compressing objects: 100% (113/113), done.
remote: Total 4179 (delta 113), reused 54 (delta 41), pack-reused 4025
Receiving objects: 100% (4179/4179), 133.83 MiB | 73.88 MiB/s, done.
Resolving deltas: 100% (2709/2709), done.
remote: Enumerating objects: 392, done.
remote: Counting objects: 100% (384/384), done.
remote: Compressing objects: 100% (201/201), done.
remote: Total 392 (delta 210), reused 305 (delta 179), pack-reused 8
Receiving objects: 100% (392/392), 331.50 KiB | 14.41 MiB/s, done.
Resolving deltas: 100% (210/210), completed with 17 local objects.
From github.com:earth-system-radiation/rte-rrtmgp
 * [new branch]      main       -> upstream/main
 * [new tag]         v1.6       -> v1.6
 * [new tag]         v1.7       -> v1.7
! Repository earth-system-radiation/rte-rrtmgp set as the default repository. To learn more about the default repository, run: gh repo set-default --help

doing this gets both the origin and the upstream remotes.

Now make sure we have the latest from the upstream:

$ cd rte-rrtmgp
$ git remote update --prune
Fetching origin
Fetching upstream
remote: Enumerating objects: 3325, done.
remote: Counting objects: 100% (2374/2374), done.
remote: Compressing objects: 100% (684/684), done.
remote: Total 3325 (delta 1722), reused 2237 (delta 1627), pack-reused 951
Receiving objects: 100% (3325/3325), 3.33 MiB | 22.72 MiB/s, done.
Resolving deltas: 100% (2385/2385), completed with 151 local objects.
From github.com:earth-system-radiation/rte-rrtmgp
 * [new branch]      autoconf                   -> upstream/autoconf
 * [new branch]      autoconf-develop           -> upstream/autoconf-develop
 * [new branch]      develop                    -> upstream/develop
 * [new branch]      documentation              -> upstream/documentation
 * [new branch]      feature-code-cov           -> upstream/feature-code-cov
 * [new branch]      feature-cuda-compatability -> upstream/feature-cuda-compatability
 * [new branch]      feature-cuda-kernels       -> upstream/feature-cuda-kernels
 * [new branch]      feature-spectral-dim       -> upstream/feature-spectral-dim
 * [new branch]      feature-top-at-1           -> upstream/feature-top-at-1
 * [new branch]      gh-pages                   -> upstream/gh-pages

The trick now is that we want to update our geos/main and geos/develop branches with the latest from the upstream main and develop branches, respectively. But we need to make sure that as we do, we can make a geos/v1.7+1.0.0 tag that is identical to the v1.7 tag in the upstream, but with our changes. So we can't just do git merge upstream/main say as upstream/main is now ahead of v1.7 in the upstream. So we need to merge incrementally.

Update the geos/main branch

First, update the geos/main branch to match v1.7 in the upstream:

$ git checkout geos/main
Already on 'geos/main'
Your branch is up to date with 'origin/geos/main'.
$ git merge v1.7

This will merge the changes from v1.7 in the upstream into geos/main. Running git diff v1.7 should show that the only difference is the one we carry. Now let's tag this point as geos/v1.7+1.0.0:

$ git tag geos/v1.7+1.0.0 -m "Tag geos/v1.7+1.0.0 relative to v1.7 from upstream"

And we now push both the branch and the tag to the origin:

$ git push origin geos/main
$ git push origin geos/v1.7+1.0.0

Now we can move geos/main to the latest from the upstream:

$ git merge upstream/main

and push this to the origin:

$ git push origin geos/main

We also now have to get our geos/develop branch in line with the upstream develop branch.

$ git checkout geos/develop
$ git merge upstream/develop

and now we push this to the origin:

$ git push origin geos/develop

RRTMGP v1.6 released

As the subject says, RRTMGP v1.6 was recently released.

This is mainly a reminder post for @dr0cloud and myself of steps we'll want to take:

  • Sync this repo with upstream
  • Test v1.6 with GEOS to see if any interface changes are needed
  • Issue geos/v1.6+1.0.0 tag in this repo
  • Update GEOS repos for new tag

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.