Sujet: [Résolu] Blocage lors du calcul de consanguinité

[Joël AUGUSTE]

As-tu vérifié avec la b4.012 qui te donne les implexes?

Bonjour,



Je viens de passer en b4.012 (je suis resté en v420).

En repartant de Alexandra de Saxe-Cobourg-Gotha l'affichage des noms est maintenant complet. Je n'ai trouvé aucun implexe de noté.

J'ai choisi Alexandra comme sosa, toujours aucun implexe. J'ai refait un calcul de consanguinité limité aux sosas sur la même personne, mais toujours le blocage. J'ai donc "tué" la calcul.

Une solution pour trouver où se situe la boucle (ou une des boucles   ), c'est peut-être de faire, depuis Anecstrologie, une extraction gedcom limitée aux ascendants de Alexandra et de la tester avec KStableau, je vais faire ça cet après-midi.



Cordialement



Joël

[DDdeBerdeux]

En repartant de Alexandra de Saxe-Cobourg-Gotha l'affichage des noms est maintenant complet. Je n'ai trouvé aucun implexe de noté.

Bonjour,

Si tu veux voir les implexes dans l'état d'ascendance complet, il faut passer à la v433.

Tu verrais que les sosas 16 et 17 figurent également comme sosas 22 et 23.

Implexes sous forme de tableau:

SOSA   IMPLEXE

22        16

23        17

62        56

63        57

106      56

107      57

108      42

208      206

209      207

210      66

211      67

396      384

397      385

414      160

415      161

480      398

481      399

etc, j'arrête en page 6, mais il y a 45 pages d'ascendance, et 223 implexes...

Une requête qui les liste:

Code: [Sélectionner]

select * from PROC_ETAT_ASCENDANCE(10014,0,3,0)

WHERE IMPLEXE IS NOT NULLJ'aurai dû commencer par là au lieu d'essayer de les lister sur l'état. D'autant plus que cette requête ne nécessite pas la v433, juste la base b4.012.

A+

André

[Joël AUGUSTE]

re bonjour,



La vérification des ascendants de Alexandra avec KStableau ne m'a pas permis de détecter où il y avait une boucle, mais d'autres erreurs sont apparues listées par KStableau :

1) Deux enregistrements FAM sont identiques. (soit la personne s'est mariée deux fois, alors que ces mariages ne peuvent être distingués soit on ne peut déterminer quel mariage est le premier) Il y en a plusieurs dizaines. J'ai vérifié les 3 premières anomalies. Sur la 1ère, il y a 2 mariages avec dates, mais les enfants ne sont affectés qu'au père (volontaire ou involontaire, je n'ai pas encore vérifié). Sur la 2ème, 1 seule union datée, l'enfant n'est affecté qu'au père (volontaire ou involontaire ?) Et sur la 3ème, 2 mariages datés, 7 enfants dont 5 pour une épouse, 1 pour l'autre et le 7ème affecté uniquement au père.

