Immatriculer les compositions

[olivir]

Bonjour,

Une petite suggestion toute bête ...

P+C reconnait ses compositions à leurs noms respectifs, ne pourrait-il pas plutôt attribuer un numéro de matricule si bien que l'on pourrait changer de nom à tout moment sans avoir à faire de corrections supplémentaires (remplacer par) ?

P+C continuerait à nous présenter les noms des compositions mais en interne il bosserait avec des numéros pour nous donner plus de liberté.

--
MAJ 15/05/2011
Puisqu'il n'y a eu aucune réaction en presqu'un an, je suppose que soit peu vous chaut soit je ne me suis pas fait comprendre, je prends donc un exemple concret

Supposons une composition "Murs extérieurs 20 cm PSE" utilisée dans un projet.
À un moment donné, on décide que ces murs extérieurs seront réalisés avec 30cm de PSE.

Je peux modifier la composition, lui donner le nom qui convient, la renvoyer dans le projet, l'affecter à la place des anciennes compositions comprenant 20 cm d'isolant. Mais, évidemment, tout comme ma phrase précédente, c'est long à faire...

Deuxième solution, je modifie la composition et ne change pas le nom... hop ça marche mais alors le nom de la composition ne correspond plus avec son contenu et c'est un peu gênant quand on reprend le projet à froid plusieurs semaines plus tard.

En revanche, on voit bien que c'est rapide !

Du coup, si P+C ne travaillait pas avec les noms mais avec un numéro de matricule (ID pas forcément accessible à l'utilisateur) plutôt qu'avec le véritable nom de la composition, on pourrait le modifier à tout moment sans conséquence fâcheuse tout en gardant facilité et rapidité pour mettre un nom qui nous convient le mieux.

matricule_compositions.png

D'ailleurs, si je peux me permettre, cette façon de faire serait sans doute à étendre à tous les intrants de P+C (scénarios, menuiseries, ponts thermiques, etc.), cela simplifierait la vie des utilisateurs

[olivir]

3 ans après, je pense toujours que cette modification serait nécessaire ! En étant malin, on pourrait même associer un matricule unique à chaque composition à la façon d'un hash*.
* Les matériaux étant eux-même équipés d'un matricule, cela serait assez simple. Par exemple, une composition associant de l'intérieur vers l'extérieur un plâtre (id=001) de 1cm et un parpaing (id=002) de 20cm pourrait s'appeler a001e1b002e20.

Du coup, on pourrait échanger entre utilisateurs de P+C des compositions qui auraient des noms différents mais dont le matricule, l'identifiant, démontrerait que c'est la même composition. Ce serait aussi la fin des doublons pour l'instant inévitables (combien j'ai de parpaings enduits ?).

[Renaud]

Bonjour,

Au départ, cela fonctionnait comme cela. Mais cela nous a posé de gros problèmes.
Il y avait un identificateur numérique unique.
Mais quand un utilisateur passait son projet à un autre utilisateur et que cette personne remontait ses composants dans sa bibliothèque, il pouvait y avoir des collisions d'identificateurs. Il fallait gérer ça, ce qui était loin d'être simple (en pratique, on avait pas mal de bugs).
De plus, cela permettrait d'avoir en bibliothèque 2 compositions différentes avec le même nom ce qui n'est pas commode non plus pour l'utilisateur.
Le hash ne règlerait pas vraiment le problème si l'utilisateur crée ses propres matériaux et éléments.

Donc pour l'instant, ce n'est pas à l'ordre du jour.
Ce que nous faisons dans des cas similaires, c'est que nous donnons un nom à la composition qui ne correspond pas à son contenu, mais à son usage. Par exemple "Mur façade Sud".
Ainsi, on peut changer son contenu en gardant son nom.

Meilleures salutations.

[olivir]

Il faudrait un hash pour les éléments à partir des caractéristiques spécifiques qu'on y entre. Par ex., qu'il s'appelle plâtre ou platre, l'ID sera le même puisque tiré de ces caractéristiques (ρ, C, λ).

Du coup, ni conflit ni doublon, c'est le même matériau et P+C le détecterait

[Nico.Naud]

Olivir,
Oui, mais quid de l'import d'un élément Titi possédant les mêmes caractéristiques thermiques qu'un élément Toto déjà en bibliothèque ? Cela remplacerait Titi par Toto.

Dans ce cas il faudrait que l'ID comporte aussi le nom de l'élément et au final cela alourdirait l'ID...

