Are changes needed to support a Gregorian (leap year) calendar?
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- fortran
- Área
- hpc
Línea de trabajo
Comienza localizando el parámetro scyr codificado y otras suposiciones de 365 días en CISM. Experimenta con un calendario gregoriano en el contexto de CESM, comprobando el comportamiento del promediado y del paso de tiempo de la dinámica para detectar errores sistemáticos o fallos. Se considera terminado cuando los riesgos estén caracterizados y se hayan identificado los cambios necesarios.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
From @billsacks on April 8, 2016 1:25
For now this is more of a question than an issue... we can change it into an issue if it seems warranted:
Do people feel that any changes are needed for CISM to support a Gregorian (leap year) calendar? Typically CESM operates with a NOLEAP calendar, but some applications use it with a Gregorian calendar.
I'm pretty sure that CISM currently assumes a 365-day (no-leap) calendar (e.g., the scyr parameter is hard-coded to 365 days). I could imagine this possibly causing small errors both in terms of averaging quantities sent to / from the climate model, and also in terms of the number and size of the dynamics timesteps that fit within a year.
There are really two questions:
(1) Are people concerned about the small (but systematic) errors this will cause?
(2) Might the current assumptions cause any major problems, such as causing the run to crash?
This one will probably take some experimentation. I'm not sure how to test this, which is part of my motivation for filing this as an issue to come back to later.
Copied from original issue: E3SM-Project/cism-piscees#54
- Lenguaje dominante
- Fortran
- Estrellas
- 13
- Forks
- 17
- Merge medio
- 3 d 15 h
- PR fusionados (30 d)
- 1
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/CISM
-
Need to update cmake_minimum_requiredQuizá libre de nuevo @Katetc la tomó hace 77 días y no hay ningún pull request abierto. Abiertobug
-
Adding PFunit unit testing to CISMQuizá libre de nuevo @Katetc la tomó hace 243 días y no hay ningún pull request abierto. Abierto
-
Methods for initializing isotopes within the Ice SheetQuizá libre de nuevo @Katetc la tomó hace 257 días y no hay ningún pull request abierto. Abierto
-
Infrastructure to bring isotopes as tracers into CISMQuizá libre de nuevo @Katetc la tomó hace 257 días y no hay ningún pull request abierto. Abierto
-
smb_input confusing logicAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
Todos los issues de ESCOMP/CISM
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
ROCm/rocm-systems#14764 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
-
Dificultad 2/5 Menos de una hora Aptitud para principiantes 80/100
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
amr bug 🔥 diagnostics outputs
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
PHAREHUB/PHARE#1348 · 1 comentario ·
Los mantenedores suelen responder en 2 días