Skip to content

STACK

Jump to bottom
hprzeta edited this page Oct 16, 2026 · 59 revisions

Riemann_Lab — Stack & Roadmap

🛠️ Référence stable. Outils, branches, matériel, roadmap formation. Change rarement. N'est pas relu au démarrage d'une session de calcul. État courant → Handoff.md, historique daté → JOURNAL.md.

🗺️ Contexte général

Élément Valeur
Dépôt GitHub hprzeta/Riemann_Lab
Branche dév. Python Riemann_Lab_IA ⭐
Branche dév. C Riemann_Lab_C (Phase C — Illinois en C/libmpfr)
Branche test Riemann_Lab_Test
Branche production main
GitHub Pages https://hprzeta.github.io/Riemann_Lab/ (depuis /docs sur Riemann_Lab_IA)
Wiki (dépôt séparé) ~/projet_zeta/Riemann_Lab.wiki/ — branche master
Logo PNG docs/images/logo_riemann_lab.png — 500×235 px, 11 Ko, exporté via cairosvg depuis le SVG animé
venv Python ~/projet_zeta/zeta_env/ (Python 3.12)
Sources optimisation ~/projet_zeta/src/calculs/optimisation/
Mail projet hprzeta@protonmail.com

Objectifs :

  1. Numérique — calculer les 10 000 premiers zéros non-triviaux de ζ(s) sur Re(s)=½ ✅ (10 142).
  2. Recherche — agent IA autonome de recherche mathématique collaborant avec des IA universitaires.

🔁 Règle permanente — fichiers dupliqués. Certains fichiers de référence existent en plusieurs copies dans le projet (wiki, pdf/cours, .claude/skills/riemann-lab/references, docs/, skills_export/, racine repo). À chaque session, avant de travailler sur l'un d'eux, vérifier que toutes les copies sont synchronisées sur la version la plus récente (comparer par date de dernier commit git, pas par mtime disque — le wiki est un dépôt séparé). Ne jamais laisser deux copies diverger. Détail → Handoff.md § Contraintes actives.

🔁 Règle permanente — KaTeX sur le wiki GitHub, 4 causes de rendu cassé (corrigées le 12/09/2026 sur tout le wiki, JOURNAL entrée 2026-09-12). GitHub casse le rendu KaTeX de 4 façons indépendantes, silencieusement (aucune erreur, juste du LaTeX brut affiché) :

  1. \_ \# \, \; \! \% — le \ est retiré même en mode math (\,/\; deviennent une virgule/point-virgule visibles, \! un ! visible). Jamais de \ devant ces caractères dans une formule.
  2. Un bloc $$...$$ dont le contenu contient un retour à la ligne interne n'est jamais reconnu comme math — même avec les $$ isolés sur leur propre ligne. Toujours réunir le contenu sur une seule ligne entre les $$.
  3. | littéral dans une cellule de tableau ($|X|$) casse le découpage en colonnes ; ]( dans une formule (ex. ℳ[f](s)) est lu comme un lien Markdown. Utiliser \lvert X\rvert ; insérer un {} entre ] et (.
  4. $ collé sans espace à ) ~ - – — * casse la reconnaissance du délimiteur. Toujours une espace entre un $ et la ponctuation adjacente, ou déplacer le séparateur à l'intérieur du mode math (\sim, \text{–}).

Vérification fiable : le rendu KaTeX de GitHub est asynchrone et déclenché par interaction (clic + scroll), pas par le temps — une page chargée sans interaction peut rester bloquée sur son état brut indéfiniment. Vérifier via claude-in-chrome + document.body.innerText.match(/\$\$/g) après clic+scroll+attente, jamais par simple lecture visuelle immédiate après navigation.

$ inline s'est révélé fiable à 100 % partout durant cette investigation — en cas de doute persistant sur un bloc $$, le convertir en $ inline plutôt que de deviner.

🌿 Branches Git

Branche Rôle
Riemann_Lab_IA ⭐ Développement principal — Python, wiki, docs, benchmarks
Riemann_Lab_C Phase C — module C, libmpfr, Illinois accéléré, ASM
Riemann_Lab_Test Tests ponctuels, Codespaces
main Production — merge depuis Riemann_Lab_IA

Convention : toutes les branches suivent le préfixe Riemann_Lab_*. phase-C-core supprimée le 18 mai 2026 → renommée Riemann_Lab_C.

git checkout Riemann_Lab_IA   # Python, wiki, docs
git checkout Riemann_Lab_C    # Module C, libmpfr, Illinois C
git checkout Riemann_Lab_Test # Tests ponctuels

⚠️ Règle scripts/ (ajoutée 15/09/2026) : tout ce qui est sous ~/projet_zeta/scripts/ (zeta_tmux.sh, zeta_monitor.py, wg_auto.sh, zeta_distribute*.py — infra cluster/réseau, aucun rapport avec Phase C) se committe exclusivement depuis Riemann_Lab_IA. git checkout Riemann_Lab_IA d'abord, systématiquement, même en session Phase C. Incident : les correctifs jump-host/ProxyJump du 05–06/09 (commits 23dce34, 4db06de) avaient été committés proprement mais uniquement sur Riemann_Lab_C, jamais portés sur Riemann_Lab_IA — la branche où ces scripts tournent réellement. Repérés et portés le 15/09/2026 (commits 0fab5cd, c9f8f0e, 8d9e61a).

🖥️ Matériel

Machine principale — zeta-lab

Composant Valeur
Réseau WiFi
CPU Intel Core i7-7500U, 2 cœurs / 4 threads
RAM 16 GB (upgrade effectué le 25/07/2026 — free -h : 15Gi total)
Swap actuel 16 GB (conservé après upgrade — encore utile sous charge 8 workers)
GPU affichage Intel HD Graphics 620
GPU calcul NVIDIA GeForce GTX 960M — 4 GB VRAM
CUDA 12.0 / 12.2 — Compute Capability 5.0 (< 6.0 → NVRTC non supporté)
OS Ubuntu 24.04, VSCode, Python 3.12

