radheat Mesosphere /Lower Thermosphere shortwave heating missing cpair factor
Los mantenedores suelen responder en 3 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- fortran
Línea de trabajo
The issue points to radheat.F90 and identifies the qrs_mlt conversion before merge_qrx as the change. Read the radheat_tend implementation and check how composition-dependent cpairv is used; then run CAM with an MT model_top configuration and verify the shortwave heating has consistent J/kg/s units. The reporter says they plan to address it and need help, so coordinate with them before starting.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
What happened?
From @briandobbins
In radheat_tend, the idealized Mesosphere /Lower Thermosphere shortwave heating qrs_mlt is built from a K/day profile ÷ 86400 (so K/s), then merged via merge_qrx with the RRTMGP qrs (which is qrs_prime, in J/kg/s). The two have inconsistent units, so wherever the merge weight qrl_wt < 1 the M/LT SW heating is ~cpair (≈1004×) too small. The LW partner qrlfomichev is already in J/kg/s, so only the SW branch is affected. This only matters for MT (model_top="mt") configs, where the top ~6 levels (p ≲ 20 Pa) run cold — full Fomichev cooling with almost no SW heating. Low-top grids have qrl_wt = 1 everywhere and are unaffected.
Fix: convert qrs_mlt to J/kg/s with the composition-dependent cpairv before merging.
What are the steps to reproduce the bug?
Run CAM
What CAM tag were you using?
latest
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, but I will need some help
Extra info
One-line code fix:
/glade/u/home/pel/src/for-cecile-radheat/radheat.F90
- Lenguaje dominante
- Sin datos de lenguaje
- Estrellas
- 93
- Forks
- 186
- Merge medio
- 5 d 15 h
- PR fusionados (30 d)
- 19
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de ESCOMP/CAM
-
build-namelist hangs (infinite loop) on #-commented line in user_nl_camPosiblemente ocupada @jtruesdal la tomó hace 22 días. Abiertobug misc tag Must have CESM3
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
ESCOMP/CAM#1701 · 2 comentarios · 1 asignado ·
Los mantenedores suelen responder en 3 días
-
CoupledEval3 Must have CESM3
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
ESCOMP/CAM#1342 · 1 comentario ·
Los mantenedores suelen responder en 3 días
-
Remove for_testing_allow_non_annual_changes from user_nl_clmPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 25/100
Los mantenedores suelen responder en 3 días
-
after CESM3_0 enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
Los mantenedores suelen responder en 3 días
-
Bring in upcoming PUMAS bug fixes (ESCOMP/PUMAS#81); answer-changing for CAM7 defaultsPosiblemente ocupada @peverwhee la tomó hace 8 días. Abiertobug Must have CESM3
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
ESCOMP/CAM#1732 · 2 asignados ·
Los mantenedores suelen responder en 3 días