[olivir]

Si le matériau Titi a les mêmes caractéristiques que Toto, alors pour la thermique c'est le même matériau, quel que soit son nom, non ?

P+C a juste à demander quel nom on veut conserver ou alors proposer la possibilité de doublonner (en allongeant d'un indice par ex. le matricule).

[Nico.Naud]

Pour P+C, oui, mais pas pour l'utilisateur.
Je suis d'accord avec toi dans le fond.
Mais voir apparaître "Placotherm" au lieu de Placomur, dans une étude thermique, ça peut poser des problèmes de labellisation Effinergie+, par exemple...
Bon, l'exemple n'est pas forcément bien trouvé, mais tu vois ce que je veux dire.

[olivir]

Ben, puisque le nom n'a plus d'importance, on pourrait le changer à volonté.
Et sinon, il suffit d'autoriser les doublons avec l'avantage incroyable que P+C saurait que ce sont des doublons ou des clones

[Nico.Naud]

Ben, puisque le nom n'a plus d'importance, on pourrait le changer à volonté.

En fait je ne parle pas ici du calcul thermique en lui-même, qui sera correct, mais de la rigidité des organismes certificateurs. Pour eux, un Placotherm c'est un Placotherm, peut importe s'il a les mêmes caractéristiques thermiques qu'un Placomur, si on pose un Placotherm c'est son nom qui doit apparaître dans l'étude thermique, et c'est sa fiche technique qui doit être jointe au dossier de certification.

Et sinon, il suffit d'autoriser les doublons avec l'avantage incroyable que P+C saurait que ce sont des doublons ou des clones

Ca par contre ça pourrait peut-être marcher... Qu'en pense l'équipe d'Izuba ?

[olivir]

D'ailleurs, ce serait assez rigolo de voir que des tas de marques distribuent en fait le même produit (d'un point de vue thermique).

[olivir]

Heu, juste un détail, il n'y a aucune raison que la fonction de hachage permette à l'utilisateur de comprendre le sens des matricules comme je l'ai fais ici. D'autant plus que pour les compositions, cela pourrait donner des ID très longs !

On peut très bien imaginer faire un hachage injectif d'une codification lisible (avec les 4 caractéristiques uniques que sont conductivité, masse volumique, chaleur spécifique et épaisseur) des matériaux et compositions pour fixer une taille par exemple.

Prenons un exemple :
Si 1cm d'enduit plâtre se code L0.35R1500C1000e1
et le parpaing de 10 cm L1.111R1300C648e10
Alors la composition avec le plâtre côté intérieur se coderait L0.35R1500C1000e1+L1.111R1300C648e10 p. ex ce qui est compréhensible par l'utilisateur mais deviendra vite long à manipuler par P+C pour les compositions plus fournies.

En revanche si je fais un hash md5 par dessus, j'obtiens une signature unique de taille limitée : dfe3d47d77835a78c1a30765e601bf20.

Si on veut générer les noms multiples comme Nico.Naud le suggérait, tout en gardant une signature thermique unique, il suffit, par ex., d'accoler le nom "Toto"=dfe3d47d77835a78c1a30765e601bf20.

Si j'envoie mon "Toto" à Nico.Naud et qu'il est identique thermiquement à son "Titi", P+C le détectera immédiatement et pourra même en avertir l'utilisateur, pour qu'il fasse la gestion qu'il veut de ses clones. Voilà qui pourrait calmer la tendance qu'ont nos bases de données d'être des grenouilles qui veulent se faire aussi grosses que le bœuf.

[Nico.Naud]

Il serait peut-être temps d'arrêter la came, Olivir !

[jdpjav]

Bonjour !
Heuuu... c'est quoi le "hash" et le "hash md5" ? ça se mange ?...

En tous cas vrai souci que la gestion de nos biblo quelles soient de "compositions" ou de "scénarii" ...

