Remove documentation on interpolated eddies

Inst_eddies/Documentation_texfol/documentation.tex

@@ -432,9 +432,8 @@ Format shapefile. Un type de géométrie par fichier donc il faut
 séparer les contours et les positions des extremums.
 \begin{itemize}
 \item \verb+extremum.shp+ : points
-\item \verb+extremum.dbf+
-  : valeur de SSH, indice de date, indice de tourbillon à cette date,
-  interpolé (logique), cyclone (logique), valid (logique), valeur
+\item \verb+extremum.dbf+ : valeur de SSH, indice de date, indice de
+  tourbillon à cette date, cyclone (logique), valid (logique), valeur
   de vitesse sur le contour de vitesse maximale
 \item \verb+outermost_contour.shp+ : polygones
 \item \verb+outermost_contour.dbf+ : aire, valeur de SSH, indice de
@@ -479,9 +478,8 @@ Pour un extremum donné, radius4 est le rayon, en pas de grille, de la
 plus petite croix autour de l'extremum qui déborde le contour
 extérieur. Si un contour extérieur valide n'a pas été trouvé alors
 radius4 est nul. Si un contour extérieur valide a été trouvé alors
-radius4 est $\ge 1$. Les champs interpolated et radius4 sont écrits à
-titre diagnostique et ne sont pas utilisés dans le programme de
-recouvrement.
+radius4 est $\ge 1$. Le champ radius4 est écrit à titre diagnostique
+et n'est pas utilisé dans le programme de recouvrement.
 
 J'avais d'abord mis la valeur de vitesse dans le fichier
 \verb+max_speed_contour_$m.dbf+ mais cette vitesse peut être associée

Overlap/Documentation_texfol/documentation.tex

@@ -81,9 +81,6 @@ Notons ici $k_b$, $k_e$, $\max \delta$ et $n_p$ les valeurs contenues
 dans les variables Fortran \verb+k_begin+, \verb+k_end+,
 \verb+max_delta+ et \verb+n_proc+ respectivement.
 
-On ne cherche des superpositions qu'entres tourbillons visibles, en
-excluant les tourbillons interpolés.
-
 Pour comparer les tourbillons à deux dates, il semble coûteux de
 n'utiliser que les listes de tourbillons aux deux dates. Cela implique
 une double boucle sur les listes de tourbillons, à l'intérieur d'une
@@ -142,16 +139,15 @@ commentaires sur overlap.
 Lorsqu'on compare des tourbillons à distance temporelle delta (entre 1
 et $\max \delta$), on veut tester s'ils n'ont pas de prédécesseur ou
 successeur visible à une date intermédiaire. Il faut donc, si on crée
