wiki:DevelopmentActivities/Assimilation

Version 24 (modified by mmaipsl, 12 years ago) (diff)

--

Assimilation of ORCHIDEE model

6/06/2012: Réunion de travail

Martial Mancip and Ernest Koffi

Stratégie pour la mise au format automatique du code ORCHIDEE pour l'assimilation

Pour l’assimilation des données du modèle ORCHIDEE (e.g., carbone, flux de surface, etc..), le différentiateur automatique TAF est utilisé. Le logiciel TAF n’est pas capable de générer les codes dérivés d’ORCHIDEE sans une mise au format du code au préalable. Ce travail préalable consiste à considérer par exemple le programme principal dim2_driver.f90 comme une fonction en lui passant le nombre de paramètres du modèle ORCHIDEE qu’on veut optimiser, le vecteur donnant les valeurs des paramètres et en sortie la fonction coût calculée à partir des variables pour les lesquelles les paramètres ont été optimisés. Il faut également adapter des routines/modules d’ORCHIDEE relatifs aux initialisations des paramètres et aux données d’entrée (dimensions des données du problème, données météo, etc..

??? ça je ne vois pas

).

Dans le but de profiter des développements futurs d’ORCHIDEE pour l’assimilation des données, nous développons des outils de transformation (scripts awk) pour la mise au format automatique du code d’ORCHIDEE pour TAF. La démarche pour cette mise au format se fait en quatre étapes suivantes. Il faut noter que certaines de ces étapes ont été déjà codées mais par souci de clarté, nous énumérons toutes les étapes sans précision. En dehors des premiers points de l’étape 1 (utilisation de model, lancement de makeorchidee_fcm), toutes les autres étapes et points décrits ci-après seront effectuées en une seule opération par l'utilisateur : 

ORCHIDEE> makeorchidee_fcm -optim

Etape 1 : Chargement des routines d’ORCHIDEE/IOIPSL/TAF pertinents pour l’optimisation que l'on veut réaliser dans un répertoire de travail

  • lancer la commande util/model pour une nouvelle configuration spécifique à l'ASSIMILATION dans le fichier mod.def (à éditer au préalable pour choisir le type d'optimisation et les tags ORCHIDEE/IOIPSL):
    • Récupére un tag/trunk d’ORCHIDEE/ORCHIDEE_OL pertinente à l’optimisation qu’on veut réaliser
    • Récupére aussi les drivers/sources spécifiques pour l’optimisation qu’on veut réaliser dans le répertoire DRIVER_ASSIMILATION. Il s'agit e.g., des initialisations des paramètres pour TAF etc..

finalement, DRIVER_ASSIMILATION, c'est bien trop long .... ASSIMILATION suffit, non ?

  • lancer ORCHIDEE/makeorchidee_fcm qui effectue les étapes suivantes :
    • Copie les sources du répertoire NETCDF nécessaire pour TAF dans modeles/DRIVER_ASSIMILATION
    • Créer un répertoire de travail temporaire modele_optim_temp à partir du répertoire modeles. Mettre les différents répertoires du code d’ORCHIDEE (i.e., ORCHIDEE, ORCHIDE_OL) et le répertoire IOIPSL en respectant la même arborescence de modeles.

Etape 2 : Préparation des routines d’ORCHIDEE pour la mise au format pour TAF

makeorchidee_fcm se place dans modeles_optim_temp/ORCHIDEE_OL et :

  • configure le Makefile dans ce répertoire pour enlever les pré-compilations PARALLEL et ASSIMIL. Ainsi par la suite la pré-compilation ASSIMIL n’existe plus !

    On abandonne en fait la pré-compilation ASSIMIL car elle n'est pas nécessaire... et n'existera pas dans les tags ORCHIDEE...

  • Crée les modules d’allocation/initialisation dans les répertoires où existe un fichier init_alloc. Ce nouveau fichier s’appelle ${rep}_init_alloc.f90 (par exemple sechiba_init_alloc.f90) et la procédure pour sa création est la suivante :
    • Lister les subroutines/fonctions dans le fichier init_alloc du répertoire traité juste après la commande CONTAINS en commençant par « List of subroutines for initialization : »
    • Ensuite mettre le nom de chacune de ces différentes subroutines/fonctions sur chaque ligne en commençant par « !- »

