Extract documentation on tests into separate file

Inst_eddies/Documentation_texfol/Graphiques/.gitignore

 degeneracy.pdf
-regions.pdf
 periodicity.pdf
 copy.pdf
 set_contours.pdf
-elapsed_time.pdf
 SHPC.pdf
-plot_test_output.pdf
-cput_sleep.pdf
-distribution.pdf
-user_proc.pdf
-user_sys.pdf
 slice.pdf
 nearby_extr.pdf
 descending.pdf

Inst_eddies/Documentation_texfol/Graphiques/GNUmakefile

 objects = degeneracy.pdf periodicity.pdf copy.pdf set_contours.pdf	\
-SHPC.pdf plot_test_output.pdf slice.pdf nearby_extr.pdf			\
-descending.pdf input_output.pdf
+SHPC.pdf slice.pdf nearby_extr.pdf descending.pdf input_output.pdf
 
 %.pdf: %.odg
 	unoconv --doctype=graphics $<

Inst_eddies/Documentation_texfol/documentation.tex

@@ -1465,300 +1465,6 @@ On pourrait passer en arguments d'entrée les numéros des
 champs dans les fichiers DBF mais cela ferait 13
 arguments.
 
-\section{Tests}
-
-Les fichiers d'entrée sont sur spirit dans :
-\begin{verbatim}
-/proju/lmd-oce/data/AVISO/DT_2018
-\end{verbatim}
-pour le domaine global et dans :
-\begin{verbatim}
-/proju/lmd-oce/EUREC4A_OA/DATA_SAT_New/SSH_CLS
-\end{verbatim}
-pour le domaine Eurec4A.
-
-\subsection{Tests de correction}
-
-Compilation et exécution testées avec NAG Fortran Compiler Release
-6.2, ifort et gfortran.
-
-Pour faire des tests : données au 1\ier{} janvier 2006. Tests sur
-différents domaines. Cf. figure (\ref{fig:regions}) et
-\verb+domains.ods+.
-\begin{figure}
-  \centering
-  \includegraphics[width=\textwidth]{regions}
-  \caption{Régions pour les tests.}
-  \label{fig:regions}
-\end{figure}
-
-Pour la région 1, coin en :
-\begin{equation*}
-  \lambda = \np{5.125}^\circ, \phi = -\np{36.375}^\circ
-\end{equation*}
-soit $(\np[rad]{0.0894}, - \np[rad]{0.6349})$. Indices dans le domaine
-global, base 1, du coin de la région 1 : 21, 215. 5 minimums et 3
-maximums dans ce cadre. Cf. figure (\ref{fig:extrema}).
-\begin{figure}
-  \centering
-  \includegraphics[width=\textwidth]{extrema}
-  \caption[Région 1]{Région 1, lignes de niveau de SSH (sans
-    signification particulière). Maximums : points rouges, minimums :
-    points bleus.}
-  \label{fig:extrema}
-\end{figure}
-Minimum cible pour le test \verb+Get_1_outerm+ en :
-\begin{equation*}
-  \lambda = \np{9.625}^\circ, \phi = - \np{33.875}^\circ
-\end{equation*}
-Indices dans le domaine global, base 1, de ce minimum : 39, 225. SSH
-en ce mimimum : \np{0.2759}. Cyclone numéro 3 dans ce cadre. Contour
-le plus intérieur : SSH = \np{0.293300003} m. Contour le plus
-extérieur : SSH = \np{0.460504} m. Contour de vitesse maximale : SSH =
-\np{0.3815} m. Cf. figures (\ref{fig:test_get_eddy}) et
-(\ref{fig:test_get_snapshot}).
-\begin{figure}
-  \centering
-  \includegraphics[width=\textwidth]{test_get_eddy}
-  \caption[Test Set\_max\_speed]{Test Set\_max\_speed. Projection
-    stéréographique centrée sur un minimum de SSH. Champ de vitesse,
-    contour de SSH le plus extérieur en bleu, contour de SSH de
-    vitesse maximale en vert. Le minimum de SSH est marqué par un
-    point.}
-  \label{fig:test_get_eddy}
-\end{figure}
-\begin{figure}
-  \centering
-  \includegraphics[width=\textwidth]{test_get_snapshot}
-  \caption[Test Extraction\_eddies\_region\_1]{Test
-    Extraction\_eddies\_region\_1\_noise. Région 1. Contours
-    extérieurs et contours de vitesse maximale. En rouge les
-    anticyclones, en bleu les cyclones. Croix : contour extérieur sans
-    contour de maximum de vitesse distinct. Cercles : contour
-    extérieur et contour de maximum de vitesse distinct. Les contours
-    extérieurs du cyclone 1 et de l'anticyclone 3 touchent le bord et
-    sont donc peut-être artificiellement sous-estimés.}
-  \label{fig:test_get_snapshot}
-\end{figure}
-
-Comparaison sur la région 1 avec le programme Matlab, pour les
-anticyclones 1 et 2. Les coordonnées des extremums sont bien les
-mêmes. Les SSH sur les contours extérieurs sont pratiquement les mêmes
-: différence de l'ordre de \np{0.1} mm. Du coup les contours
-extérieurs sont quasi-identiques. Les rayons des contours extérieurs
-sont presque les mêmes aussi : j'ai \np{87.7} km au lieu de \np{87.5}
-km et \np{90.80} km au lieu de \np{90.81} km. Les SSH sur les contours
-de vitesse max diffèrent de 2 cm environ. Cf. figure
-(\ref{fig:comparaison_Matlab}).
-\begin{figure}
-  \centering
-  \includegraphics[width=\textwidth]{comparaison_201}
-  \includegraphics[width=\textwidth]{comparaison_202}
-  \caption[Comparaison avec le programme Matlab]{Comparaison avec le
-    programme Matlab. Pour chacun des deux tourbillons, le contour
-    sans marqueur est à la valeur de SSH donnée par le programme
-    Matlab.}
-  \label{fig:comparaison_Matlab}
-\end{figure}
-J'obtiens comme vitesse maximale : $\np[m s^{-1}]{0.29}$ au lieu de
-$\np[m s^{-1}]{0.30}$ et $\np[m s^{-1}]{0.23}$ au lieu de
-$\np[m s^{-1}]{0.26}$.
-
-Test sur la région 3, sans minimum d'amplitude. 14 extremums sans
-contour extérieur, dont 5 sur les bords et 11 dégénérés. Avec minimum
-d'amplitude : 34 extremums sans contour extérieur. Je vérifie que,
-pour chaque extremum, s'il n'y a pas de contour extérieur dans le cas
-sans minimum, il n'y en a pas non plus dans le cas avec minimum. Il y
-a donc 20 extremums qui passent à un contour extérieur vide faux à
-cause du minimum d'amplitude. Je vérifie que, pour ces 20 extremums,
-le contour extérieur dans le cas sans minimum est le même que dans le
-cas avec minimum. Entre le cas sans minimum et le cas avec minimum,
-seulement trois contours extérieurs grossissent (je le vois en
-comparant les fichiers outermost\_contour\_1.dbf) : dans le cas avec
-minimum, ils englobent un extremum d'amplitude insuffisante. Dans le
-cas avec minimum, 48 contours extérieurs sont calculés deux fois.
-
-Sur la région 3, avec un mm de minimum d'amplitude, le contour
-extérieur 168 a un diamètre de 27 points, environ 7 degrés en
-longitude. \`A 40° S, donc un diamètre de 600 km environ. On ne peut
-donc pas prendre max\_radius = 12.
-
-Test de
-\verb+max_speed_contour_ssh+. Cf. figure~\ref{fig:test_max_speed_contour_ssh}.
-\begin{figure}
-  \centering
-  \includegraphics[width=\textwidth]{test_max_speed_contour_ssh}
-  \caption[SSH pour le test de max\_speed\_contour\_ssh]{SSH pour le
-    test de max\_speed\_contour\_ssh. Données du 29 novembre 2015. La
-    région est à l'embouchure de l'Amazone.}
-  \label{fig:test_max_speed_contour_ssh}
-\end{figure}
-Bizarrement, la vitesse n'est pas définie à certains points alors
-qu'il n'y a pas de terres.
-
-Tests sur les fichiers INALT60 de Leon Mock. Bien que les fichiers
-NetCDF contiennent des variables bi-dimensionnelles \verb+nav_lon+ et
-\verb+nav_lat+, la grille est en fait exactement cartésienne en
-longitude et latitude. La grille est pratiquement uniforme en
-longitude : le pas de longitude est de l'ordre de \np{e-2} degrés,
-avec une amplitude de variation du pas de l'ordre de \np{e-6}
-degrés. L'amplitude relative du pas en longitude est donc de l'ordre
-de \np{e-4}. La grille est légèrement étirée en latitude : le pas de
-latitude augmente légèrement avec l'indice. L'amplitude relative du
-pas est de l'ordre de \np{e-1}.
-
-\subsection{Tests de performance}
-
-Je constate que le temps d'exécution est très sensible à max\_radius :
-un facteur \np{2.7} environ entre max\_radius = 12 et max\_radius =
-20. Le temps d'exécution semble donc proportionnel à max\_radius$^2$,
-ce qui peut se comprendre.
-
-Les processeurs de ciclad sont des Intel Xeon sur les n\oe{}uds
-interactifs et des AMD Optéron sur les n\oe{}uds de calcul. Le temps
-d'exécution sur n\oe{}ud de calcul est environ trois fois plus grand,
-que le code ait été compilé avec ifort ou gcc. Peut-être que les AMD
-Opteron 6134 sur Ciclad sont juste plus lents.
-
-Sur Ciclad, version \verb+0.17+, le temps passé à la concaténation des
-shapefiles semble du même ordre de grandeur que le temps passé dans
-l'exécutable Fortran. Cf. figure \ref{fig:elapsed_time}.
-\begin{figure}
-  \centering
-  \includegraphics[width=\textwidth]{elapsed_time}
-  \caption[Temps écoulé]{Test de performance de
-    \texttt{inst\_eddies.py}, temps écoulé par date traitée. Versions
-    0.17 et ba6ab118 sur Ciclad, AMD Opteron, ifort 19, release
-    build. Domaine global, 59 dates (janvier et février).}
-  \label{fig:elapsed_time}
-\end{figure}
-Avec la version ba6ab118, bizarrement on ne gagne presque rien. \`A la
-vue de la figure \ref{fig:elapsed_time}, on peut se demander s'il y a
-un cycle reproductible de temps d'exécution par date. Le graphique
-pour une période plus longue ne le confirme pas : figure
-\ref{fig:Inst_eddies_9}.
-\begin{figure}
-  \centering
-  \includegraphics[width=\textwidth]{Inst_eddies_9}
-  \caption[Temps d'exécution pour l'expérience Inst\_eddies\_9]{Temps
-    d'exécution pour l'expérience Inst\_eddies\_9. Sur Ciclad, AMD
-    Opteron.}
-  \label{fig:Inst_eddies_9}
-\end{figure}
-En insérant des appels à \verb+cpu_time+ dans le code Fortran, j'ai
-constaté que l'addition des intervalles de temps donnés par
-\verb+cpu_time+ donnait à peu près le temps écoulé pour l'exécution
-Fortran. Il y a donc peu de temps d'attente. Par ailleurs, j'ai fait
-l'expérience d'écrire exactement le même snapshot dans un slice
-contenant une seule date et dans un slice contenant 14 dates. Le temps de
-la boucle d'appel à \verb+write_eddy+ varie significativement et de
-façon reproductible entre ces deux cas. Je vérifie avec les appels à
-\verb+cpu_time+ que le temps écoulé pour le reste du code ne varie
-presque pas entre ces deux cas. Le temps des appels à
-\verb+write_eddy+ est à peu près égal à la partie CPU système
-rapportée par la commande time. Le temps du reste du code est à peu
-près égal à la partie CPU user rapportée par la commande time. Exemple
-de temps mesurés, domaine global, sur ciclad en interactif :
-\begin{itemize}
-\item 8 s system time, appels à \verb+write_eddy+, dans un slice
-  contenant une seule date
-\item 57 s system time, appels à \verb+write_eddy+, dans un slice
-  contenant 14 dates
-\item 32 s user time, reste du code Fortran, indépendamment de la
-  taille du slice pré-existant
-\end{itemize}
-J'ai regardé l'analyse par gprof de l'exécution mais le temps système
-n'est pas mesuré par gprof. On ne peut donc pas cerner plus
-précisément avec gprof dans quels appels sous \verb+write_eddy+ passe
-le temps système.
-
-Les tests dans \verb+test_output.json+ montrent, sur ciclad :
-\begin{itemize}
-\item pas de diminution systématique du temps écoulé lorsqu'on passe
-  de mixed vrai à faux ;
-\item augmentation du temps écoulé lorsqu'on passe de la création d'un
-  slice à l'ajout à un petit slice ;
-\item augmentation du temps écoulé lorsqu'on passe de l'ajout à un
-  petit slice à l'ajout à un slice de taille moyenne ;
-\item pas d'augmentation systématique du temps écoulé lorsqu'on passe
-  de l'ajout à un slice de taille moyenne à l'ajout à un slice de grande
-  taille.
-\end{itemize}
-Cf. figure \ref{fig:plot_test_output}.
-\begin{figure}
-  \centering
-  \includegraphics[width=\textwidth]{plot_test_output}
-  \caption[Tests dans test\_output.json]{Tests dans test\_output.json,
-    sur Ciclad en interactif et sur un noeud de calcul, ciclad 17. \og
-    old\fg{} : avec la vieille bibliothèque shapelib installée avec la
-    distribution sur ciclad. \og new\fg{} : avec la dernière version
-    de la bibliothèque shapelib. Il y a un facteur 32 entre le plus
-    petit et le plus grand temps.}
-  \label{fig:plot_test_output}
-\end{figure}
-Sur vierne, jean-zay et spirit1, les huit tests prennent chacun entre
-2 et 3 s. Sur ces trois machines, la bibliothèque shp utilisée est
-\verb+libshp.so.2.1.0+, tandis que sur ciclad c'est
-\verb+libshp.so.1.0.1+. Sur jean-zay, c'est moi qui ai installé shp :
-cf. \href{/home/guez/Vierne_documents/Informatique_fonctionnement/User_install_texfol/user_install.pdf}{installation
-  de Shapelib}. J'ai donc fait le test d'installer la dernière version
-de shapelib sur Ciclad et de recompiler avec cette dernière
-version. Il n'y a pas de réduction des temps. Cf. figure
-\ref{fig:plot_test_output}. Sur spirit, sur deux mois traités, le
-temps pris par l'exécutable Fortran est stable vers 24 s, dont environ
-23 s user et 1 s système.
-
-\verb+Inst_eddies_1993_2020+. Cf. figure \ref{fig:distribution}.
-\begin{figure}
-  \centering
-  \includegraphics[width=\textwidth]{distribution}
-  \caption[Fonctions de
-  distribution]{Inst\_eddies\_1993\_2020. Fonctions de distribution de
-    cput et walltime, considérées comme des variables aléatoires avec
-    l'année traitée. cput et walltime donnés par Torque.}
-  \label{fig:distribution}
-\end{figure}
-Une variabilité d'un facteur 2, en cput comme en walltime.  Beaucoup
-de temps d'attente en sommeil pour certaines années. Le temps
-d'attente en sommeil n'est pas corrélé au cput. Cf. figure
-\ref{fig:cput_sleep}.
-\begin{figure}
-  \centering
-  \includegraphics[width=\textwidth]{cput_sleep}
-  \caption[Temps de sommeil]{Inst\_eddies\_1993\_2020. Temps de
-    sommeil : walltime $-$ cput. cput et walltime donnés par Torque.}
-  \label{fig:cput_sleep}
-\end{figure}
-On a bien l'égalité approximative entre walltime donné par Torque et
-real donné par la commande time. On a bien l'égalité approximative
-entre cput donné par Torque et user + sys donné par la commande
-time. Cf. figure \ref{fig:user_sys}.
-\begin{figure}
-  \centering
-  \includegraphics[width=\textwidth]{user_sys}
-  \caption[walltime, sleep, user,
-  sys]{Inst\_eddies\_1993\_2020. walltime = user + sys + sleep. user :
-    CPU user time. sys : CPU system time. user et sys sont donnés par
-    la commande time.}
-  \label{fig:user_sys}
-\end{figure}
-Année 2010 sur AMD Opteron 6378, année 2016 sur AMD Opteron 6134. Sur
-internet, le processeur AMD Opteron 6378 est décrit comme plus
-puissant. 69 \% d'augmentation de user de 2010 à 2016. Le nombre de
-tourbillons (anti + cyclo) augmente de 3 \% de 2010 à 2016. Cf. figure
-\ref{fig:user_proc}.
-\begin{figure}
-  \centering
-  \includegraphics[width=\textwidth]{user_proc}
-  \caption[CPU user time and processor type]{Relation entre temps CPU
-    utilisateur et modèle de processeur. Les deux processeurs sont des
-    AMD Optéron, modèles 6134 et 6378.}
-  \label{fig:user_proc}
-\end{figure}
-Il y a bien une corrélation entre user et processeur mais la
-variabilité pour un processeur donné reste grande, je ne comprends pas
-pourquoi.
-
 \section{Améliorations, prolongements}
 
 Le stockage de la vitesse en chaque point d'un contour serait

Inst_eddies/Tests/Documentation_texfol/.gitignore

+/*.aux
+/*.log
+/*.out
+/*.pdf
+/*.synctex*
+/*.toc
+/*.lof
+/*.lot
+/auto/

Inst_eddies/Tests/Documentation_texfol/Graphiques/.gitignore

+regions.pdf
+elapsed_time.pdf
+plot_test_output.pdf
+cput_sleep.pdf
+distribution.pdf
+user_proc.pdf
+user_sys.pdf

Inst_eddies/Tests/Documentation_texfol/Graphiques/GNUmakefile

+objects = plot_test_output.pdf elapsed_time.pdf regions.pdf
+
+%.pdf: %.py
+	$<
+
+all: ${objects}
+
+clean:
+	rm -f ${objects}