-un arc entre deux dates successives, ou delta arcs à distance delta
-(par interpolation de tourbillons invisibles), enregistrer ce fait en
-prévision du passage au delta supérieur. Mais d'un autre côté, on ne
-veut pas que le fait de mettre des arcs à l'étape delta ait une
-importance pour la suite de l'étape delta. (Et accessoirement, on ne
-veut pas que l'ordre dans lequel on passe les tourbillons à l'étape
-delta ait une importance.)  On est donc obligé d'enregistrer, pour
-chaque tourbillon, non seulement s'il a des prédécesseurs visibles et
-s'il a des successeurs visibles, mais aussi à quelle distance
-temporelle.
+un arc entre deux dates successives, ou un arc à distance delta,
+enregistrer ce fait en prévision du passage au delta supérieur. Mais
+d'un autre côté, on ne veut pas que le fait de mettre des arcs à
+l'étape delta ait une importance pour la suite de l'étape delta. (Et
+accessoirement, on ne veut pas que l'ordre dans lequel on passe les
+tourbillons à l'étape delta ait une importance.)  On est donc obligé
+d'enregistrer, pour chaque tourbillon, non seulement s'il a des
+prédécesseurs visibles et s'il a des successeurs visibles, mais aussi
+à quelle distance temporelle.
 
 $m$ est le numéro du processus MPI, compris entre 0 et $n_p - 1$. On
 pourrait écrire l'algorithme principal en explicitant les
@@ -179,15 +175,7 @@ Dans le programme de recouvrement, idée d'admettre des tourbillons
 dont les numéros à une date donnée n'iraient pas forcément de 1 au
 nombre de tourbillons visibles. L'intérêt serait de pouvoir traiter
 des domaines extraits d'un snapshot global. il faudrait ajouter une
-composante identifiant au type eddy, remplacer la composante
-\verb+number_eddies+ du type snapshot par une composante
-\verb+number_interp_eddies+ et passer :
-\begin{verbatim}
-- flow(j - delta + 1:j - 1)%number_interp_eddies
-\end{verbatim}
-au lieu de \verb|flow(j - delta + 1:j - 1)%number_eddies| à
-\verb+write_overlap+ pour que les
-numéros de tourbillons interpolés soient négatifs.
+composante identifiant au type eddy.
 
 Optimisation. Les send doivent-ils être bloquants ? Les recv ? Ne pas
 utiliser bsend. L'algorithme ne permet pas isend ni irecv. Penser à
@@ -195,44 +183,6 @@ utiliser bsend. L'algorithme ne permet pas isend ni irecv. Penser à
 
 \section{Entrées et sorties}
 
-On pourrait créer un shapefile séparé pour les extremums interpolés
-(points), avec des méta-données supplémentaires sur les contours
-fictifs associés. En notant $m$ le numéro de processus MPI :
-\begin{itemize}
-\item \verb+extremum_interpolated_$m.shp+ : points
-\item \verb+extremum_interpolated_$m.dbf+ : valeur de SSH à l'extremum,
-  indice de date, indice de tourbillon à cette date, aire du contour
-  de SSH le plus éloigné, valeur de SSH sur le contour de SSH le plus
-  éloigné, aire du contour de vitesse maximale, valeur de vitesse sur
-  le contour de vitesse maximale
-\end{itemize}
-Mais il me semble plus simple et clair d'écrire les tourbillons
-interpolés avec les autres, en utilisant une forme NULL pour le
-polygone correspondant à un contour interpolé.
-
-On n'enregistre pas de contours pour les tourbillons interpolés. Les
-tourbillons interpolés sont écrits avec les autres, en utilisant une
-forme NULL pour le polygone correspondant à un contour interpolé. Un
-processus donné, dans plusieurs appels à overlap, peut interpoler des
-extremums à une même date. Donc, dans le shapefile \verb+extremum+
-écrit par un processus donné, les dates sont dans le désordre. En
-outre, deux processus peuvent interpoler des extremums à une même
-date. Il sera certainement utile de concaténer et trier les shapefiles
-en post-traitement. Pour trier, je ne suis pas obligé de charger en
-mémoire vive tous les shapefiles : je peux simplement faire la
-concaténation puis lire dans \verb+extremum.dbf+ par exemple deux suites
-d'entiers \verb+date_index+ et \verb+eddy_index+.
-
-Un processus donné alterne lecture de shapefiles (créés par
-extraction\_eddies) et écriture de shapefiles (contenant les
-tourbillons interpolés). Un processus donné doit donc manipuler deux
-jeux de pointeurs de shapefiles. On peut éventuellement supposer que
-les numéros de champs sont les mêmes pour les deux jeux de shapefiles.
-
-La méta-donnée logique \og interpolé \fg{} dans
-\verb+extremum_$m.dbf+ est nécessaire parce qu'il est possible de ne
-pas trouver de contour extérieur autour d'un extremum détecté.
-
 Une possibilité simple de stockage de graphe est la liste d'adjacences
 (en texte), c'est-à-dire, pour chaque sommet du graphe, une ligne :
 \begin{verbatim}
@@ -270,12 +220,10 @@ facilement trouvée. On ajoute par conséquent les fichiers de sortie
 suivants :
 \begin{description}
 \item[number\_eddies\_\$m.csv] Une colonne indice de date, une colonne
-  nombre de tourbillons visibles, une colonne nombre de tourbillons
-  interpolés.
-\item[isolated\_nodes\_\$m.txt] Sur chaque ligne : indice de date, indice
-  de tourbillon. Peut être lu comme une simple liste
-  d'adjacence. Remarque : par construction, les tourbillons interpolés
-  ne sont jamais isolés.
+  nombre de tourbillons visibles.
+\item[isolated\_nodes\_\$m.txt] Sur chaque ligne : indice de date,
+  indice de tourbillon. Peut être lu comme une simple liste
+  d'adjacence.
 \end{description}
 
 Les entrées-sorties sont dans : l'algorithme principal directement
@@ -329,11 +277,6 @@ par \verb+overlap+.
 \item[weight\_delta] Scalaire réel.
 \end{description}
 
-On doit stocker dans le champ number\_eddies le nombre de tourbillons
-parce qu'on peut refaire des interpolations à une même date dans
-différents appels à overlap avec delta $\ge 2$ : il faut que le numéro
-de tourbillon interpolé soit bien incrémenté.
-
 i désigne un indice de tourbillon, j un indice de position dans la
 fenêtre temporelle (entre 1 et $\max \delta$ + 1) et k un indice de
 date. Cf. figure (\ref{fig:window}) et algorithme
@@ -736,54 +679,6 @@ $(k, \delta_1, m_1)$ est terminé avant l'appel $(k, \delta_2,
 m_2)$. Les prédécesseurs d'une date donnée sont cherchés dans l'ordre
 croissant des $\delta$.
 