Non c'est pas vraiment ça ... c'est embrouillé, je trouve; tu reprendras lorsque je te montrerai ce que j'ai déjà fait (et presque terminé !)

Etape 3 : Création des routines pour TAF

Boucler sur le/les fichiers sources de chaque répertoire deux fois avec deux scripts awk

  • script 1 : DRIVER_ASSIMILATION/TOOLS/variables.awk
    • Avant IMPLICIT NONE :
      • Garder les USE dans le fichier $rep_init_alloc ( => à voir ... )
    • Entre IMPLICIT NONE et CONTAINS :
      • Garder les INTERFACE. Gestion particulière ? En effet, TAF n’arrive pas à les gérer proprement sans l’utilisation de directives. En particulier, la gestion des INTERFACE des codes IOIPSL se fait via le fichier taf_directives.f90.
      • Couper les variables globales SAVE. Mettre ces variables dans le fichier $rep_init_alloc. Il faut noter que pour l’assimilation, toutes ces variables sont désormais PUBLIC.
    • Couper les variables SAVE locales (dans les fonctions) dans les fichiers $rep_init_alloc du répertoire traité. Mettre ces variables dans le fichier $rep_init_alloc. Aussi, toutes ces variables sont désormais PUBLIC. Attention à se conformer à la règle de programmation pour éviter la redondance !!! Pour cela, on pourrait remplacer $nommodule_nomfonction_var ??? Je ne comprends pas bien ca...

Comme on met un variable "var" locale à une fonction "nomfonction" depuis un module "nommodule" en SAVE global dans $rep_init_alloc, on pourrait la renommer $nommodule_nomfonction_var en global et partout dans cette fonction pour éviter les problèmes à la compilation

  • Ajouter CONTAINS à la suite dans le fichier $rep_init_alloc
  • script 2 : DRIVER_ASSIMILATION/TOOLS/subroutines.awk
    • Lire la phrase « List of subroutines for initialization : » et construire un tableau init_functions qui lit chaque ligne commençant par « !-». Exemple : 
      ! List of subroutines for initialization :
!- routing_init
!- routing_clear
!- routing_diagnostic_p
!- routing_diagnostic
!- routing_basins_p
!- routing_basins
!- routing_getgrid
!- routing_sortcoord
!- routing_findbasins
!- routing_simplify
!- routing_cutbasin
!- routing_hierarchy
!- routing_findrout
!- routing_globalize
!- routing_linkup
!- routing_fetch
!- routing_truncate
!- routing_killbas
!- routing_names
!- routing_irrigmap
    • Couper les fonctions init dans init_alloc pour inclusion dans $rep_init_alloc
  • Gérer/simplifier les appels du module d'optimisation (depuis TANGEANT) depuis intersurf.f90
  • Retravailler les parties driver/readdim2.f90
  • Copier toutes les sources de modeles_optim_temp dans modeles/TANGEANT
  • Copier toutes les sources de modeles/DRIVER_ASSIMILATION dans modeles/TANGEANT
  • Copier le Makefile de modeles/DRIVER_ASSIMILATION dans modeles/TANGEANT
  • Copier les sources NetCDF dans le répertoire modeles/DRIVER_ASSIMILATIONS/NETCDF dans modeles/TANGEANT
  • Supprimer modeles_optim_temp

Etape 4 : Application de TAF pour la génération des routines dérivées

Se placer dans le répertoire TANGENT crée (voir ci-dessus) puis lancer TAF pour la différentiation souhaitée, e.g., TL (tangent linéaire) , VTL (tangent linéaire vectoriel), AD (code adjoint). Pour détails, voir le Makefile dans TANGEANT

Questions/Reflexions?