Plus terre à terre:
A- pour mon usage j'ai décris des compos et scénar de base (= couramment utilisés), auxquels j'affecte un préfixe de "type" (mnémonique "parlante"), suivi d'un n° d'ordre unique, suivi d'un "détail" descriptif.
Par exemple : un mur en ite est nommé : Me (le type) -001 (le N° d'ordre) - enduitX+iteY+structure porteuseZ+Lame d'air La+etc.
- Le nom est long et très descriptif : "Me-001-enduitX+iteY+structure porteuseZ+Lame d'air LaW+...+...+..." On sait à sa lecture à quoi on a à faire.
- Son libellé n'est quelques fois pas lisible entièrement dans les fenêtres un peu riquiqui, c'est vrai. Mais son n° d'ordre unique permet d'éviter les doublons et n'oblige pas à tout lire pour l'identifier dans le jeu des manips de type "remplacer". Il suffit de noter dans un coin de cervelle "Me-001".
-Les doublons sont évités en prenant le temps d'aller lire le dernier n° d'ordre utilisé pour le "type" en question. C'est donc manuel et demande un peu d'attention.

B-un souci se pose lorsqu'on veut ranger cette compo dans 2 classes distinctes. C'est à dire la conserver dans la "biblio de base" et à la fois dans la "biblio d'un projet donné" (histoire d'avoir sous les yeux toutes les variantes de compo utilisées pour ce projet là).
P+C n'admet pas qu'un même nom existe en plusieurs endroits ... Dommage.
J'ai contourné le pb en introduisant un "index projet" que je rajoute entre le "N° d'ordre" et le "détail"; ainsi "Me-001-enduitX+iteY+structure porteuseZ+Lame d'air LaW+...+...+..." devient pour le projet Toto "Me-001_toto-enduitX+iteY+structure porteuseZ+Lame d'air aW+...+...+...".

Cette méthode est loin d'être parfaite, mais j'ai pour l'instant pas trouvé mieux.
Chacun d'entre-nous étant confronté à la nécessité d'organiser un minimum sa bibliothèque, et le métier de bibliothécaire étant un vrai métier, il me paraitrait intéressant que nos chers développeurs ajoutent au manuel une proposition de méthodologie de "nommage" et de classement afin que chacun ne soit pas amené à réinventer sa brouette brinquebalante.
La grande -et précieuse !- souplesse de l'outil P+C ne perdrait rien à être assortie de propositions méthodologiques !
C'est vrai, ici, pour les biblio, mais également sur de nombreux autres sujets !...
Bon été à tous !

[olivir]

Bah, ouais mais moi comme je suis pas aussi méthodique que toi, Jean-Marie, je préfèrerais avoir la liberté de mettre le nom qui me chantera à l'instant t ("le bon mur pour la bonne maison" ), quitte à la changer à t+1 ("quel mur de m**de"), sans que cela ait d'impact sur les calculs et les rendus grâce à des identifiants uniques. Plus besoin de relancer un calcul pour corriger une fiche récapitulative ou un rapport par ex..

Si mon exemple fait junky (spéciale dédicace à mon ami Nico ), on peut en prendre un plus simple : une composition (ou une menuiserie voire même un scénario) doit être juste un jeu de clef, peu importe l'étiquette qu'on lui accolle, elles continueront à ouvrir les mêmes portes.

@jdpjav : le hachage n'est qu'une fonction injective qui associe à des données une empreinte numérique, un peu comme un code barre. L'avantage est que l'empreinte est unique et d'assez courte longueur. On se sert du hachage md5 très couramment pour vérifier que le fichier que l'on échange est le bon, de sorte d'éviter que quand on ouvre un fichier "température conventionnelle très chaude.zip", on ne retrouve pas autre chose qu'un XML RT2012 p. ex. ...

[jdpjav]

"je préfèrerais avoir la liberté de mettre le nom qui me chantera à l'instant t ("le bon mur pour la bonne maison" ), quitte à la changer à t+1".

Malgré mon écrit, je suis très ok avec toi sur l'idée qu'on pourrait (grâce à ta proposition) pouvoir changer de nom sans être obligé de remouliner !
Car il est évident que certains noms adoptés à un moment et pour un projet peuvent être gênants ou complètement inappropriés plus tard ou sur un autre projet.

Quant aux méthodes -sans tomber dans le "méthodisme", la liberté étant une chère valeur ...- je trouve que, lorsque les données sont nombreuses, vient le moment de s'organiser pour éviter de se prendre les pieds dans le joyeux foutoir. Or la liberté de créer toutes les compo du monde, tous les scénarii imaginables (ou presque) induit le "risque" justement de cette immense diversité dans laquelle il devient difficile de retrouver ses petits.

Proposer des méthodes ouvertes, c'est faire part aux autres d'une façon de faire qui peut aider sans contraindre. Une façon de déblayer un peu le chemin, un peu comme un guide touristique qui dit ce qui est remarquable sans interdire d'être curieux d'autres choses, ni de faire le circuit à l'envers !!!
Allez re-bonnes Wacances !