Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Bring in upcoming PUMAS bug fixes (ESCOMP/PUMAS#81); answer-changing for CAM7 defaults

Open
  • Is something wrong?
#1,732 0 comments 0 reactions 2 assignees View on GitHub

Maintainers usually reply within 3 days

@peverwhee is already working on this.

Since Oct 20, 2026.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
fortran
Domain
backend

Research direction

Read the linked ESCOMP/PUMAS#81 report and inspect CAM → atmos_phys → schemes/pumas/pumas, currently atmos_phys0_31_000 / pumas_cam-release_v1.41; compare those files with the reported fixes. Before updating the submodule, check the F1850 TOA balance and consider whether the micro_mg_vtrmi_factor tuning needs review. Run CAM7 cases with the stated warm-rain and accretion settings, then review expected baseline changes in aux_cam.

Written by the indexing model from the issue text.

Description

bug Must have CESM3
What happened?

Heads-up: ESCOMP/PUMAS#81 reports three bugs in PUMAS that are active in the default CAM7 configuration. Once fixes are tagged in PUMAS, they should come into CAM via an atmos_phys update (CAM → atmos_phys → schemes/pumas/pumas; currently atmos_phys0_31_000 / pumas_cam-release_v1.41).

The three bugs:

  1. accre_sees_auto (on by default for cam7): the provisional droplet number passed to accretion is reduced by the rain-number source (nprc) instead of the droplet-number sink (nprc1).
  2. micro_mg_vtrmi_factor (1.39 for cam7): applied twice to part of the small/large-ice fall-speed blend, and never applied to the number-weighted ice fall speed.
  3. Ice slope lower bound: 1._r8/2._r8*dcs evaluates to dcs/2 instead of 1/(2*dcs), so the 900 µm ceiling on mean ice size never engages. This is a regression from 2022.

Things to plan for:

  • The fixes are answer-changing for cam7 compsets, so expect baseline changes in aux_cam.

  • Climate impact looks small in 6-month F2000dev (ne30pg3) ensembles:

    • IWP +2.7%, LWP +1.4%;
    • net TOA −0.16 ± 0.24 W m⁻², not significant.

    However, micro_mg_vtrmi_factor=1.39 was tuned with the buggy behaviour. A check of the F1850 TOA balance (and possibly the tuning) is worth doing before the fixes go into a production configuration.

  • CAM6 is not affected by bugs 1 and 3. src/physics/pumas-frozen (v1.17) has the correct ice bound and no accre_sees_auto. It does have the same vtrmi double-application, which may be acceptable to leave in the frozen code.

Details and patches: ESCOMP/PUMAS#81.

What are the steps to reproduce the bug?

Run any CAM7 configuration with micro_mg_warm_rain='kk2000' and micro_mg_accre_sees_auto=.true.

What CAM tag were you using?

cam6_4_212

What machine were you running CAM on?

CISL machine (e.g. derecho)

What compiler were you using?

Intel

Path to a case directory, if applicable

No response

Will you be addressing this bug yourself?

Yes

Extra info

No response

Dominant language
No language data
Stars
93
Forks
186
Avg merge
5d 15h
Merged PRs (30d)
19

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ESCOMP/CAM

All issues in ESCOMP/CAM

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.