Il faut plus rédiger cette partie, je pense...

  • Il faudra dans les tags/trunk ORCHIDEE : construire et maintenir de la liste des subroutines/fonctions d’initialisation par module (pas d'autres implications des développeurs "standard" pour conserver les optimisations dans les futures développements)
  • Gestion des « includes » des directives TAF. Il faut noter que cela se fait désormais dans model.f90 mais doit être spécifique à chaque version pour l’optimisation et aussi à la version de IOSPL
  • Gestion de l’interdépendance des USE
  • Copie des « INTERFACE » d’initialisation
  • Gestion de la liste des modules. Le faire dans le AA_make de TANGEANT ?
  • Conformité aux règles de programmation
  • les sources NetCDF

18/11/2011: Réunion de travail

Martial Mancip (MM), Ernest Koffi (EK), Philippe Peylin (de passage)

Discussions sur les différentes étapes à suivre pour l'efficacité du travail avec Fastopt.

Situation actuelle

Nous avons 3 versions du code "Assimilation"

  • V1: Version du code envoyée à Fastopt par le LSCE en mai 2011
  • V2: Version V1 travaillée par Fastopt pour créer à Fastopt le code tangent avec l'option -keep. Version envoyée au LSCE en septembre 2011. Test effectué au LSCE avec succès
  • V3: Version actuelle du code au LSCE dans la branche "Assimilation"

Prochaines étapes à courte échéance

1) Travail à faire par LSCE pour Fastopt

  • MM crée un répertoire privé sous svn pour Fastopt (on appelle ce répertoire fastopt)
  • EK construit une ligne de commande svn import pour fastopt et envoie un e-mail à Fastopt
  • Fastopt dépose sa version actuelle dans ce répertoire

2) Travail à faire au LSCE pour le suivi du travail

  • Faire passer la version récente de TAF sur la version du code dans la branche "Assimilation"
  • Analyser et documenter les différences entre les différentes versions V1, V2, et V3 décrites ci-dessus
    • V1 et V2
    • V3 et V2
  • Envoyer un e-mail à Fastopt pour informations sur les différences

23/05/2011: E-mail envoye a Thomas Kaminski pour la version actuelle d ORCHIDEE pour Assimilation

Hello Thomas,

We have now fixed the problem on the compilation of ORCHIDEE model by using the option "--chkglobal" with lf95. The forward run test has also been performed (i.e., call three times the model, the two first ones without the change of the parameters (as priors), and the last one by perturbing the priors).

  1. The new version of the ORCHIDEE model shaped for TAF can be found from our ftp server here: (These documents are only available on this server for a period of 7 days):

​ftp://ftp.cea.fr/incoming/y2k01/orchidee

Note that the previous provided readme file is still valid. For this new version, some additional netcdf files have been considered for the runing of TAF (see the line 17 in the file AA_make in the directory ORCHIDEE_OL to indicate the right path:, i.e, NETCDF_SRC).

  1. In parallel, we are working on the generation of the tangent linear codes of the model with TAF and we have experienced some recurrent errors and warnings. Find hereafter some of them:
  • An error on the string length: " INTERNAL ERROR: string too long." We do not understand this error since we have set the maximum length of the string to 130 throughout ORCHIDEE model and set to 132 in the command line for TAF in the Makefile. For more details on this error and others, see the output file from TAF running (i.e., taf_output_current and taf-tlm-current.log in the directory TANGEANT).
  • The following recurrent warning for several routines, e.g., : " *WARNING* : model.f90:463 : call of intersurf_main too many arguments (44) defined = 0" (see in the file taf-tlm-current.log).
  • TAF seems to not handle the following fortran command, as e.g., this line in some netcdf files: localMap (:numDims ) = (/ 1, (product(localCount(:counter)), counter = 1, numDims - 1) /)

We have then made some modifications in such netcdf files and also made compliant some parts of the ORCHIDEE model to proceed further with TAF. For more details, we have provided the netcdf files we are using including both the original and modified files (i.e., netcdf_expanded.f90 and netcdf_text_variables.f90; see in the directory NETCDF in TANGEANT).

Note: As it is built now the Makefile for the generation of TL codes (exec tlm), one needs to compile the forward model before, otherwise there is an error. This needs to be fixed.

  1. Issues on the generated TL codes by TAF

As already mentionned, TAF seems to generate TL codes, but we think that these codes are incompleted. However, we have tried to compile them. Hereafter are some problems we encountered:

  • The generated TL codes by TAF have sometimes string length over 132 characters. Of course, such a length is not allowed by the lf95 when considering the stricted options of this compiler. As an example, the generated TL code for TL relevant to the module intersurf.f90:

subroutine intersurf_main_2d( kjit, iim, jjm, kjpindex, kindex, xrdt, lrestart_read, lrestart_write, lon, lat, zcontfrac, & &zneighbours, zresolution, date0, zlev, u, v, qair, temp_air, epot_air, ccanopy, cdrag, petacoef, peqacoef, petbcoef, peqbcoef, & &precip_rain, precip_snow, lwdown, swnet, swdown, pb, vevapp, fluxsens, fluxlat, co2_flux_tot, coastalflow, riverflow, tsol_rad, & &temp_sol_new, qsurf, albedo, emis, z0 )

