Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

New CISM time management aborts for leap years

Aperta
  • Qualcosa non va?
#1 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
fortran
Ambito
backend

Direzione di ricerca

Inizia dalla riga 650 di glad_main.F90 e segui il controllo della gestione del tempo di CISM che segnala “Valid_inputs cannot be .false.” durante gli anni bisestili del calendario gregoriano. Esamina i log di FCSD del 2011–2016 e le alternative elencate relative alla gestione del tempo di CISM, ai calendari gregoriani e a CLM con glc_mec e SGLC; il lavoro è completato quando è stato stabilito un approccio supportato che evita l’interruzione forzata.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Fortran
Stelle
4
Fork
18
Merge medio
1g 20h
PR unite (30g)
2

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ESCOMP/CISM-wrapper

Tutte le issue di ESCOMP/CISM-wrapper

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.