Années bissextiles dans les pack

[acosce]

La procédure de pack ne gère pas les années bissextiles. Par exemple on aura un pack 19991001_20000929_restart.tar au lieu de 19991001_20000930_restart.tar.

[sdipsl]

Tester la proposition de Anne.

modifier la ligne suivante dans pack_output pour les années bissextiles.

date_end_pack=$( IGCM_date_AddDaysToGregorianDate ${date_begin_pack} $(( ${DaysTemp?} - 1 )) )

par

date_end_pack=$( IGCM_date_AddDaysToGregorianDate ${date_begin_pack} $(( ${DaysTemp?} )) )

[sdipsl]

Replying to sdipsl:

Tester la proposition de Anne.

modifier la ligne suivante dans pack_output pour les années bissextiles.

date_end_pack=$( IGCM_date_AddDaysToGregorianDate ${date_begin_pack} $(( ${DaysTemp?} - 1 )) )

par

date_end_pack=$( IGCM_date_AddDaysToGregorianDate ${date_begin_pack} $(( ${DaysTemp?} )) )

Dans ce cas de figure, on a une simulation qui démarre en novembre en utilisant un "vrai calendrier" et qui sera packé par année.
on génère 19991001_20000929_restart.tar au lieu de 19991001_20000930_restart.tar

On n'aurait pas le souci en démarrant en janvier ou février.

Le problème ne vient pas du calcul de date_end_pack mais du calcul de DaysTemp? par la fonction IGCM_date_DaysInCurrentPeriod

Cette fonction ajoute dans ce cas le nombre de jours de l'année de début de pack (365 dans cet exemple). Ce qui ne colle pas car le mois de février 2000 a 29 jours.

Il faudrait dans IGCM_date_DaysInCurrentPeriod ajouter le nombre de jour de l'année + 1 si le mois de démarrage est > 2

[sdipsl]

Done. see r722

It's very likely that time series and seasonal averages will also experience troubles in that case (not yet tested).
An overcome is to specify frequencies in month waiting for a fix.
This issue will be describe in another ticket.