Can you clarify us on these issues ? Thanks.

Please do not hesitate to contact us for any clarifications and additional questions.

Best regards,

Ernest & Martial

Reunion du 20/04/2011 sur l etat d avancement du travail sur l assimilation d ORCHIDEE avec TAF

Presents: Catherine Ottle (CO), Cedric Bacour (CB), Philippe Peylin (PP), Sylvain Kuppel (SK), Abdou Kane (AK), Martial Mancip (MM), Ernest Koffi (EK)

EK presente les objectifs de ce travail et son avancement (voir presentation. Est-ce possible de mettre cette presentation ici ?)

En resume, il faut adapter ORCHIDEE de telle sorte qu'on puisse l appeler comme une fonction model(n,x,fc): avec n le nombre de paramatres du modele a optimiser, x le vecteur parametres et fc la fonction cout en fonction des variables pour lesquelles les parametres sont optimises. Ensuite, il faut compiler le modele avec le compilateur lf95 en utilisant les options les plus strictes possibles de ce compilateur, en occurence l option --chkglobal. Ce travail est effecute par EK et MM.

Etat d avancement

  1. Modele direct
    • Mise en forme du modele telle que decrite ci-dessus effectuee
    • Compilation du modele sans l option --chkglobal: OK
    • Test du modele sans l option --chkglobal: OK. Ce test consiste a appeler ORCHIDEE deux fois de suite sans modifier les parametres et s assurer que la fonction cout est la meme. Ceci suppose que toutes les initialisations/deallocations des tableaux du modele ont ete bien effecuees. Ensuite, un troisieme test suivant les deux precedents en perturbant les parametres.
    • Compilation du modele avec l option --chkgloabl: OK, mais le modele plante a l execution.
  1. Modele tangeant lineaire (TL)
    • Code TL genere mais ne compile pas.
  1. Cette version du modele suit la structure de compilation/gestion du modele ORCHIDEE generique
  1. Une branche Assimilation est cree : ​http://forge.ipsl.jussieu.fr/orchidee/browser/branches/Assimilation
  1. Discussions:
  • Calcul de la fonction cout

CB pose la question sur la maniere dont on calcule la fonction cout de la nouvelle version d ORCHIDEE pour l assimilation. En effet, la fonction cout considere les observations pour les variables pour lesquelles on optimise les parametres. Dans la version TL qui utilise seulement une partie du modele et qui marche (travail de Francois Delage (FD) et Cedric Bacour), la fonction cout est calcule a partir de toutes les variables modelisees pour lesquelles on cherche a optimiser les parametres. L argument principal justifiant cette deuxieme maniere de calculer la fonction cout est qu'une fois les codes TL generes, on y revient plus sauf s il y a une modification majeure. EK pense que les 2 options sont equivalentes pour TAF et surtout que la generation des codes TL par TAF ne prend pas de temps (i.e., une fois que les codes ont ete bien generes) . Ainsi, une modification du code avec ajout d autres variables/parametres ne necessite pas un travail supplementaire important. Il est neamoins prevu de considerer les deux options dans le but de comparer les codes TL.

  • Directives TAF

CB demande si les directives TAF utilisees par FD et CB ont ete conservees. En grande partie oui, sauf les directives dans le nouveau model.f90 ont ete enlevees. Une verification faite apres la reunion montre que les codes TL generes par TAF avec ou sans ces directives restent identiques.

  • Option -keep de TAF

EK pense que cette option ne devrait pas etre consideree car TAF analyse les liens entre les entrees et sorties du modele. Cette option utilisee apres la reunion permet neanmoins d avoir un nombre de modules legerement eleve pour lesquels le code TL est cree. Neanmoins ce code TL ne compile toujours pas.

23/03/2011 E-mail and ORCHIDEE codes sent to FastOpt? in the framework of the work on TL & AD codes of ORCHIDEE by TAF

Dear Thomas,

We have now a version of the whole ORCHIDEE model shaped for TAF, which allows keeping the model structure in order to benefit for any improvements of the model. This version: 1) considers the main driver of ORCHIDEE as a subroutine called model (n,x,fc) with n the number of the parameters, x the parameters vector and the cost function fc. The parameters are the default values of ORCHIDEE model parameters and obtained during the initialisation of the model.

