Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

New CISM time management aborts for leap years

Abierto
  • ¿Algo no está bien?
#1 1 comentario 0 reacciones 0 asignados Ver en GitHub

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
Error
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
fortran
Área
backend

Línea de trabajo

Comienza en glad_main.F90, línea 650, y sigue la comprobación de gestión del tiempo de CISM que informa “Valid_inputs cannot be .false.” durante los años bisiestos del calendario gregoriano. Revisa los registros de FCSD de 2011–2016 y las alternativas enumeradas relacionadas con la gestión del tiempo de CISM, los calendarios gregorianos y CLM con glc_mec y SGLC; se considera terminado cuando se haya establecido un enfoque compatible que evite el aborto.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Bill Sacks < sacks > - 2017-09-05 12:41:58 -0600
Bugzilla Id: 2507
Bugzilla CC: fyke, lipscomb, mvertens,

A few months ago, Mariana and I put in new CISM time management, where the coupler averages to a year before sending values to CISM. We put in place the following error check to ensure that CISM gets inputs at the time it expects them - because if the coupler and CISM are out of sync, CISM may be running with very wrong forcing values (e.g., always running with 0 values):

else if (time - av_start_time + params%time_step == params%tstep_mbal) then  

   if  (.not. valid_inputs) then
      write(message,*) &
           'Valid_inputs cannot be .false. if trying to do a mass balance time step'
      call write_log(message,GM_FATAL,__FILE__,__LINE__)
   end if

However, Louisa Emmons ran into a problem trying to run with a Gregorian calendar:

I am trying to run compset FCSD from 2011-2016, and seem to have gotten stuck because 2012 is a leap year. I guess I could just switch to a 365-day calendar.

My case run directory is:
/glade/scratch/emmons/cesm2alph07_FCSD_09x1_TS1mamsoa/run
which used source code in:
/glade/p/work/fvitt/cesm/cesm2_0_alpha07c/

These are the log error messages:
glc.log:
WARNING: GLINT will not handle leap years correctly!!!
...

  • FATAL ERROR : (glad_main.F90:650) Valid_inputs cannot be .false. if trying
    to do a mass balance time step

cesm.log:
189: * FATAL ERROR : (glad_main.F90:650) Valid_inputs cannot be .false. if trying
189: to do a mass balance time step
189: Exiting with fatal error: this_rank = 189
0: PARALLEL STOP in glimmer_log.F90 at line 180

Indeed, I don't think we tested this with a Gregorian calendar. CISM has never run correctly with a Gregorian calendar, but we've tried to make sure that it doesn't abort.

We need to determine how to get back to a situation where at least it doesn't abort.

Solutions I can see are:

  • Fix the problem robustly to allow gregorian runs with cism, by changing cism's time management

This would likely be a lot of work, and isn't favored by CISM folks, because they have no need for it.

  • Bypass the above error checks if running with a Gregorian calendar

This might work, but I think we'll get more and more out of sync over time, which might cause some other problems.

  • Some kludgey change to CISM's time handling to sort of do the right thing when running with a Gregorian calendar

This would be non-trivial because of the complexity of CISM's time handling - though would likely be easier than a full, robust reimplementation of time management in CISM.

e.g., we could temporarily modify tstep_mbal and related variables in leap years. It may not do exactly the right thing, but we could probably get it to do approximately the right thing - e.g., still running the CISM dynamics at the end of each year, whether or not it's a leap year.

  • Get CLM working with glc_mec with SGLC. Then don't allow CISM with a Gregorian calendar, but provide this alternative so you can run a reasonable glc_mec configuration with a Gregorian calendar.

This is probably my preference (because we want this SGLC support for other reasons, too), as long as there aren't too many people who want to be able to run with a Gregorian calendar.

Lenguaje dominante
Fortran
Estrellas
4
Forks
18
Merge medio
1 d 20 h
PR fusionados (30 d)
2

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

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ESCOMP/CISM-wrapper

Todos los issues de ESCOMP/CISM-wrapper

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.