2) Le lien CHILdans l'enregistrement FAM n'existe pas (la famille contient un enfant pour lequel il n'y a pas d'enregistrement INDI. Il y en a des dizaines et des dizaines. J'ai vérifié les 3 premières anomalies. Sur la 1ère, 2 unions datées alors que SKtableau indique WIFE inconnu(e), 7 enfants dont 4 pour une épouse et 3 pour l'autre. J'ai remarqué que bien qu'il y ait 7 enfants, il était indiqué dans Ancestro 4 enfants connus. Dans les préférences / options de saisie, j'ai bien décoché la case remplissage automatique du NCHI et NMR à chaque fiche, mais j'avais commencé ce dossier avec cette case cochée. Sur la 2ème, 1 union datée, 6 enfants bien affectées aux 2 conjoints mais KStableau n'en prend qu'un seul, celui qui a le numéro sosa. Pour la 3ème, (il s'agit de Alexandra de Saxe...) date du mariage indiquée dans KS, mais époux inconnu et enfants inconnus alors que dans Ancestro, ils sont tous normalement affectés.

3) Le lien HUSB de l'enregistrement FAM n'existe pas. (la famille annonce un mari pour lequel in n'y a pas d'enregistrement INDI.). Vérification de 3 fiches, la 1ère 2 unions, mais un seul mariage. Sur la 2ème, 2 unions, déclarés mariés, datées dont une avec date "avant 1204". pour la 3ème, 2 unions, déclarés mariés et datées. Il n'y a que quelques erreurs de ce type, on trouve aussi le même genre avec "...annonce une épouse pour laquelle..."



Avec mes excuses pour avoir été aussi long...

Dernière remarque, l'extraction gedcom avait été faite depuis la base avec laquelle j'avais "tué" le calcul de consanguinité. Je vais refaire une extraction avec la sauvegarde que j'espère propre et je comparerai.



Cordialement



Joël

[Joël AUGUSTE]

Dernière remarque, l'extraction gedcom avait été faite depuis la base avec laquelle j'avais "tué" le calcul de consanguinité. Je vais refaire une extraction avec la sauvegarde que j'espère propre et je comparerai.

Exportation gedcom faite avec une base (a poriori) saine de corruption suite à une interruption volontaire du calcul de consanguinité, on obtient avec KStableau les mêmes résultats en nombre, c'est à dire :

Liens FAMS incorrects  (61x)

Liens CHIL incorrects  (1066x)

Liens HUSB/WIFE incorrects  (216x)

Cela fait quand même beaucoup car l'export gedcom contient 1002 personnes pour 858 familles. Il est vrai que pour les enfants incorrects, l'erreur est répétée pour chaque enfant déclaré manquant du couple ou du père.



Cordialement



Joël

[Horemans]

Cela fait quand même beaucoup

Un certain nombre de ces erreurs sont "normales" et il ne faut pas en tenir comte, car l'extrait fait par Ancestro crée des ruptures de liens, les conjoints n'étant (sauf erreur de ma part) pas récupérés ou pas toujours.

Je pense qu'il faut concentrer ton analyse sur la recherche de l'anomalie initiale, la boucle

Si tu utilises Visuged pour faire un extrait, tu auras surement des messages moins nombreux

[Joël AUGUSTE]

Je pense qu'il faut concentrer ton analyse sur la recherche de l'anomalie initiale, la boucle

Si tu utilises Visuged pour faire un extrait, tu auras surement des messages moins nombreux

C'est bien ce que je compte faire... En commençant par les implexes dont parle André.

Je vais utiliser également Visuged, mais l'inconvénient de ce logiciel c'est que, contrairement à KStableau, il n'indique pas le nom de l'individu où il y a une erreur, mais seulement son numéro, la recherche va donc être beaucoup plus longue... 95% des erreurs de Visuged sont : l'enfant n°xxxxx n'a pas été décrit précédemment à cette union n°xxxxx (err.123) et 5% sont : l'époux n°xxxxx n'a pas été décrit précédemment à cette union n°xxxxx. il n'est pas pris en compte (err.121).



Joël

[Joël AUGUSTE]

Bonjour,



J'ai commencé la recherche des boucles possibles sur les 223 individus qui ont des implexes en sortant un tableau grace à la formule SQL de André.

J'ai commencé par les noms qui figuraient en double dans la liste, je n'ai pas fini, mais je pense que je n'en trouverai sûrement pas car j'ai regardé en priorité ceux qui n'avaient pas de date.

Par contre j'ai découvert un problème en ce qui concerne le calcul des Sosas, voici 2 exemples :

ANGLETERRE (D’) Georges Ier (il n'y en qu'un seul) CLE_FICHE = 4690 :

- N° Sosa sur fiche de saisie Ancestrologie = 160

- N° Sosa dans impressions / documents / ascendance complet = 414 + 160

- N° Sosa dans requête SQL = 414 (un seul Sosa)

BARCELONE (DE) Bérengère (il n'y en a qu'une seule) CLE_FICHE = 9052 :

- N° Sosa sur fiche de saisie Ancestrologie = 42162193

- N° Sosa dans impressions / documents / ascendance complet = 42152977 (un seul Sosa)

- N° Sosa dans requête SQL = 42168359 + 84306023



Si pour le 1er exemple, il y a des convergences dans les numéros, il n'y en a aucun dans le 2ème exemple !  

J'ai vérifié les CLE_FICHE ou clé lien interne, ce sont bien les mêmes dans le tableau SQL et sur la fiche Ancestrologie



Cordialement



Joël

[DDdeBerdeux]

Bonjour,

J'ai fait comme vous avec v433 et b4.012. J'ai commencé par faire dans ancestro la renumérotation sosa à partir d'Alexandra 10014.

J'ai édité l'état d'ascendance d'Alexandra dans Ancestro et fait la requête suivante

Code: [Sélectionner]

select p.cle_fiche,p.generattion,p.sosa,p.implexe,i.num_sosa,p.nom

from PROC_ETAT_ASCENDANCE(10014,0,3,0) p, individu i

WHERE IMPLEXE IS NOT NULL and i.cle_fiche=p.cle_fiche

order by p.cle_fiche, p.generattion,p.sosalégèrement modifiée pour faire apparaître uniquement les champs intéressants et le NUM_SOSA issu de la fiche.

Premier résultat: l'état et la requête (sauf limitation aux implexes) donnent le même résultat, ce qui est normal puisqu'ils utilisent la même procédure.

La requête (et l'état) appellent SOSA le n° attribué en suivant les branches ascendantes, et mettent dans IMPLEXE le premier n° SOSA attribué au même individu.

La procédure de renumérotation SOSA utilisée par Ancestrologie, utilise la même logique, sauf qu'elle se limite à la première fois que l'individu est trouvé sur une branche, et ne le "ressort" plus ensuite même s'il est trouvé sur une autre branche.

Vous comprenez donc que si dans les 2 procédures, les branches ascendantes ne sont pas explorées exactement dans le même ordre, la "première fois" ne sera pas obligatoirement la même donc le SOSA sera différent.

Mais la méthode sortant les implexes, calculant tous les SOSA d'un individu, il devrait y en avoir au moins un égal au NUM_SOSA de la fiche.

Pour 4690 la requête donne sosa 414 et implexe 160, comme le NUM_SOSA de la fiche donc tout est normal.

Pour 9052 la requête ressort 2 lignes

génération 26 sosa 42168329 implexe 42152977 NUM_SOSA 42162193

génération 27 sosa 84306023 implexe et num_sosa comme au dessus.

Aucun des 3 n° trouvés dans la requête n'est celui de la fiche, il y a donc une anomalie qu'il faudrait rechercher dans les générations d'avant.

A+

André

[Joël AUGUSTE]

Aucun des 3 n° trouvés dans la requête n'est celui de la fiche, il y a donc une anomalie qu'il faudrait rechercher dans les générations d'avant.

Quand tu dis qu'il faudrait chercher l'erreur dans les générations d'avant, cela signifie bien que l'anomalie se tiendrait dans les individus de l'ascendance situés entre Alexandra 10014 et Bérengère 9052 ?

Si c'est bien ça que j'ai compris, ça va limiter le champ des recherches ! ... Pour cette anomalie ...  



Joël

[DDdeBerdeux]

Oui, mais ce n'est pas facile pour autant, car il y a 26 générations d'écart...

Et redescendre les générations en divisant les sosa par 2, poufffff. :?

Je préfère regarder la PROC_REF_CIRC, elle serait plus utile pour tout le monde.

A+

André

[DDdeBerdeux]

Dernière expérience du jour.

J'ai pris la base de PCM de 147 individus.

Le dernier (pour le moment) de la lignée: Kévin né en 1997.

J'ai remonté les générations jusqu'à la 8ième, Paul né en 1780 qui n'avait pas de père connu.

Je lui donne Kévin comme père. Ancestro l'accepte sans aucune alerte.

Je vais sur la fiche de Kévin; une fenêtre bleue signale que Kévin était trop jeune pour être père (normal à -217 ans ).

Le supprime l'évènement naissance de Kévin. Depuis plus de fenêtre signalant l'incohérence.

Cà m'a permis d'essayer la PROC_REF_CIRC. Elle fonctionne correctement, mais il faut plus d'une seconde pour analyser une base de 147 individus, et sort les 8 individus qui se trouvent sur la boucle. Logique.

Je vais la réessayer sur votre base, mais je la lancerai avant d'aller me coucher...

A+

André

[Joël AUGUSTE]

Cà m'a permis d'essayer la PROC_REF_CIRC. Elle fonctionne correctement, mais il faut plus d'une seconde pour analyser une base de 147 individus, et sort les 8 individus qui se trouvent sur la boucle. Logique.

Je vais la réessayer sur votre base, mais je la lancerai avant d'aller me coucher...

Merci André, mais je me pose la question si au vu du nombre important des implexes, des boucles "normales" ne peuvent-elles pas exister ? (mariages entre cousins, avec des oncles ou tantes, etc...)

Pour faciliter la recherche, j'ai fait un export gedcom des ascendants d'Alexandra sur 29 générations pour le réintégrer dans une autre base sur Ancestrologie. A Bérengère, je m'aperçois qu'il lui manque un enfant. Mais l'enfant qui lui manque n'est pas un sosa de Alexandra, c'est pour ça qu'il n'a pas été pris dans l'export.

Quand on voit le nombre d'enfants par couple qui sont des sosas alors qu'en ligne directe, un seul devrait l'être...



Bonne fin de soirée, je vais arrêter mes recherches pour l'instant, je commence à avoir les yeux qui se croisent...



A+

Joël

[DDdeBerdeux]

Quand on voit le nombre d'enfants par couple qui sont des sosas alors qu'en ligne directe, un seul devrait l'être...

C'est pour celà que le couple fait partie des implexes. C'est même comme çà que je détecte les implexes. Les branches venant de ind1 et de ind2, arrivent à l'implexe par un enfant différent. Si c'était par le même enfant, l'implexe serait cet enfant.

Bonne nuit.

André

[DDdeBerdeux]

Bonjour,

Recherches de références circulaires arrêtées au bout de 8 heures.

Par contre, est-il normal qu'une mère ait un enfant avec son fils!

C'est le cas de GONNOR 11323 qui avec son fils Richard II de Normandie 11324, a eu pour fils Rober 1er de Normandie 6517, un des ancêtres d'Alexandra.

Après vérification, ce n'est pas çà qui provoque le bouclage dans le calcul de consanguinité. J'ai tout de même fait un calcul de consanguinité en supprimant la récursivité de la formule, et le calcul aboutit...

A+

André

[Joël AUGUSTE]

Bonjour

C'est le cas de GONNOR 11323 qui avec son fils Richard II de Normandie 11324, a eu pour fils Rober 1er de Normandie 6517, un des ancêtres d'Alexandra.

Après vérification, ce n'est pas çà qui provoque le bouclage dans le calcul de consanguinité. J'ai tout de même fait un calcul de consanguinité en supprimant la récursivité de la formule, et le calcul aboutit...

Il s'agit bien d'une erreur, mais il y a eu plusieurs Richard de Normandie nés et décédés dans les mêmes périodes. Je reprendrai la généalogie exacte plus tard.

J'ai également supprimé cette boucle mais je n'ai pas pu aboutir au calcul de consanguinité limité aux ascendants d'Alexandra. J'ai tué le calcul au bout de 15 minutes.

Une question, lorsqu'on tue un calcul de consanguinité, et que l'on peut rouvrir Ancestrologie aves cette base dont la taille peut avoir été multipliée par 10, reste-t-il dans la base des traces de ce calcul qui pourrait venir polluer un prochain calcul, même après une optimalisation ?



A+

Joël

[DDdeBerdeux]

Non, car si tu tues la tâche FB, les modifications dans la table temporaire ne sont pas validées, mais tu as de la chance de pouvoir l'optimiser. Chez moi il est fréquent que la base soit corrompue au point qu'Ancestro fasse plein de messages d'erreur, donc pas d'optimisation possible.

Il y a sans doûte d'autres boucles. Une leçon qu'on pourrait tirer de ton expérience, mais je ne sais pas si les généalogistes seront d'accord, c'est qu'il est préférable de mettre une date estimée pour la naissance ou le décès , ainsi les contrôles de cohérences, auraient plus de chances de trouver les anomalies de bouclage, et il y aurait moins de risques de confusion d'individus lors de la sélection.

A+

André

[DDdeBerdeux]

Bonjour,

J'espère que le problème du plantage lors du calcul de consanguinité sur un dossier "à bouclettes" est résolu avec la base b4.014.

Mais pas le problème de la détection des boucles. Le calcul de consanguinité dans ce cas demande de la patience, et est certainement faux.

A+

André

[Joël AUGUSTE]

J'espère que le problème du plantage lors du calcul de consanguinité sur un dossier "à bouclettes" est résolu avec la base b4.014.

Bonsoir,



J'ai refait un calcul de consanguinité complet sur la base de 13000 individus (j'étais en v450 b4.015). Pas de plantage, résultat obtenu en moins de 1 minute, je m'attendais à beaucoup plus, je n'avais donc pas noté la seconde de départ.

Même si le résultat risque d'être faux si il y a des boucles, je pense que les erreurs éventuelles se produisent avec les individus concernés par la boucle dans la limite des générations mentionnée dans la configuration (j'ai laissé 4).



Encore merci à André dont les investigations et le travail pointilleux ont permis de trouver une solution au problème.



Cordialement



Joël

[DDdeBerdeux]

La précision est faible avec 4 générations seulement. Pour une base normale, je fais le calcul sur 10 générations. Comme le calcul n'utilise plus une formule récursive elle ne devrait pas planter le micro, ce n'est qu'une question de temps et de grossissement de la base. Essayez d'augmenter progressivement le nombre de générations, en l'optimisant entre chaque essai, pour mesurer l'impact sur le temps de calcul et la taille de la base. Et une mesure de la somme des consanguinités par la requête:

SELECT SUM(CONSANGUINITE) FROM INDIVIDU, vous permettrait de voir à partir de combien de générations, il n'y a plus d'augmentation significative.

Bonne nuit

André

[AquaBlue]

26 000 personnes et 40 générations.



Le calcul se passe bien et se termine dans un temps tout à fait raisonable.