2) compiles with lf95

3) We have succesfully made the following tests with this version:

  • two consecutive calls of model(n,x,fc) with the same set of parameters: the cost function is OK:, ie., the same value as expected
  • A third run after the two aboved mentionned with the set of parameters perturbed: the cost function is different as expected.

4) We have started generating the TL codes with TAF with this version without the option -keep, but the work is still ongoing (Note that the reduced version of ORCHIDEE as previously provided to you is working well with TL codes used for our needs). Indeed, with this version, TAF starts to generate the codes and produces some TL codes which are not yet completed. However, to allow you making use of the code, I have put the current version of the code called here "Assimilation.tar.gz" on our ftp server:

​ftp://ftp.cea.fr/incoming/y2k01/orchidee (Note that the data are on this ftp server only for one week from now)

( If you wish to take the data from UNIX/LINUX: ftp ftp.cea.fr Name (ftp.cea.fr:...): anonymous Password: just put enter ftp> cd incoming/y2k01/orchidee Then you can get the data )

You will find a readme file (detailled below), which gives the various steps to be followed for both the compilation and the running of the ORCHIDEE code shaped for TAF:

A/ Having the ORCHIDEE model shaped for TAF

  1. go to the directory "util"

2) do ins_make -t lf95. This will create automatically the Makefiles in the directories modeles/ORCHIDEE and modeles/ORCHIDEE_OL where are stored the main codes of ORCHIDEE and the directory "modeles/ORCHIDEE_OL/TANGEANT" where the following drivers (i.e. model.f90, prgcost2.f90, etc..) are stored .

  1. go to the directory "ORCHIDEE_OL"
  2. do gmake tangeant. This will shape all the codes for TAF and put them in the same directory called "TANGEANT".

B/ Compilation of the codes shaped for TAF in forward mode

  1. go to the directory "TANGEANT"
  2. do gmake. The exec "orchidee_ol_tg" is stored in ../../../bin

Actions A/ and B/ can be executed automatically by using the script shell called "arrange_orchidee_for_taf": do arrange_orchidee_for_taf and the codes are pop on in the directory modeles/ORCHIDEE_OL/TANGEANT.

C/ Running the ORCHIDEE model in forward mode We have prepared a set of data in the directory "post" (i.e., inputs, ....) for a test run:

  1. go to the directory post
  2. Before runing the code, ensure that the run parameters are OK for you. The run definition file is called "run.def". For an example, the time length of the run goto about line 498 ( change TIME_LENGTH if necessary , e.g. TIME_LENGTH= 2D for two days of simulation). For the other parameters, you do not need to change them for this test.
  3. Ensure that there are not any restart files in the output directory called "output". In case they are some restart files, the run can stop. To avoid this, we have created a script called "lance" which cleans this directory before the run.

Note that in the current configuration of this forward code, we call three times ORCHIDEE: the first and second ones use the same values of the parameters and the third one with a perturbed parameters.

D/ Generating ORCHIDEE TL For generating TL and other codes from TAF, the Makefile under TANGEANT can be modified if necessary. However, for the current configuration, to generate TL

  1. goto the directory TANGEANT
  2. do gmake tlm, but it still does not generate a complete TL code as mentionned earlier.

E/ Other details: NETCDF stuff in the Makefile under the directory TANGEANT needed for TAF. Give the right netcdf links at lines 54 and 55 of the current Makefile. NCDF_INC = NCDF_LIB = . In the current version, for TAF we use 3 files (netcdf_constants.f90, typSizes.f90, netcdf.f90 in the directory TANGEANT) relevant for netcdf. Note that these files are not in the repository of ORCHIDEE ! Of course, the link to taf "staf" needs to be provided at line 159 in the current Makefile

Hope that clarifies the matter and thus we can start efficiently work with the code to fulfill our objectives.

Please do not hesitate to ask us (I and/or Martial) for any clarifications/questions about this version.

With our best wishes,

Ernest and Martial

08/12/2010 Réunion sur l'externalisation des paramètres d'ORCHIDEE

(Didier Solyga, Martial Mancip, Ernest Koffi)

Pour l'externalisation des paramètres d'ORCHIDEE, il y a actuellement deux versions du modèle:

  1. version utilisée pour l'assimilation (Delage/Cedric/Ernest?: ci-après version DCE) et
  2. la version d'externalisation générique (Didier: version DM).