nvtop : lire le graphe historique du haut (fiable), pas la colonne GPU% par processus (bursts ~50 ms invisibles à l'échantillonnage 2 s). OLLAMA_MODELS=/mnt/data/models_ia/ollama · OLLAMA_CUDA=1 (.bashrc). 1 seul modèle LLM à la fois (4 GB VRAM).

Stockage — disque rejeté

SSD 3.8 To externe (USB, /dev/sdb) — REJETÉ. Testé sur zeta-lab (PC1) le 21 juin 2026 en vue d'un volume dédié au vault RAG/ChromaDB de l'Objectif 2. mkfs.ext4 a échoué (erreur d'E/S), dmesg a révélé une erreur SCSI « Logical block address out of range » dès ~2,03 To (bien avant les 3,81 To annoncés). Confirmation finale par f3probe --destructive : capacité utilisable = 0 octet (0 bloc). Disque défectueux ou frauduleux (fausse capacité). Retourné au vendeur / mis au rebut. Ne jamais réintégrer ce disque au projet.

Stockage — vault RAG (Objectif 2)

SSD Micron 1100 256 Go (Micron_1100_MTFDDAK256TBN, S/N 1702155DE7AA) — EN SERVICE depuis le 22 juin 2026. Disque de remplacement après le rejet du SSD 3,8 To ci-dessus (modèle différent, capacité réelle confirmée : 256 GB / 238,47 GiB). SMART : PASSED, 89 % lifetime remaining, 1991 h d'usage, 1002 cycles d'allumage — usure normale (occasion). ⚠️ Anomalie mineure non bloquante : liaison SATA négociée à 1,5 Gb/s (max 6,0 Gb/s) + 2 erreurs CRC UDMA, probablement câble/port — à surveiller.

Élément Valeur
Device /dev/sdb1 (partition unique, GPT, pleine disque)
Filesystem ext4 — mkfs.ext4 -i 8192 -m 1 -L vault_rag
UUID 9476fad5-8512-4e0d-8cd4-50c9acae01c2
Point de montage /mnt/vault_rag (fstab : defaults,noatime,nofail)
Propriétaire riemann:riemann
Arborescence chromadb/ · corpus/ · llamaindex_cache/ · agent_logs/
Usage Vault RAG/ChromaDB — Objectif 2 (agent IA autonome de recherche)
Mise en service 22 juin 2026

⚠️ Le nom /dev/sdX change selon l'ordre de branchement USB (le vault a été sdb1, puis sdc1 quand le disque de clone est branché) : identifier le disque par UUID ou par étiquette (vault_rag), jamais par sdX. L'option nofail du fstab évite de bloquer le démarrage si le SSD est absent.

Stockage — disque de clone

Toshiba MQ04ABD200 (1,8 To, USB) — disque de clone de zeta-lab, utilisé par zeta-clone (zeta_backup_toshiba.sh, rsync --delete : il reproduit la source et efface tout ce qui n'existe pas sur PC1). Partitions identifiées par étiquette, jamais par sdX : Toshiba-PC1-root, Toshiba-PC1-home, Toshiba-PC1-data. Disque physique distinct de celui du dépôt et du vault RAG. Un fichier copié à la main sur l'une de ces partitions doit exister au même chemin sur PC1, sinon le prochain clone l'efface.

Cluster Zeta — toutes les machines

Hostname Matériel CPU RAM Réseau Rôle
zeta-lab Machine principale Intel Core i7-7500U · 2 cœurs / 4 threads 16 GB + 16 GB swap WiFi Calcul + orchestration
zeta-calc-second HP Compaq 8000 Elite CMT · CM HP 3647h Core2Duo E8400 3 GHz 4 GB DDR3 Gigabit ETH Nœud calcul auxiliaire
zeta-backup Compaq-Presario SG3210FR · CM ECS Livermore8 AMD Athlon II X2 215 2.7 GHz 3 GB DDR2 100 Mbit ETH · Ubuntu 16.04.7 i686 (32 bits, fin de support) Relais backup → ProtonDrive
zeta-secure Compaq CQ58 Notebook PC — bastion VPN/pare-feu Celeron B830 · 2C · 1.8 GHz 4 GB ETH · OpenBSD 7.9 amd64 Point d'entrée VPN externe ✅
zeta-monitor Compaq CQ57 Notebook PC AMD série E (k10temp) 2 GB Debian 12 Monitoring (lm-sensors)

Renommage effectué le 2026-06-13 : hp3647h → zeta-hp3647h · pcfix2 → zeta-livermore8. PC4 zeta-secure ajouté le 2026-06-15 — bastion WireGuard IPv6, accessible depuis 4G. Renommage 2026-06-16 : zeta-hp3647h → zeta-calc-second · zeta-livermore8 → zeta-backup · zeta-del.local → zeta-secure (PC4). Préfixe zeta- uniforme sur tout le cluster. PC5 zeta-monitor ajouté le 20/09/2026 — nœud monitoring, joignable via bastion comme PC2/PC3. Accès externe : DDNS dédié sur le bastion (AAAA — CGNAT IPv4 sur la box SFR, adresse non divulguée ici). ⚠️ VPN tiers (Proton VPN) incompatible avec l'accès distant : bloque l'IPv6 nécessaire au tunnel WireGuard côté client. Toujours couper Proton avant de joindre le cluster en déplacement — détail : Guide-WireGuard-Acces-Distant. Migration matérielle 2026-08-16 : Dell Dimension 4500 → Compaq CQ58 (2 crashes matériels isolés le même jour) — même hostname/IP/rôle, détail complet : Migration-PC4-Compaq-CQ58-20260816.md. Doc complète : Architecture-Cluster-Zeta.md §10-15.

Ratio de vitesse PC1/PC2 (mesuré 02/08/2026, v15 T=1000)

Machine Vitesse mesurée Split N(T) appliqué
zeta-lab (PC1) 822,48 z/s 67,4 %
zeta-calc-second (PC2) 512,19 z/s 32,6 %

Ratio réel ×1,6 — remplace un ratio ×12 historiquement supposé (52 z/s mesurés sans python-flint, alors absent de PC2). python-flint 0.8.0 s'est révélé installé sur PC2 lors de la resynchronisation du 02/08 : remesuré dans les mêmes conditions que PC1, l'écart réel est bien plus faible qu'estimé. V_PC1_DEFAULT/V_PC2_DEFAULT dans scripts/zeta_distribute.py reflètent ces valeurs.

⚠️ PC2 identifié comme goulot d'étranglement probable en usage réel (run T=5M v15, 04-05/08/2026) : double pénalité — seulement 2 cœurs physiques pour 8 workers (oversubscription ×4, contre 4 cœurs dédiés sur PC1) et segment assigné sur la zone à t la plus élevée du run ([3,47M–5M]), où le coût de scan par point croît avec t (plus de termes Riemann-Siegel nécessaires). Le ratio z/s ci-dessus a été mesuré sur un petit intervalle bas-t (T=1000) — il ne capture pas ce second effet. À reconsidérer avant un prochain run à grande échelle : soit rééquilibrer le split en défaveur de PC2, soit réduire son nombre de workers pour limiter l'oversubscription. Détail → JOURNAL.md 04-05/08/2026.

🔧 Infrastructure backup

Pipeline nocturne (automatique)

Étape Machine source Heure Destination Commande
1 — rsync local→Acer zeta-lab (cron 01h50) 01h50 pjexosql@zeta-backup:~/backup/ rsync -aq -e 'ssh -i <clé SSH dédiée>' logs/ wiki/ pdf/
2 — rclone Acer→cloud zeta-backup (cron 02h00) 02h00 protondrive:hprzeta/Riemann_Lab/backup/ ~/bin/rclone copy ~/backup/ (v1.73.5)
3 — hors git → Proton zeta-lab (cron 02h30) 02h30 protondrive:hprzeta/Riemann_Lab/hors_git/ scripts/zeta_backup_horsgit.sh --auto (jeux sans secrets ; seulement si PC1 est allumé)
  • Clé SSH dédiée (ed25519, sans passphrase, nom non divulgué ici) — connexion automatique zeta-lab → zeta-backup
  • Répertoires sauvegardés : logs/ · wiki/ · pdf/
  • Log rclone : ~/rclone_cron.log (hors de ~/backup/ depuis le 16/08/2026 — voir ci-dessous)
  • Le rsync de 01h50 ne tourne que les nuits où PC1 est allumé ; « aucun fichier » dans zeta-backup-status veut dire « rien de nouveau à copier », pas forcément une panne.

✅ Fiabilité — étape 2 (rclone→cloud) CORRIGÉE le 16/08/2026 (2 causes, jamais fonctionné depuis le 15/06/2026). zeta_backup_status.py avait mesuré 7/7 jours en échec récents ; investigation complète a remonté tout l'historique du log (~/backup/rclone_cron.log, 56 628 lignes) et montré 0 succès depuis le tout premier run (15/06/2026) — pas juste un problème récent. Cause n°1 (chronique, 100% des runs) : rclone_cron.log était écrit à l'intérieur du dossier copié (~/backup/rclone_cron.log), donc rclone tentait de copier ce fichier pendant qu'il grossissait → Failed to copy: can't copy - source file is being updated à chaque run, qui laissait un upload « draft » orphelin côté Proton Drive, provoquant en cascade des 422 fichier existe déjà (556 occurrences en 2 mois) et a draft exist (124 occurrences). Corrigé : log déplacé vers ~/rclone_cron.log, hors du périmètre sauvegardé. Cause n°2 (intermittente, ~1 run sur 3, 38 occurrences en 2 mois) : fatal error: found bad pointer in Go heap — bug mémoire du runtime Go, rclone v1.74.3 était compilé avec go1.26.x dont le nouveau Green Tea GC (expérimental, devenu défaut en Go 1.26, GOEXPERIMENT = flag de compilation, pas désactivable au runtime) — connu pour des instabilités sur architectures 32 bits (386), exactement le cas de PC3 (i686). Corrigé : downgrade vers rclone v1.73.5 (dernier correctif encore sur go1.25.9, avant le changement de GC par défaut), installé dans ~/bin/rclone (permissions utilisateur seules, pas de sudo nécessaire — /usr/bin/rclone système resté intact). Testé manuellement en conditions réelles : 2 runs consécutifs, rc=0, 0 erreur, 2ᵉ run nothing to transfer (1749/1749 checks OK). Confirmation définitive attendue au prochain déclenchement cron automatique (17/08 02h00). Détail complet → JOURNAL.md 16/08/2026, commit code 65e64f4.

Scripts & diagrammes

Fichier Commit Rôle
scripts/backup_cluster_map.sh cd11a5f Génère les 2 SVGs ci-dessous
docs/images/backup_cluster_map.svg cd11a5f Diagramme du pipeline backup (rsync + rclone)
docs/images/topo_machines_zeta.svg cd11a5f Topologie matérielle du cluster Zeta
docs/backup_cluster_map.svg c33fb3a Copie racine docs/
docs/topo_machines_zeta.svg c33fb3a Copie racine docs/
scripts/zeta_backup_status.py (05/08/2026) — Statut quotidien du pipeline (rsync + rclone) — alias zeta-backup-status ; --date AAAA-MM-JJ

🤖 Stack « Second Cerveau IA »

LLM locaux (Ollama)

Modèle Taille Statut Rôle
mathstral:latest 4.1 GB ✅ Maths + ζ(s) symbolique
deepseek-coder:6.7b 3.8 GB ✅ Code Python/C
qwen3:4b ~2.5 GB ✅ Polyvalent rapide
deepseek-math:7b ~3.8 GB 🔜 Meilleur raisonnement math pur
phi3:mini ~2.3 GB 🔜 Ultra-léger 
ollama pull deepseek-math:7b
ollama pull phi3:mini

LLM en ligne (navigateur)

Outil Modèle Usage
Claude Sonnet 4.5 Cerveau de session — mémoire, structure, maths longues, wiki
Copilot ⭐ GPT-4.5 Cadrage Phase C, génération PDF + prompts voie B/v5
Perplexity — Recherche web + arXiv
Kimi — Lecture longs PDF (Titchmarsh, Odlyzko)
DeepSeek — Raisonnement math alternatif

Skills Claude

Skill Statut Rôle
riemann-lab ✅ Mémoire projet — KaTeX, wiki, Python, Git
phase-c-illinois ✅ Phase C — libmpfr, Illinois C, ctypes
riemann-code-review ✅ Audit code Python/C
riemann-security-review ✅ Vérif sécurité scripts et .so
mattpocock/skills 🔜 (Obj. 2) Skills communautaires généralistes

Audit 3 emplacements (06/07/2026) : global ~/.claude/skills/, repo tracké .claude/skills/, skills_export/. 2 désync réelles trouvées et corrigées — riemann-lab/references/*.md figées au commit initial, phase-c-illinois ayant divergé en deux lignées (v6/v7/v8 vs v9/v12-v15) depuis le 11/06. riemann-code-review et riemann-security-review : RAS, identiques partout. Détail → JOURNAL.md 06/07/2026.

MCP · RAG · Tools

Outil Statut Rôle
Context7 (MCP) 🔜 Doc à jour (mpmath, numpy, libmpfr) injectée dans Claude
LlamaIndex ✅ en service RAG — ingestion PDFs + wiki + prompts (scripts/rag_ingest_corpus.py)
ChromaDB ✅ en service Collection riemann_lab_corpus — 1258 chunks (réingestion du 04/10/2026 ; 838 avant) — /mnt/vault_rag/chromadb
sentence-transformers ✅ en service all-MiniLM-L6-v2 — mêmes modèle ingestion/requête obligatoire
Ollama (contexte) ✅ Fenêtre 4096 tokens (valeur par défaut) : au-delà, le prompt est tronqué — d'où --k 4
scripts/rag_query.py ✅ (04/10/2026) --k 4 par défaut ; avertit si le prompt estimé dépasse 4096 ; garde de citation (valeurs_non_ancrees, est_un_refus)
scripts/rag_ingest_corpus.py ✅ v2.1 (04/10/2026) --reset, garde de montage, embedding forcé sur CPU (GTX 960M non gérée par torch 2.11)
scripts/zeta_rag.sh (zeta-rag) ✅ (03/10/2026) Menu SSD vault_rag + RAG : état, montage, question, surveillance, ingestion, sauvegarde
scripts/rag_monitor.py ✅ (05/07/2026) Surveillance vault : montage, tailles, collections, --test-query (latence HNSW 0.091 s)
Guide-RAG-BrainVault-Debutant ✅ (05/07/2026) Guide débutant MD (wiki) + PDF (pdf/optimisation/ + ProtonDrive cours/)
Manim 🔜 Animations math (style 3Blue1Brown)
Flowise 🔜 (fin Obj. 1) Second Cerveau visuel low-code
n8n / Activepieces 🔜 (Obj. 2) Automatisation GitHub → mail → publication
LangChain / LM Studio 🔜 (Obj. 2) Framework agent complet

Vault RAG : SSD Micron 1100 256 Go dédié, monté sur /mnt/vault_rag (mis en service 22/06/2026). Garde obligatoire avant écriture : vérifier le montage (mountpoint) — sinon écriture silencieuse sur le disque système (leçon 05/07/2026, voir rag_monitor.py).

pip install manim llama-index chromadb sentence-transformers
npx flowise start   # http://localhost:3000

📋 Roadmap

Objectif 1 — finalisation (10 000 zéros → 100 000 zéros)

  • Run compute_zeros_v4_1 à T=10 000 — 10 141 zéros, Turing COMPLET, 18.65 z/s ✅
  • Comparer aux tables LMFDB — 19/20 précision ≤ 1e-10 ✅
  • Visualisations dans /docs — 8 animations HTML + index.html, validées Playwright ✅
  • Logo PNG statique docs/images/logo_riemann_lab.png — README + wiki Home.md, 4 branches ✅
  • Run T=100 000 — 138 069 zéros, Turing COMPLET, 30.9 min, 74.49 z/s (v7) ✅
  • Site GitHub Pages mis à jour v6+v7 — commit 9dc0d23, vérifié 11 juin 2026 ✅
  • Benchmark v8 — prec_fast/prec_full + W=4 vs W=8 → plancher hardware i7 atteint ✅
  • Fix lien PDF cassé dans Phase-Optimisation-compute_zeros_v3.md + git push origin master. ✅ corrigé (raw.githubusercontent.com)
  • v9 Brent C/mpfr : 26.6 min (turbo) · ×1.80 vs v8 ✅
  • v10 W=8 forcé : 23.7 min · ×5040 vs v1 ✅
  • v12 : Illinois hybride 2-phases (illinois_arb.c) — 8.8 min T=100k · 0 manquant · Turing COMPLET ✅
  • v13 + rescan ciblé par déficit — Section 3b rescan_segments_deficit(), STEP/2 parallèle — validé T=1000 ✅ — commit 77efd10
  • Run T=5 000 000 terminé (04/07/2026, PC1 turbo, ~38h) — 10 016 377 / 10 016 473 zéros · 96 manquants · cause : fragilité RS à bas $t$ ($N$ petit / reste $R(t)$ ), PAS des paires enjambées (M₁≈0,08, réfuté par test A/B le 06/09/2026 — voir JOURNAL et Formules_zeta §33)
  • v14 — Cache RS statique log_n/isqrt_n — gain ×1.10 · T=100k 7.7 min · commit d4b3611 ✅
  • v15 — Phase 2 adaptative SEUIL_1NEWTON=20k — gain ×1.93 vs v13 · T=100k 4.4 min · Condition Obj2 atteinte ✅ · commit adf5d2a
  • v16 — Z_arb à précision fixe (acb_dirichlet_hardy_z, 64 bits) — gain ×2.75 vs v15 · T=100k 1.6 min · LMFDB 20/20 · Turing COMPLET · commit 00abe5c (08/08/2026)
  • Wiki — Partie 2 (Z(t), zéros non-triviaux).
  • Rapport analyse_problemes_v13_v15.md + PDF dans pdf/optimisation/ — confirmés existants (vérifié 09/08/2026, réutilisés dans la colonne Analyse du site)
  • Site public — colonnes « Formule principale » et « Analyse » sur le tableau v1→v16 (09/08/2026) : 15 liens vers sections Formules_zeta/Bibliotheques (ancres vérifiées en direct, comparées aux href="#..." réels GitHub) + 11 liens vers les rapports analyse_problemes_vN_vN+1, 100% en PDF public (pdf/optimisation/) — analyse_problemes_v7_v8.pdf généré depuis le wiki (scripts/build_pdf_riemann_CM.sh), plus aucune exception wiki. 26 liens testés individuellement (HTTP 200, ancres/%PDF/taille exacte confirmés) ✅
  • Tableau v1→v16 du site — ligne v6 ajoutée + correction v8 (09/08/2026) : vérification des colonnes Algorithme clé/Gain/Temps/Ver. contre ce fichier — v8 corrigé (« 116→80 bits » au lieu de « 64→80 », gain « ×1.06 vs v7 » restauré) ; ligne v6 manquante ajoutée (130 min, 0 manquant, commit b676e88 — voir table T=100k ci-dessous) car déjà référencée par la ligne v7 (« ×4.2 vs v6 ») sans exister elle-même. Tableau du site : 15 lignes ✅
  • 2 doublons PDF orphelins (docs/pdf/analyse_v6_v7.pdf, analyse_v8_v9.pdf) — identiques (MD5) à des fichiers déjà corrects dans pdf/optimisation/, supprimés (doublon manqué au recensement initial du Chantier 1, 09/08/2026)

Phase C — accélération Illinois

  • Appliquer + valider Option B (illinois_refine fa/fb depuis Python) — T=10 000 ✅
  • Instrumentation brackets ZETA_DEBUG_BRACKETS — commits 7914fa3 + 2b94b9f ✅
  • Rescan ciblé par déficit rescan_segments_deficit() dans v13 — validé T=1000 ✅
  • v14 — Cache RS statique (illinois_arb.c + scan_arb.c) — Phase 1 accélérée · 7.7 min T=100k ✅
    • log_n_cache[2101] + isqrt_n_cache[2101] · 33 KB · init post-fork · couverture T≲27M
    • Condition Obj2 : T=100k < 5 min. Écart résiduel v14 : 7.7 → 5 min.
  • v15 — Phase 2 adaptative SEUIL_1NEWTON=20 000 — #define SEUIL_1NEWTON 20000.0 ✅
    • biais_RS(20k) ≈ 6.4e-7 → erreur 1 Newton ≈ 4e-13 < tol · 87% des zéros T=100k bénéficient
    • Condition Obj2 atteinte le 2026-07-04 : T=100k = 4.4 min < 5 min ✅
  • v16 — Z_arb à précision fixe (acb_dirichlet_hardy_z, 64 bits, sans escalade) ✅
    • arb_fpwrap_cdouble_hardy_z(flags=0) escalade en interne 64→8192 bits visant ~1e-16 (confirmé depuis le code source FLINT 3.3.1) — surdimensionné vs tol=1e-12 (~40 bits)
    • Headers FLINT 3.3.1 vendorisés en source (c_modules/flint-headers-3.3.1/) — apt libflint-dev = 3.0.1, ABI incompatible (dirichlet_group_t/dirichlet_char_t)
    • Validé run réel T=10000 (prototype isolé) puis T=100000 (intégré) avant adoption — Turing COMPLET + LMFDB 20/20 aux deux échelles
    • T=100k : 4.4 → 1.6 min (×2.75) · T=10000 : 20.2 → 10.2s (×1.98)
  • v17 — Odlyzko-Schönhage (long terme) — O(N log²N) vs O(N × √T) → gain ×50+ à T=5M
  • Rapport analyse_problemes_v13_v15.md + PDF — confirmés existants (09/08/2026)
  • Diagnostic 96 manquants T=5M — clos le 06/09/2026 : cause = fragilité RS à bas $t$ (voir note corrigée dans le tableau « Progression T=5M » ci-dessus). Reste ouvert si repris : test discriminant canal $N$ vs canal $R(t)$ (léger, non exécuté), v17 (long terme).
  • Suites proposées par l'audit lecture seule du 12-13/09/2026 (rapports/audit_reco_IA_2026-09-12.md, dépôt de code, non commité, en attente de validation hprzeta) :
    • R4 — journal de calibration par run (exposer MARGE_SECURITE, absente du log v16 malgré un log déjà riche)
    • Corriger la doc MARGE_SECURITE=3.0 → investigation git blame du 12-13/09/2026 terminée (rapports/marge_securite_et_precision_2026-09-12.md, non commité) : 10.0 est la seule valeur avec une trace de validation empirique (commits bbb8a6f→00abe5c), 3.0 a été testée et explicitement trouvée insuffisante (a04ea1f, T≈4,86M) — ce n'est plus seulement une valeur active vs documentée, c'est une croyance contredite par l'historique git. Reste à faire : corriger le texte du CLAUDE.md racine + Recommandations_LAB_et_prompt.md + Formation_Zeta_HR_Riemann_ Lab.pdf (aucun de ces 3 documents modifié — hors périmètre lecture seule).
    • R1 — script de validation échantillonnée de l'équation fonctionnelle (branche Γ/θ, dps=30, N points — pas de colonne CSV massive)
    • Gate empirique T=100k (MARGE=10.0 vs valeur alternative) pour objectiver le surcoût réel avant tout rerun T=5M — proposé par l'investigation du 12-13/09, pas encore lancé
    • R2+R8 — rerun T=5M avec Turing complet + rapport de recoupement des 96 manquants historiques (systemd-inhibit déjà en place, rien à ajouter sur ce point)
    • Nettoyer T_SEUIL_ILLINOIS_C=300 (CLAUDE.md racine, obsolète depuis v12) et le git add -A résiduel dans scripts/push_phase0_complete.sh:36
  • Rapport v5 → v4.1 : pdf/optimisation/analyse_problemes_v5_v4_1.pdf.

Objectif 2 — agent IA autonome (DÉMARRAGE — condition Obj1 atteinte le 04/07/2026)

  • Condition préalable : T=100k < 5 min — atteinte le 04/07/2026 avec v15 (4.4 min), améliorée le 08/08/2026 avec v16 (1.6 min) ✅
  • Anthropic Skilljar : Claude Code 101 → MCP intro/avancé → Subagents → Agent Skills.
  • MCP → connexion GitHub / wiki.
  • Agent capable de : publier sur hprzeta.github.io/Riemann_Lab/, générer les rapports v→v+1, envoyer les résultats à hprzeta@protonmail.com, collaborer avec des IA universitaires.
  • RAG vault (/mnt/vault_rag) : ChromaDB + LlamaIndex — 838 chunks ingérés, rag_monitor.py (surveillance) + guide débutant publiés (05/07/2026) ✅
  • Industrialiser la boucle RAG (script réutilisable retrieval + génération)
  • Résoudre le retrieval imparfait (chunk pertinent pas toujours en top-5 — voir JOURNAL.md 05/07)
  • Investigation 96 manquants T=5M — diagnostic clos 06/09/2026, voir Objectif 1 ci-dessus.

Formation

Ressource Usage
roadmap.sh Roadmaps Python, IA, agents
build-your-own-x Implémenter RAG / agent / LLM from scratch
Anthropic Skilljar Parcours Claude Code → MCP → Subagents

📚 PDF de cadrage et cours (Voie B5)

PDF Thème Message clé
01 Cartographie diagnostic Conserver l'historique, ne pas repartir de zéro
02 Migration / Brain Vault / RAG Structure, recovery, données validées
03 Checklist Linux Git, GPU, Python, Ollama, partitions
04 Scripts post-audit Extraction archive, mini-audit Git
05 Complément Git Branches confirmées, Riemann_Lab_C = c_modules
06 Lexique IA & Brain Vault Vault, RAG, Skills, agents, grounding
07 Pavé primalité Premiers, produit eulérien, ψ(x), formule explicite
08 CryptoZeta RSA, ECC, post-quantique, hash, recovery
09 Synthèse Phase C v4 voie B v4 hybride validé T=650
10 Résumé + prompt v5 Passerelle → Claude Code voie B/v5

🔗 Références

Ressource Lien
Site du projet https://hprzeta.github.io/Riemann_Lab/
Code source https://github.com/hprzeta/Riemann_Lab/tree/Riemann_Lab_IA/src
LMFDB https://lmfdb.org/zeros/zeta/
Odlyzko & Schönhage 1988 https://doi.org/10.1090/S0002-9947-1988-0936813-0
Turing 1953 https://doi.org/10.1112/plms/s3-3.1.99
Titchmarsh — Theory of ζ (§4.12) https://archive.org/details/theoryofriemann00titc

Progression des versions — T = 10 000 zéros

Version Temps Gain vs v1 Algorithme clé Formule principale
v1 21h — Newton scalar $\zeta(\frac{1}{2}+it)$ Newton séquentiel, 1 worker
v2 2h ×10 Illinois + Z(t) $Z(t) = e^{i\theta(t)}\zeta(\frac{1}{2}+it)$ · bracket Illinois
v3 45min ×28 Parallèle W=4 T/W par worker · post-fork .so · N(T) corrigé
v4.1 9min ×140 Illinois C/libmpfr illinois_mpfr.c · $(f_a, f_b)$ pré-calculés Python→C
v4.1+Arb 2.60 min ×484 Arb + STEP adaptatif Arb ×27 · STEP 0.05/0.010 · overlap=2.0 · Turing COMPLET

×484 = 21h / 2.60 min — mesuré T=10 000 (2026-06-10 · commit 50837f7). STEP adaptatif v3 (commit 181fdd1) : 0.05 (t<5k) / 0.010 (t≥5k) + overlap fixe 2.0.

Speedup Arb vs mpmath : ×27 (0.77 ms vs 21.13 ms, mesuré benchmark_arb_vs_mpmath_20260609)

Progression des versions — T = 100 000 zéros

Version Temps Gain Zéros Algorithme clé Commit
v1 (STEP=0.1 fixe) ~1h58 — 137 904 baseline —
v2 (STEP adaptatif 0.1/0.05/0.02) ~105 min — 138 039 Turing INCOMPLET ❌ —
v3 (STEP adaptatif 0.05/0.010) ~113 min — 138 069 scan_arb.c Z_double 181fdd1
v6 (STEP=0.010 fixe ⚠️ VESTIGE, scan_arb.c) ~130 min — 138 069 Z_double C inline · 0 manquant ✅ b676e88
v7 (illinois_refine_adaptive) 30.9 min ×4.2 vs v6 138 069 prec=64 bits → 1 limb → SIMD ×16 8637098
v8 (prec_full=80 bits) 50.5 min* ×1.06 vs v7 138 069 prec_full 116→80 bits —
v9 (Brent C/mpfr) 26.6 min (turbo) · 28.0 min (sans) ×1.80 vs v8 138 069 Brent IQI+sécante+bissection (ordre ~1.84) 1c8c0ab
v10 (W=8 forcé) 23.7 min (turbo) ×1.12 vs v9 138 069 W=8 forcé — Brent grand t dilue overhead HT c9fad76
v12 (Illinois hybride 2-phases) 8.8 min (turbo) ✅ mesuré ×2.69 vs v10 · ×16.9 benchmark ~138 080 Z_rs_double Phase 1 (0.015 ms) + 2 Newton Z_arb Phase 2 f0e8430
v13 PC1 seul 8.50 min ✅ ×1.04 vs v12 138 069 T_SEUIL_PETIT_T 200→65 · TOL_ARB 1e-9→1e-12 · scan_arb C 77efd10
v13 distribué PC1+PC2 8.50 min mur ✅ ×148 vs v1 138 069 zeta_distribute.py · pivot N(T) marge −15% · Turing COMPLET 98de98e
v14 (cache log_n/isqrt_n) 7.7 min ✅ ×1.10 vs v13 138 069 Cache RS statique 33 KB · init post-fork · Phase 2 inchangée (2 Newton early-exit) d4b3611
v15 (SEUIL_1NEWTON=20k) 4.4 min ✅ ×1.93 vs v13 · ×286 vs v1 138 069 Phase 2 adaptative : 1 Newton si t≥20k (87% des zéros T=100k) · LMFDB 20/20 adf5d2a
v16 (Z_arb précision fixe 64 bits) ⭐ 1.6 min ✅ ×2.75 vs v15 · ×787.5 vs v1 138 069 acb_dirichlet_hardy_z fixe 64 bits (vs arb_fpwrap escalade ~1e-16) · LMFDB 20/20 · Turing COMPLET 00abe5c

v9 : gain turbo ×1.05 seulement — bottleneck MPFR/mémoire (vs ×1.63 pour v7). Swappiness déjà à 10 lors du run sans turbo. v10 : W=8 forcé sur i7-7500U (2 cœurs physiques, 4 logiques). Gain ×1.12 > ×0.99 benchmark v8 — car Brent grand t (~64 ms/appel) dilue l'overhead HT du context-switch.

⚠️ STEP=0,010 (lignes v3/v6 ci-dessus) est un vestige d'un pipeline abandonné le 17/06/2026 — ce n'est PAS une règle active. Le STEP réel, depuis v7, est adaptatif : $$\text{STEP}(T_{\max}) = \frac{\kappa \cdot \delta_{\text{moyen}}(T_{\max}) \cdot N(T_{\max})^{-1/3}}{\text{MARGE-SECURITE}}$$ calculé une seule fois sur le $T_{\max}$ global du run, puis appliqué uniformément de $T_{\min}$ à $T_{\max}$ — y compris aux segments de bas $t$, où l'espacement réel entre zéros est bien plus large qu'à $T_{\max}$. Conséquence mesurée : à $t=14$, la grille compte ~17 fois plus de points par zéro qu'à $t=5\times10^6$ (voir Formules_zeta §32). Ce n'est pas un défaut caché : c'est le prix du calibrage sur le pire cas. v16 : gain mesuré à deux échelles — ×1.98 à T=10000 (20.2→10.2s), ×2.75 à T=100000 (4.4→1.6 min). La phase Illinois pèse une part croissante du temps mur à mesure que T augmente, d'où un gain supérieur à T=100k. Voir Handoff.md/JOURNAL.md wiki, entrée 08/08/2026, pour le détail complet (mécanisme arb_fpwrap, comparaison MPFR pur écartée, validation run réel avant intégration).

Gain global v1 → v9 mesuré sans turbo : ×45 (21h → 28 min) Gain global v1 → v9 avec turbo : ×47.4 (21h → 26.6 min) Gain global v1 → v10 avec turbo : ×53.2 (21h → 23.7 min) Gain global v1 → v13 distribué PC1+PC2 : ×148 (21h → 8.5 min mur) Gain global v1 → v15 (PC1 local) : ×286 (21h → 4.4 min) — Condition Objectif 2 atteinte le 2026-07-04 Gain global v1 → v16 (PC1 local) : ×787.5 (21h → 1.6 min) — Condition Objectif 2 largement dépassée ✅ le 2026-08-08

⚠️ Correction 06/09/2026 : les valeurs précédentes (×4 300 à ×78 650+) étaient erronées d'un facteur ~100 (erreur de calcul, jamais ×N réel). Valeurs ci-dessus recalculées directement à partir des temps mesurés (21h / X min).

Progression — T = 5 000 000 zéros

Version Temps Zéros Statut Note
v13 PC1 local + rescan ciblé — TERMINÉ ~38h réel (lancé 27/06 16h02 → terminé ~04/07) 10 016 377 / 10 016 473 96 manquants — run terminé STEP=0.001571 · 8 workers · turbo · N_RS=892 termes Arb

⚠️ Correction 06/09/2026 : l'explication ci-dessus (« paires de zéros enjambées par la grille ») est invalidée (test A/B + triple expertise mathématique — $M_1\approx0{,}08$ zéro attendu contre 96-177 observés, écart de 3 ordres de grandeur, mauvaise localisation prédite). Cause retenue : fragilité de la formule de Riemann-Siegel tronquée à bas $t$ ($N=\lfloor\sqrt{t/2\pi}\rfloor$ petit → erreur relative énorme sur la somme tronquée), non-menace pour l'HR (zéros non détectés par une limite numérique, pas des contre-exemples). Chantier diagnostic clos. Détail : JOURNAL.md 2026-09-06, Formules_zeta.md §33. Reste ouvert si repris : test discriminant canal $N$ vs canal $R(t)$ (léger, non exécuté) et v17 (long terme).

Audit lecture seule 12-13/09/2026 (rapports/audit_reco_IA_2026-09-12.md, dépôt de code, non commité) : confirme que le pipeline production (v16) n'a jamais dépendu d'une mauvaise valeur de MARGE_SECURITE pour ce déficit précis (cause ci-dessus, indépendante de ce paramètre) — mais relève que MARGE_SECURITE=3.0 reste documenté comme « calibration validée » dans le CLAUDE.md racine et 2 documents externes (Recommandations_LAB_et_prompt.md, Formation_Zeta_HR_Riemann_Lab.pdf) alors que la valeur réellement active dans le code (v15 et v16) est 10.0.

Investigation sémantique + git blame 12-13/09/2026 (rapports/marge_securite_et_precision_2026-09-12.md, dépôt de code, non commité, mode lecture seule, verrou moteur respecté) : ce n'est plus seulement une dette de documentation — l'historique git lui-même contredit « 3.0 = validé ». MARGE_SECURITE divise l'estimation du plus petit écart attendu entre zéros pour fixer STEP (le pas de la grille de détection de signe de $Z(t)$) — une marge trop petite fait tomber deux zéros proches dans le même pas et les fait s'annuler silencieusement (mécanisme confirmé comme cause des 96 manquants à MARGE=2.0). Chaîne git blame reconstituée :

Commit Date MARGE_SECURITE Résultat connu
a0e6e41 04/07 2.0 96 manquants T=5M
a7fb498 02/08 → 3.0 restauration, jamais validée à grande échelle
a04ea1f 02/08 → 15.0 3.0 testé et confirmé insuffisant à T≈4,86M
bbb8a6f 02/08 → 10.0 0 manquant sur 3 zones + pivot réel PC1+PC2
00abe5c 08/08 (v16 prod) 10.0 (déjà actif) T=100k Turing COMPLET, LMFDB 20/20

MARGE_SECURITE=10.0 est la seule valeur avec une trace de validation empirique (isolée ET en configuration distribuée réelle) ; 3.0 a été testée spécifiquement et trouvée insuffisante, pas seulement remplacée. Un dédoublonnage existant (tolérance 0.01, parallel_scanner.py:148-166) absorbe sans risque documenté le coût d'une marge plus grande. Reste à faire, volontairement non tranché ici : un gate empirique T=100k pour objectiver le surcoût réel de 10.0 avant tout rerun T=5M (prompt séparé, pas encore lancé). R6 (même investigation) documente aussi la précision Arb fixe 64 bits (indépendante de $t$) avec un écart max mesuré de 1,455e-11 au pire point en production (t=10⁵) — deux ordres de grandeur sous le seuil de dédoublonnage, aucune recalibration effectuée.

Progression — T = 500 000 zéros

Version Temps Zéros Statut Commit
v13 distribué PC1+PC2 — run #4 (RÉFÉRENCE OFFICIELLE) 35.36 min mur 818 409 / 818 414 (99,9994 %) Turing INCOMPLET (5 manquants) — accepté comme limitation connue 8f755eb
v13 distribué + OVERLAP_PIVOT=2.0 seul (Option A) — run #5 41.55 min mur 818 406 / 818 414 ❌ 8 manquants — pire non commité
v13 distribué + overlap (A) + MARGE_SECURITE=3.0 — run #6 45.34 min mur 818 408 / 818 414 ❌ 6 manquants — toujours pire non commité
v13 distribué Option B (frontières originales + supplément pivot séparé) + MARGE×3 — run #7 43.36 min mur 818 405 / 818 414 ❌ 9 manquants — pire que tout non commité

24/06 — 4 tentatives de levée des 5 manquants, aucune n'a fait mieux que le run #4. Diagnostic après-midi du 23/06 (3 méthodes post-hoc) épuisé sans résultat ; relecture Formules_zeta.md/Bibliotheques.md + skill riemann-code-review a fait remonter le trou de couverture structurel au pivot PC1/PC2 (zeta_distribute.py sans overlap, run #5) et une marge STEP « quasi-échec ×1,28 » documentée dans le code lui-même. 2 jeux de frontières (originales / décalées par l'overlap) × 2 marges (2.0 / 3.0) testés — aucune combinaison ne bat les 5 manquants du run #4 :

Run Frontières workers MARGE_SECURITE Manquants
#4 originales 2.0 5
#5 décalées (Option A) 2.0 8
#6 décalées (Option A) 3.0 6
#7 originales (Option B) 3.0 9

Conclusion : STEP/MARGE_SECURITE n'est pas un paramètre monotone — chaque valeur définit une grille d'échantillonnage différente, et la phase exacte de cette grille compte au moins autant que la taille nominale de la marge. Continuer à tâtonner cette valeur à l'aveugle n'a pas de garantie de convergence. Décision (hprzeta, 24/06) : arrêt du tâtonnement. Le run #4 reste la référence officielle. Prochaine piste, si reprise un jour : instrumenter scan_arb.c/illinois_refine_arb pour logger directement les brackets rejetés lors d'un run réel, plutôt que deviner via STEP. Détail complet : JOURNAL.md sessions 23/06 (soir) et 24/06.

Historique (ancien diagnostic, après-midi 23/06) : 3 méthodes de localisation post-hoc sur le run #4 (analyse statistique des écarts, scan à phase de grille décalée, bisection N_exact) — toutes négatives ou faux positifs sur les 5 manquants d'alors.

Infrastructure — monitoring Zêta (monitoring/, installé le 16/10/2026)

Élément Commit État Note
monitoring/scripts/ (logger, watcher, rapport, graphiques) — (non suivi) ✅ 5 machines répondent (--test 16/10) · ⚠️ jamais vu sur un vrai run 1 mesure/s → data/cluster_metrics_AAAAMMJJ.csv ; rapport auto dans runs/<id>/
monitoring/zeta_monitoring_alias.sh — (non suivi) ✅ chargé par ~/.bashrc fonctions zeta-mon-on/off/status, zeta-run-hint, zeta-live, zeta-metrics, zeta-gue, zeta-report, zeta-index, zeta-runs
monitoring/README.md 2de45af ✅ menu zeta-script + procédure avant / pendant / après un run
scripts/zeta_script.py 2de45af ✅ testé (n° 39) lit aussi les fonctions du monitoring (n° 37-46)

Test sur un run court prévu le 17/10 ; le rapport ne remplace pas la validation Turing–Backlund. Détail : JOURNAL entrée 2026-10-16 (22h30).

Infrastructure — zeta_turbo (cycle de vie PAR SESSION depuis le 16/10/2026)

Script Commit État Note
zeta_turbo_on.sh 1a9ad0c ✅ réécrit 16/10, testé sur système factice (34 tests) · jamais activé en réel idempotent, état /run/zeta_turbo/state, --services · sudoers /etc/sudoers.d/zeta_turbo (2026-06-12) pointe sur le dépôt : à durcir (copies root /usr/local/sbin) · gain mesuré : 26.6 min T=100k
zeta_turbo_off.sh 1a9ad0c ✅ réécrit 16/10 (idem) restauration exacte vérifiée (gouverneur+EPP par CPU, swappiness, services), --force-defaults en secours
zeta_turbo_status.sh 1a9ad0c ✅ nouveau lecture seule : ACTIF/INACTIF/DERIVE/INVALIDE
zeta_session_turbo.sh 1a9ad0c ✅ nouveau start (hook SessionStart) / end (étape 0 du « bye bye ») ; journal logs/turbo_session.log
zeta_run.sh 33205f2 ✅ mis à jour pointe sur compute_zeros_v12.py depuis 2026-06-13 (était v4_1)
zeta_run.sh (turbo) 1a9ad0c ✅ 16/10 arrête les services pendant le run seulement ; le turbo CPU reste actif jusqu'au « bye bye »
zeta_sync_pc2.sh 23a79b7 ⚠️ créé, non testé rsync sources Python+C vers PC2 + recompile scan_arb.so/illinois_mpfr.so/illinois_arb.so (détection auto libflint-arb système via ldconfig) — à valider, PC2 injoignable le 23/06

Découverte v7 : réduire $N_\text{termes}/4$ invalide les signes Z_rs (faux zéros). Le vrai levier : prec_fast = 64 bits → 1 limbe mpfr → SIMD AVX2 automatique. Gain ×16 local (phase 1), ×3.7 global. Analyse : analyse_problemes_v6_v7.md.

Benchmark v8 : prec_full=80 bits → ×1.06 (gain marginal). W=8 contre-productif sur i7-7500U (dual-core HT, 4 threads logiques). Plancher hardware atteint. Voir §24 Formules_zeta.md.

v9 Brent : gain ×1.78 sur benchmark [1000,50000], +3% seulement sur T=10k (faible t → N_full petit). Gain T=100k attendu supérieur (majorité des zéros à grand t → N_full élevé). Analyse : analyse_problemes_v8_v9.md.

Run T=10 000 v4.1+Arb validé : 10 141/10 142 zéros · 2.60 min · Turing COMPLET · LMFDB 19/20

Mise à jour : 6 juin 2026 · 9 juin 2026 · 10 juin 2026 · 11 juin 2026 · 12 juin 2026 · 13 juin 2026 · 15 juin 2026 (VPN WireGuard IPv6) · 16 juin 2026 (renommage hostnames) · 21 juin 2026 (SSD 3.8 To rejeté) · 23 juin 2026 (T=500k run #4 référence officielle, zeta_sync_pc2.sh) · 24 juin 2026 (arrêt tâtonnement STEP) · 27 juin 2026 — v13 rescan ciblé implémenté, run T=5M lancé · 4 juillet 2026 — T=5M terminé (96 manquants), v14 (7.7 min ×1.10), v15 (4.4 min ×1.93), Condition Obj2 atteinte ✅, démarrage Objectif 2 · 5 juillet 2026 — RAG vault en service (838 chunks), rag_monitor.py + guide débutant, sync 4 branches · 6 juillet 2026 — audit 4 skills, 2 désync corrigées (riemann-lab references, fusion phase-c-illinois) · 25 juillet 2026 — upgrade RAM PC1 (zeta-lab) : 8 → 16 GB, free -h confirmé · 5 août 2026 — ratio PC1/PC2 réel ×1,6 documenté (822/512 z/s), goulot PC2 identifié · zeta_backup_status.py créé, échec rclone→ProtonDrive 7/7 jours découvert · 9 août 2026 — harmonisation des fichiers dupliqués (Formules_zeta §31, 3+2 orphelins supprimés dont 2 doublons docs/pdf/) + colonnes Formule principale/Analyse sur le site public (100% liens PDF, 0 exception après génération de analyse_problemes_v7_v8.pdf), 2 erreurs factuelles corrigées sur v8 (116→80 bits, gain ×1.06), ligne v6 manquante ajoutée (tableau du site : 15 lignes), règle permanente « fichiers dupliqués » ajoutée, 26 liens du tableau v1→v16 vérifiés un par un, 4 branches + wiki resynchronisées (6 cycles) et vérifiées en ligne · 16 août 2026 — Guide-Linux-Commandes.md enrichi de 3 nouvelles sections (§23 apt PC2/PC3, §24 users cluster + auto-login, §25 vi) et de commandes SSH/doas (§4) + OpenBSD (§6 : prompt ksh, tty, extinction, consoles) issues de la session admin à distance du 15/08 ; commit wiki 166b7ba · 16 août 2026 (suite) — migration matérielle PC4 : Dell Dimension 4500 → Compaq CQ58 (Celeron B830 dual-core, 4 GB, amd64) suite à 2 crashes matériels isolés le même jour, même hostname/IP/rôle, tableau cluster + fiche Architecture-Cluster-Zeta.md §10 mis à jour · 16 août 2026 (fin de soirée) — pipeline backup rclone PC3→ProtonDrive réparé (2 causes trouvées : log auto-copié pendant sa croissance + crash Go greenteagc sur 386, jamais fonctionné depuis le 15/06 — commit 65e64f4) · 18 août 2026 — STEP=0,010 marqué vestige dans le tableau historique, formule adaptative réelle documentée (calibrage sur T_MAX global, suréchantillonnage ×17 à bas t) · 5 septembre 2026 — VPN tiers (Proton VPN) identifié incompatible avec l'accès distant (bloque l'IPv6 nécessaire au tunnel), avertissement ajouté à la fiche cluster ; nouveau guide Guide-WireGuard-Acces-Distant · 6 septembre 2026 — cause du déficit T=5M (96 manquants) corrigée : fragilité RS à bas t, PAS des paires enjambées (M₁≈0,08, réfuté par test A/B) · voir JOURNAL et Formules_zeta §33 · 12 septembre 2026 — rendu KaTeX cassé sur tout le wiki : 4 causes racines identifiées et corrigées (_/#/,/;/!/%, blocs $$ multi-lignes, pipe/lien dans tableau, adjacence $ sans espace), ~50 fichiers, 8 commits · règle permanente ajoutée ci-dessus, détail JOURNAL entrée 2026-09-12 · 13 septembre 2026 — audit lecture seule des recommandations IA externes (DeepSeek/Kimi/Grok) + 2 documents du LAB, note « paires enjambées » du tableau T=5M corrigée (référence croisée avec le diagnostic du 06/09), 5 actions proposées en attente de validation hprzeta, détail JOURNAL entrée 2026-09-13, rapport source rapports/audit_reco_IA_2026-09-12.md (dépôt de code, non commité) · 13 septembre 2026 (suite) — investigation sémantique MARGE_SECURITE + git blame aux jalons validés (verrou moteur, lecture seule) : 10.0 confirmé seule valeur validée empiriquement (bbb8a6f→00abe5c), 3.0 explicitement invalidée (a04ea1f) — plus seulement une dette de doc, une croyance contredite par git ; R6 précision Arb 64 bits documentée, écart max 1,455e-11 en production ; rapport rapports/marge_securite_et_precision_2026-09-12.md (non commité), détail JOURNAL entrée 2026-09-13 (suite) · 5 octobre 2026 (matériel, RAG, sauvegardes) · STACK.md (hprzeta) · Mis à jour le 2026-10-16 — 671 lignes

Clone this wiki locally