-\subsection{Numéros des tourbillons interpolés}
-
-L'attribution d'un numéro de tourbillon interpolé, et donc
-l'incrémentation du nombre de tourbillons interpolés, à chaque date,
-sont faits par la procédure overlap. Montrons que : deux processus ne
-peuvent pas attribuer le même numéro de tourbillon interpolé à une
-date donnée ; une incrémentation à une date donnée par un processus ne
-peut pas s'intercaler entre deux incrémentations à la même date par un
-autre processus.
-
-Considérons deux appels de overlap : $(m_1, k_1, \delta_1)$ et
-$(m_2, k_2, \delta_2)$, avec $m_1 \ne m_2$. Supposons qu'il existe un
-indice de date $k$ appartenant à
-$\{k_1 - \delta_1 + 1, \dots, k_1 - 1\} \cap \{k_2 - \delta_2 + 1,
-\dots, k_2 - 1\}$. Avec les équations (\ref{eq:pred_main_loop}) et
-(\ref{eq:predecessor}), $k$ est dans l'intersection des domaines de
-$m_1$ et $m_2$. Donc $|m_2 - m_1| = 1$ et on peut supposer sans perte
-de généralité que $m_1 = m_2 + 1$.
-
-\begin{multline*}
-  k_2 \ge k + 1 \ge k_1 - \delta_1 + 2 \ge k_b(m_1) + 2
-  = k_b(m_2 + 1) + 2 \\
-  = k_e(m_2) - \max \delta + 3 
-  = \mathtt{k\_end\_main\_loop}(m_2) + 2
-\end{multline*}
-Donc l'appel $(m_2, k_2, \delta_2)$ est dans l'épilogue.  L'overlap
-$(m_2, k_2, \delta_2)$ suit forcément un \verb+get_snapshot(k2)+. Le
-\verb+get_snapshot(k2)+ est une réception bloquante. Il suit forcément
-un send de $k_2$ du processus $m_1$. Dans un processus quelconque,
-après un \verb+dispatch_snapshot+ d'une date quelconque, plus aucun
-overlap ne recouvre cette date. Donc l'overlap$(m_1, k_1, \delta_1)$
-est forcément fini avant le début de l'overlap $(m_2, k_2,
-\delta_2)$. $\Box$
-
-Pour deux exécutions avec des entrées identiques mais des nombres de
-processus MPI différents, le numéro d'un tourbillon interpolé à une
-certaine date entre deux tourbillons visibles donnés peut varier. En
-effet, ce numéro est attribué par la procédure overlap et dépend donc
-de l'ordre dans lequel les procédures overlap interpolent à une date
-donnée. Par exemple, pour $\max \delta = 4$, n\_dates = 15, $n_p = 3$,
-$k_1 = 1$, l'overlap 5-9 s'exécute après l'overlap 7-10. Cf. figure
-\ref{fig:15_3}. Alors que l'overlap 5-9 s'exécute avant l'overlap 7-10
-pour $n_p = 1$ ou 2. Difficile de mettre en place une numérotation qui
-serait indépendante de l'ordre des overlap. Pour comparer facilement
-les résultats d'exécutions avec différents nombres de processus, il
-reste donc la possibilité de renuméroter après coup les tourbillons
-interpolés : script \verb+renumber_interp.py+.
-
 \section{Algorithme principal, parallèle}
 
 \begin{algorithmic}
@@ -894,14 +789,6 @@ croissantes. \verb+get_snapshot+ n'a donc besoin d'avoir à un instant donné
 qu'un seul triplet ouvert. Je fais le pari que plusieurs processus MPI
 pourront accéder en même temps en lecture à un même fichier.
 
-\subsection{init\_interpolated\_eddy}
-
-On peut mettre le champ valid à faux pour un tourbillon interpolé,
-en cohérence avec un champ \verb+out_cont+ vide. Il faut alors un
-champ interpolated pour distinguer les tourbillons interpolés de ceux
-pour lesquels un extremum a été détecté mais sans obtenir de contour
-extérieur.
-
 \subsection{overlap}
 
 Accélération possible en ne comparant à i1 que les trois tourbillons
@@ -949,12 +836,7 @@ laquelle des successeurs ont été trouvés. (Commission 7bb46ec.)
 \subsection{weight}
 
 D'autant plus proche de 0 que les tourbillons sont
-ressemblants. Comment calculer ce poids ? Comment calculer le poids
-faisant intervenir un ou deux tourbillons interpolés ? Pour faire au
-plus simple, j'ai supposé que l'on utilisait pour les arcs faisant
-intervenir les tourbillons interpolés le poids associé aux tourbillons
-visibles entre lesquels on interpole. Normalement, ce choix doit
-donner un poids plus faible à ces arcs.
+ressemblants. Comment calculer ce poids ?
 
 \section{Tests}