Bonjour Jérôme,
Le 31/01/2022 à 15:53, Jérôme Kieffer a écrit :
> Bonjour Aimé,
>
> On est bien d'accord qu'il s'agit surtout d'un problème de science
> humaine: le management du code et de son développeur.
C'est plus largement un problème de gestion des matériels, du code et
des connaissances (développeurs, données, documentations, utilisateurs).
Pour fixer les idées sur la page inventaire d'équipements
http://www.epn-campus.eu/users/pscm/pscm-facilities/pscm-equipment/ il y a :
Ellipsometer for Solids
This is an "home made" ellipsometer by*Patrice Ballet* at the University
Joseph Fourier (Grenoble).
The principle of this rotating quarter wave plate ellipsometer can be
found at this address :
http://pagesperso-orange.fr/aime.vareille/pages/ellipsometrie/
The laser diodes 2 & 3 are required to find the number of periods of the
signal.
The signal acquisition is done with an A/D conversion card at 100 kHz
and with a resolution of 16 bits.
The angle of incidence is set to silicon (75 °) but can be changed
between 0 and 90 degrees.
C'est un équipement "fait maison" qui, en fait, peut aussi bien servir
pour les liquides que pour les solides (il n'en tient qu'aux
utilisateurs ...).
Un premier équipement programmé en ada (héritant d'équipements
antérieurs en fortran) avait accompagné dans les années 1990 celui qui
en a construit d'autres l'adaptant aux technologies émergentes comme
Arduino, Raspberry ... Matlab...
En réalité tous les équipements de l'inventaire devraient être
documentés en environnements logiciels et connaissances ressources :
les hautes technologies nécessitent de plus en plus de puissance de
calcul et d'environnements numériques.
> Si en 1980, Fortran ne souffrait aucune comparaison, il est de plus en
> plus obsolete aujourd'hui: même si des nouvelles normes du langage
> existe, plus personne ne se presse pour les implementer dans un
> compilateur.https://fortranwiki.org/fortran/show/Fortran+2008+status
>
> Cela étant dit, fixer une signature à une fonction et figer l'API est
> une solution qui marche bien. Peu de gens se plaignent de l'interface
> de BLAS (qui est en Fortran)! C'est ce que je conseille à Fred.
>
> Pour ce qui est de ta volonté de documenter du code, on utilise avec un
> certain succès nbsphinx pour convertir des notebook jupyter en
> documentation (générée par sphinx). Juste un exemple:
> https://www.silx.org/doc/pyFAI/dev/usage/cookbook/integration_with_python.html
> Ce n'est pas limité à Python puisque JuPyteR correspond à la
> concatenation de Julia Python et R ... et beaucoup d'autres languages
> de programmation aujourd'hui.
Au delà de la documentation du code, comme l'explique Frédéric, il y a
des problèmes de documentation scientifique.
En ce qui me concerne, je n'ai pas retrouvé toutes les publications
scientifiques que j'avais annotées il y a une trentaine d'années pour
produire certaines parties de code fortran.
La tribulation instrumentale repose aussi sur l'évolution des
ordinateurs : fortran rte6 (HP1000), rsx11m+ (DEC), dos, windows, linux
(PC).
En fait, je suis principalement physico-chimiste technophile, pas
informaticien, et je souhaite participer actuellement à la construction
d'environnements d'instrumentation libre avec pas mal d'optique ce qui
pousse à se rapprocher de phablabs (i.e.
http://www.phablabs.eu/).
> A++
>
> Jérôme
Effectivement, le code scientifique a fort à faire pour améliorer et
étendre sa maintenance long terme sur les dizaines d'années à venir.
Merci pour le lien
https://www.silx.org/
A++
@Aime38 a.k.a. ellipsometrix
> On Mon, 31 Jan 2022 15:30:17 +0100
> Aimé Vareille<aime.vareille@???> wrote:
>
>> Bonjour,
>>
>> En LL pour les maths j'ai aussi vu passerhttps://www.scilab.org/ et
>> https://www.sagemath.org/ sans compterhttps://www.r-project.org/ .
>>
>> https://wiki.octave.org/GNU_Octave_Wiki est-il plus facile pour faire
>> ses gammes ?
>>
>> Question migrations je vois qu'il y a de plus en plus de possibilités
>> qui rendent les réalisations de plus en plus difficile à maintenir et
>> transmettre ...
>>
>> Le bon exemple qui correspond à ce que je voudrais enrichir est
>> https://www.f-legrand.fr/scidoc/index.html
>>
>> Le 31/01/2022 à 10:12, Frédéric a écrit :
>>> Le lundi 31 janvier 2022, Jérôme a écrit :
>>>
>>>> En tant que voisins, on a des déboires du même genre ...
>>>> Notre approche est un peu differente:
>>>> * Les gens qui veulent faire du matlab, on ne les en empêche pas, mais
>>>> ils se démerdent
>>>> * Les gens qui veulent partir sur du "gratuit" (car le libre, ils s'en
>>>> foutent, c'est le prix de la license matlab qui leur pose problème)
>>>> - on traduit les routines numerique en python, numpy et numba/cython
>>>> au besoin, travail bien adapté aux stagiaires avec des tests de non
>>>> régression
>>>> - on refait l'interface graphique au besoin avec les technos à la
>>>> mode du moment. C'était pyQt, maintenant c'est des interface web.
>>>> - Une fois la transition faite, le scientifique n'a plus le droit de
>>>> toucher à son code Matlab.
>>>> * Octave se trouve un peu hors du chemin car pas assez compatible avec
>>>> Matlab d'un coté et trop différent du reste pour être compatible.
>>>> Quelques scientifiques ont franchi le pas mais c'est presque pire
>>>> que Matlab car il y a moins de documentation donc plus compliqué de
>>>> faire du portage.
>>> Alors l'approche initiale était aussi de passer en Python, mais c'est pas
>>> trivial. Même avec Numpy, quand je vois la liste des différences à gérer,
>>> c'est plus qu'une migration :o/ J'ai bien tenté les moulinettes
>>> automatiques, mais y'a absolument rien qui passe.
>>>
>>> Et le problème de repartir de zéro, c'est qu'il n'y aura personne pour
>>> m'expliquer la partie scientifique, et que je n'ai aucune chance de la
>>> comprendre moi-même, vu la tronche du script Matlab :o/ Et si c'est pour
>>> transformer ligne à ligne, sans comprendre, ça va rester un tas de boue
>>> impossible à maintenir ; ça n'a vraiment pas d'intérêt.
>>>
>>> Du coup, pour le moment, Octave me semble la solution la moins pire...
>>> Surtout si ça se résume à 2 fonctions graphiques à modifier.
>>>
>>> Mais, comme tu dis, les docs de ces softs, c'est vraiment pas glorieux !
>>> Même Matlab, franchement, pfff ! Ça ne m'étonne pas que les scripts soient
>>> moches, à la sortie ;o)
>>>
>> --
>> Aimé
>>
>>
--
Aimé
