time_step.m / interpolations convert decimal days into nb of steps!

[Boxx-Obspm]

Maybe a bug: timeStep (1x3) is first computed in decimal days (good) then it converts the intervals wrt "ii" in integers (nb of steps before "ii").... then it produces dates of observation that fits exactly with the input datasets, which is not the aim (we have developed an interpolation method)

[Boxx-Obspm]

ici les timeStep étaient en nb de jours décimaux (ce qui est bien), je les renomme dt1, dt2, dt3

puis ils sont convertis en nb de "pas".... mais pourquoi???

donc timeStep(1) : nb de pas du fichier depuis ii et le plus proche après ii+dt1

(2) : nb de pas du fichier depuis (ii+timeStep(1)) et le plus proche après ii+timeStep(1)+dt2

(notons que timeStep(1) n'est plus dt1 en jours décimaux mais un pas de fichier)

(3) : nb de pas du fichier depuis (ii+timeStep(1)+timeStep(2)) et le plus proche après ii+timeStep(1)+timeStep(2)+dt3

pas trop grave mais tres fort risque de fournir 2 mesures identiques à l'algorithme

timeStep(1)=sum((TimeList1<=TimeList1(ii)+timeStep(1)))-ii;
timeStep(2)=sum((TimeList1<=TimeList1(ii+timeStep(1))+timeStep(2)))-ii-timeStep(1);
timeStep(3)=sum((TimeList1<=TimeList1(ii+timeStep(1)+timeStep(2))+timeStep(3)))-ii-timeStep(1)-timeStep(2);

[Boxx-Obspm]

Dans le choix des points de mesure, le problème n'est pas trop grave: 1- c'est un choix arbitraire de dates connues des fichiers T1, pour interpolation des fichiers T0 2- par contre ce sont des dates en avance de ii: ii+dt1, +(dt1+dt2), +(dt1+dt2+dt3) => ceci est-il compatible de la théorie? (qui prévoyait des dates *antérieures" à ii). 3- de plus, ce sont des dates qui coïncident exactement avec les dates de T0 donc en fait il n'y a pas d'interpolation stricte (à vérifier)

[Boxx-Obspm]

Fermé suite à release v1.3