Fusion des versions

On a parcouru les modules relatifs à l'externalisation de ces 2 versions citées ci-dessus. Globalement, ces 2 versions peuvent être fusionnées. Néanmoins ceci nécessitera un travail assez important.

  • version CDE: l'externalisation des paramètres se fait dans le module interface_optim.f90
  • version DM: l'externalisation se fait dans 2 modules: constantes.f90 and pft_parameters.f90
  • La version DCE est bien avancée, mais des problèmes restent à résoudre pour la rendre flexible. Particulièrement les deux points suivants ont été discutés:
    1. Le gros du travail concernerait la structure du module interface_optim.f90
    2. En détail, e.g., la structure actuelle de dépendence des paramètres au temps de la version DCE est pour le moment trop rigide. En effet, tout ajout ou modfication de la liste des paramètres nécessitera des modifications à plusieurs endroits du code.

Coordination des travaux

Un nombre de paramètres important a déjà été externalisé pour l'assimilation. On s'est aperçu que certain d'entre eux avaient aussi été externalisés dans la version DM et ne voulaient pas dire la même chose !
exemple Q10 dans stomate_litter :

  • version DCE : 
        !!>ORCHIS
    !!tempfunc_result(:) = EXP( 0.69 * ( temp_in(:) - (ZeroCelsius+30.) ) / 10. )
    tempfunc_result(:) = EXP( LOG(q10(:)) * ( temp_in(:) - (ZeroCelsius+30.) ) / 10. )
    !!<ORCHIS
  • version DM : 
       tempfunc_result(:) = exp( soil_Q10 * ( temp_in(:) - (ZeroCelsius+tsoil_ref)) / Q10 )

Il est donc impératif que P. Peylin et N. Viovy tranchent sur les définitions exactes.

Actions:

  • Didier doit s'assurer qu'il externalise au moins les paramètres utilisés dans l'assimilation

Autres: Préparation du code pour l'adjoint

Pour l'adjoint d'ORCHIDEE, FastOpt? veut un code préalablement compilé par le compilateur lf95. Martial n'a réussi à compiler le code qu'en mettant tous les codes sources dans le meme répertoire. Plus particulièrement, les difficultés sont survenues sur les modules parallel.f90 et slowproc.f90. Est-ce un défaut du compilateur? La question reste posée.

19/11/2010

réunion de préparation de l'acceuil de Thomas Kaminski (équipe FastOpt?)

  • On a constaté le conflit de compilation du code modifier par François Delage pour TAF. On a simplifier cette compilation : travail sur l'initialisation du routage. Après demande cette question qui lui a été posée :
    Bonjour François,
    Nous poursuivons ton travail et de fois viennent des questions comme celles de Martial formulées ci dessous. Peux-tu nous éclairer urgemment sur ce point car nous recevrons Thomas Kaminski le jeudi 25 novembre pour travailler sur le code.
    Une première réponse de sa part a été :
    Tout simplement parce que la subroutine routing ne contenais pas de variables independantes et n'etait donc pas une subroutines active que ce soit pour l'adjointisation ou pour la linéarisation. Si je me souviens bien, il existe deux version de routages dans orchidee et j'avais surement decidé de gagner du temps en sortant routing du process.
    Il y a surement d'autres raisons mais ca me vient pas la naturellement.
    Il semble que ce choix est judicieux, car il permet d'incorporer plus simplement les directive pour l'assimilation dans le code SVN de ORCHIDEE.
    • Martial doit faire ces tests d'incorporation et de compilation.
    • Ernest doit tester cette première version modifiée avec TAF.
  • On a analyser les scripts de pré-travail présents dans le répertoire bin/preproc. Pour automatiser la création du modèle modifier, on doit re-travailler le script launch_preproc.ksh. On aura l'arborescence classique après récupération du modèle avec util/model puis installation standard des Makefiles avec util/ins_make.
  • voir REUION_19-11-10​

02/08/2009

Réunion de préparation du voyage vers FastOP
Le but est de cette réunion était de comprendre la chaîne de compilation pour fabriquer le tangeant linéaire.
Une simplification de cette chaîne est possible. Les notes succintes concernant cette chaîne et des améliorations possibles est attaché à cette page : COMMENTAIRES_compilation​

Attachments (2)

Download all attachments as: .zip