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

[mathomp4]

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

[RobertPincus]

@mathomp4 In principle yes I'd be open to taking other cloud sampling. Note that the repos will be even more reorganized in future so it's not clear where such sampling would live.

[mathomp4]

@mathomp4 In principle yes I'd be open to taking other cloud sampling. Note that the repos will be even more reorganized in future so it's not clear where such sampling would live.

Maybe that's a good reason for us to get it to you quickly. Then when reorganized, it's taken care of! 😄

We already saw that things moved around, so we'll need to edit our CMakeLists.txt anyway when we integrate v1.7

... And now that I stare at that once @dr0cloud has gotten things running, I might explore:

# 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 a two-year old CMake bit. That is based on v1.5. New issue time!

[mathomp4]

Closing this as we have done this! See https://github.com/GEOS-ESM/rte-rrtmgp/releases/tag/geos%2Fv1.7%2B1.0.0