Calculs autour du moteur mange-flammes

[gégé62]

bonjour à vous,
@Gedeon

la courbe PV qui change avec la vitesse, la surface entre les courbes diminue quand la vitesse augmente...

oui c'est normal, la surface utile est liée à la quantité de chaleur échangée entre gaz et paroi. Plus ça va vite, moins on a de temps donc il y a moins de calories échangées.
Dans le calcul actuel le coefficient d'échange est fixé et constant. Or dans la réalité il augmente un peu avec la vitesse, car il varie dans le sens du nombre de Reynolds (Re=V*D/Nu) où V=vitesse, D une dimension géométrique de référence (*) disons le diamètre ou la course, Nu=viscospté cinématique du gaz.
On sait que l'on ne connait pas le coefficient d'échange, on sait qu'on ne pourra pas le calculer, mais il y a tout lieu de penser qu'il varie de la même façon que pour un écoulement dans un tube en régime laminaire/turbulent, un peu à la limite entre les deux. Il semblerait que "h" varie comme Re^0.33 (laminaire) ou Re^0.8 (turbulent). La viscosité semble varier comme T(°K)^1.66.
Je prépare une version suivante dans laquelle "h" est proportionnel à Re^0.5.
La question est de définir le "h" de départ. J'ai proposé que la valeur que l'on fixe pour "h" corresponde au fonctionnement le plus courant de ces moteurs, à savoir 300 t/mn et 600°K. Cette valeur est ensuite adaptée à tout instant en fonction du diamètre, de la vitesse du piston et de la température.

Un autre point me turlupine: c'est que dans certaines conditions on ne trouve pas de limite supérieure à la vitesse, philippe2 l'avais déjà testé, puissance et rendement continuent d'augmenter à perpette....Et c'est peut-être ce que tu constates aussi Gedeon. Curieusement cela semble se produire quand on met un très fort décalage de vilebrequin, en négatif bien sûr.
Je ne dirais pas que j'ai compris la cause exacte, il y a peut-être une erreur de calcul concernant la géométrie, je dois vérifier cela. Mais si on raisonne par rapport à un "vrai" moteur, on comprend bien que si la vitesse augmente beaucoup, on va finir par être limité par les frottements et les pertes de charge du gaz.
Pour les frottements, je pense que dans le calcul actuel, à savoir une certaine contre-pression qui s'exerce toujours dans le sens pénalisant, le principe n'est pas mauvais. Bien entendu reste à trouver la bonne valeur....mesure du frottement réel comme tu as déjà fait Gedeon...
Pour les pertes de charge, on indique bien une pression perdue, mais elle est fixe. Or en réalité la perte de charge du clapet et celle de la soupape varient comme le carré du débit qui passe au moment considéré.
D'autre part, je n'ai pas pris en compte la perte de charge interne du gaz liée au mouvement du piston, puisqu'il y a bien un écoulement, il y a une perte de charge. Elle aussi varie au carré de la vitesse, elle devient probablement limitante à partir d'un certain point.

Dans la version que je prépare, je modifie les pertes de charge de la façon suivante:
-pour le clapet. En général on connait le diamètre d'orifice. On entre ce paramètre de construction dans les données. La feuille s'occupe de faire le calcul de la perte de charge en fonction du débit. C'est un calcul un peu à la louche, mais c'est assez réaliste quand même.
-pour la soupape. [Edit] On entre une valeur pour la pression de début d'ouverture, et un diamètre correspondant à l'orifice de passage.
-pour les pertes de charge liées aux turbulences internes, c'est plus difficile. En phase de remplissage, ça peut s'ajouter à la perte de charge du clapet. En phase d'échappement, ça peut s'ajouter à la perte de charge de la soupape. En phase "fermé", je pense que cette notion est délicate à appréhender. En thermodynamique classique, on suppose que la pression dans une enceinte est partout identique. Si on s'éloigne de ça, on arrive à des considérations complexes, que je ne puis aborder, du genre "transformations non réversibles" "variation d'entropie" etc.... donc je n'y toucherai pas. (mais reconnaissons que dans la réalité ça peut jouer, et nous amener une limitation supplémentaire).

Cela n'est-il pas lié à l'énergie cinétique ? La charge est-elle constante ?

Question pas facile....
Quelle que soit la vitesse du moteur, et donc, quelle que soit l'énergie cinétique à un moment donné, la charge (puissance) que peut subir un moteur correspond au travail qu'il peut fournir à chaque seconde, donc sur un certain nombre de cycles. Si on le charge plus il va ralentir, et s'arrêter si vraiment on charge trop. Donc l'énergie cinétique ne joue aucun rôle, sauf que en cas de charge trop élevée il tiendra un peu plus longtemps avant de s'arrêter, "il vivra un moment sur ses réserves"

En pratique je cherche la vitesse maximum sur mes moteurs, j'ai bien l'impression que plus il tourne vite, plus je peux lui imposer une charge élevée.

est-ce avec un décalage de vilebrequin ?
Je pense qu'on peut représenter la courbe Puissance=f(vitesse) comme une sorte de parabole (croquis ci-joint).
S'il n'y a pas de limite, c'est à cause d'un problème de calcul, comme évoqué au début.

bonne journée !

 

[SULREN]

Bonjour,

Un autre point me turlupine: c'est que dans certaines conditions on ne trouve pas de limite supérieure à la vitesse, philippe2 l'avais déjà testé, puissance et rendement continuent d'augmenter à perpette...

@gégé62 :

Comme tu l’as toi-même fait remarquer, beaucoup d’éléments de calcul varient avec la vitesse et on ne peut pas les supposer constants sans nuire à la validité de la simulation. Il faut même prendre en compte la vitesse instantanée à chaque point du cycle, et pas la vitesse moyenne.
- La perte de charge dans l’orifice d’admission varie avec la vitesse et donc la masse de gaz chaud avalé à chaque cycle en dépendra aussi.
- La colonne de gaz aspirée a un comportement, un type d'écoulement qui dépend de la vitesse.
- Les frottements visqueux sur les pièces en mouvement dépendent de la vitesse : on ne peut pas les supposer constants.
- La masse de gaz qui fuit à chaque cycle dans le clapet d’aspiration et dans le jeu autour du piston, dépend de la section de passage de fuite, mais aussi du temps pendant lequel la fuite opère, donc dépend de la vitesse.
- La quantité instantanée de chaleur échangée à travers les parois à un point du cycle dépend de l’écart de température à ce point du cycle, de la surface d’échange à ce point du cycle, du coefficient d’échange (supposé constant) et du temps de l’échange (temps de séjour à ce point du cycle), donc là aussi de la vitesse.
- etc.

Pour savoir où cette dépendance de la vitesse a été prise en compte, ou pas, il faut décortiquer les cellules du tableau Excel. Cela permettra ensuite d’en étudier l’impact sur la précision de la simulation et d'introduire partout où c'est important la loi de variation de l'élément considéré en fonction de la vitesse instantanée.

 

[gégé62]

Pour savoir où cette dépendance de la vitesse a été prise en compte, ou pas, il faut décortiquer les cellules du tableau Excel.

bonjour Sulren,
Pour la plupart des points que tu soulèves, la réponse est dans mon post de ce matin. Il y a aussi des explications à la première feuille du fichier (version 10 diffusée samedi post #226) sur les hypothèses et les limitations du calcul.
Une précision: la perte de charge du clapet est prise en compte (valeur constante actuellement, variable en future version 11) uniquement pour définir la pression interne, mais je n'ai pas influencé le débit entrant ou sortant. Normalement c'est du second ordre, mais à vitesse rapide il est rvai que cela peut jouer, et ce serait mieux d'en tenir compte. Je vais voir, si ce n'est pas trop compliqué je le ferai.

La masse de gaz qui fuit à chaque cycle dans le clapet d’aspiration et dans le jeu autour du piston, dépend de la section de passage de fuite, mais aussi du temps pendant lequel la fuite opère, donc dépend de la vitesse.

Les frottements visqueux sur les pièces en mouvement dépendent de la vitesse : on ne peut pas les supposer constants

Je peux ajouter une fonction "fuite" qui agit comme s'il y avait un trou de fuite de diamètre donné. Mais comment fixer ce diamètre....Je pense que ce serait peut-être aller trop loin inutilement. Pour l'instant je considère que les pertes par fuite, ou par les frottements visqueux du gaz, dont je parlais aussi, sont plus ou moins à inclure dans ce que j'ai appelé "frottements", et qui est censé englober tout ce qui entrave la marche du moteur et qui n'est pas nommément pris en compte.

Bonne soirée

 

[Gedeon Spilett]

Je suis bien d'accord avec cette courbe de puissance/vitesse, c'est ce que j'observe avec mon moteur ici
https://www.usinages.com/threads/un...ipe-du-moteur-avaleur-de-flamme.106396/page-2courbe de puissance. post #24
d'ailleurs ces valeurs sont à refaire, avec son nouveau clapet en acier inox, ce moulin dépasse 1300 rpm à vide.
mais simplement si un petit moteur ronronne à 300 rpm, lui coupler une charge va le stopper...c'est pour ça que je recherche un moteur rapide.

Dans le calcul du travail moteur cellule C114 (et E114), c'est la somme de toute la ligne 112 correspondant au travail moteur par incrément, et pas seulement pendant la phase ou le clapet d'admission est fermé. Or la surface comprise entre les lignes "horizontales" peut être plus importante que la surface du travail et à mon avis ne devrait pas être prise en compte, ai-je bien compris ton tableau ou j'ai tout faux ?

 

[SULREN]

Bonjour,

Normalement c'est du second ordre, mais à vitesse rapide il est rvai que cela peut jouer, et ce serait mieux d'en tenir compte. Je vais voir, si ce n'est pas trop compliqué je le ferai.

C’est peut-être compliqué mais plutôt que d’essayer de re-inventer en partant de 0 il faut peut-être s’inspirer de ce qu’a fait Klaus-Jürgen Bladt, dans les excellents documents que mvt nous a indiqués.

K.J. Bladt donne l’expression de la pression régnant dans le cylindre pendant la phase de succion. On n’a plus besoin de se préoccuper de la delta P dans le clapet, et c’est plus précis que de supposer une pression fixe sur la face du piston. Je n’ai pas encore essayé de comprendre sa démonstration, mais je vais m’y atteler.

PS : @mvt Grand merci pour les liens qu’il a partagés avec nous.

Entre ces infos et celles qu’on trouve dans le travail de gégé62, il est facile de retrouver l’ensemble des équations qui décrivent le comportement de l’avaleur de flammes, avec bien sûr les inévitables petites approximations, comme dans toute modélisation.
A noter que la grande majorité de ces équations sont de simples calculs géométriques / trigonométriques.
Les plus difficiles sont celles, très peu nombreuses, relatives à la mécanique des fluides et à la thermodynamique.
Cela me donne envie, quand je serai sorti de la « phase de surcharge » que je connais aujourd’hui, d’écrire en langage de programmation un simulateur numérique d’avaleur de flamme sur la base de ces équations. C’est bien plus facile et rapide qu’avec Excel. Cela permettrait d’échanger des résultats et de se debugger mutuellement, plus facilement qu’en travaillant seul.

 

[gégé62]

K.J. Bladt donne l’expression de la pression régnant dans le cylindre pendant la phase de succion. On n’a plus besoin de se préoccuper de la delta P dans le clapet, et c’est plus précis que de supposer une pression fixe sur la face du piston

Je pense qu'il n'y a qu'une façon de trouver la pression dans le cylindre: calculer la delta P au passage du clapet et la retrancher de Patm. Ainsi on peut corriger le débit entrant. C'est ce que j'ai fait finalement dans la version 11 (je vais progressivement du plus simple au plus compliqué.....
Je pense que c'est aussi ce qu'il a fait dans les lignes que tu cites.

plutôt que d’essayer de re-inventer en partant de 0 il faut peut-être s’inspirer

J'ai découvert sur ce fil le travail de KJ.Bladt quand j'ai fait mes premières versions, mis ne l'ai guère étudié, pas le temps..... Et puis il faut bien faire travailler ses neuronnes....je n'ai rien inventé, j'ai mis sur tableur le comportement tel que je le voyais, et j'ai découvert certaines choses en le faisant. Si j'avais connu ce calcul de Bladt je n'aurais rien fait du tout....! Là j'avais le sentiment de faire du nouveau et de combler un manque.
Maintenant sauf erreur de calcul manifeste, il n'y a pas de raison pour trouver des résultats très différents, juste que nous devons avoir chacun notre façon de faire des approximations.

 

[gégé62]

d’écrire en langage de programmation un simulateur numérique d’avaleur de flamme sur la base de ces équations

Ce serait un beau challenge, je ne connais pas de simulateur, ça doit être un tort.....

 

[gégé62]

post #24

je n'avais plus en mémoire cette courbe, merci de la rappeler.

Or la surface comprise entre les lignes "horizontales" peut être plus importante que la surface du travail et à mon avis ne devrait pas être prise en compte, ai-je bien compris ton tableau ou j'ai tout faux ?

Non tu as raison le travail utile est bien ce que tu dis. Mais entre les horizontales c'est un travail négatif, donc il intervient, mais en déduction du travail utile. La somme sur toute la ligne est la somme algébrique, et le total peut facilement être négatif.....à ce moment le moteur ne peut fonctionner.

 

[Gedeon Spilett]

Mais entre les horizontales c'est un travail négatif,

ça je suis d'accord, mais je ne vois pas de "raison thermodynamique" de calculer les échanges thermiques dans cette phase "ouverte" et les inclure dans le bilan, il sont utiles certes pour calculer la température du cylindre, des gaz résiduels etc...pour les cycles suivants.
Il me semble que le trajet de retour du piston passé le retour à la pression atm et l'ouverture du clapet ne dépend plus des échanges thermiques mais seulement du volant.

Si la pression dans le cylindre lors de l'admission n'est pas la pression atmosphérique, c'est que l'orifice d'admission est bien trop petit...même pour une feuille de calculs, il faut partir sur des bases raisonnables.
(c'est facile à voir sur la feuille de KJ Bladt en changeant la taille de l'orifice) il a introduit un facteur dzéta basé sur le rapport des diamètres orifice/cylindre pour évaluer cette perte de charge. mais par contre, la température de l'air entrant a toutes les chances d'être inférieure à la température de la flamme quand on voit tourner un moteur, c'est une approximation discutable il me semble.

 

[gégé62]

mais je ne vois pas de "raison thermodynamique" de calculer les échanges thermiques dans cette phase "ouverte" et les inclure dans le bilan

j'ai voulu représenter du mieux que je pouvais ce qui se passe réellement.
Que ce soit en phase 1 (ouverte) ou en phase 2 (clapet fermé) dès que le gaz est dans le cylindre l'échange thermique se fait, il n'y a pas de raison de ne pas le compter.
Maintenant pour ce qui est de la surface entre les horizontales, si la pression diffère un peu de l'atmosphère, il y a bien une action (en négatif), il y a bien une force qui est le produit de la pression différentielle par la section, et cette force travaille. Par exemple avec un moteur sans soupape ou une soupape tarée trop fort ça peut devenir très important si l'ouverture de clapet traîne en peu. Si elle est négligeable, aucune importance, on peut entrer une valeur très faible, l'effet sera minime.

même pour une feuille de calculs, il faut partir sur des bases raisonnables

j'avoue ne pas comprendre, rien n'empêche d'entrer des valeurs correctes. La feuille de calcul doit rendre compte de tout, si possible. Il y a des points où les données manquent (échange thermique, température du gaz entrant). Pour le reste, on sait à pêu près ce qui se passe, je ne vois pas pourquoi on ajouterait des approximations.
Cela dit je suis d'accord que rien n'empêche de mettre un orifice suffisamment gros pour qu'il ne donne jamais une grande perte de charge même à grande vitesse. Comme je l'ai dit tout à l'heure, la version 11 calculera la perte de charge et on pourra donc fixer son diamètre en connaissance de cause.

il a introduit un facteur dzéta basé sur le rapport des diamètres orifice/cylindre pour évaluer cette perte de charge

Ce n'est pas illogique mais ça ne correspond pas à la réalité. Dans la version 11 je calcule cette perte de charge en fonction du débit instantané et du diamètre d'orifice. C'est peut-être un luxe inutile, mais ce n'était pas très compliqué. Je fais l'impasse sur la température, qui joue aussi, mais elle ne varie pas tellement.

la température de l'air entrant a toutes les chances d'être inférieure à la température de la flamme

Je suis tout à fait d'accord. Déjà la température de flamme n'est pas tellement connue. J'ai essayé un calcul (il est dans la feuille "combustion"), mais c'est théorique, on arrive à une température plus élevée que ce qu'on peut mesurer en pratique. Je suppose que dans une combustion les gaz en réaction ne sont jamais en parfaite proportion stoechiométrique. En plus, je suppose qu'il doit y avoir un peu d'air frais qui se faufile avec la flamme à l'entrée du cylindre, et qui baisse la température par dilution, d'où l'intérêt d'une tubulure d'admission comme on en voit sur certaines vidéos. Maintenant, ça a peut-être aussi des inconvénients, il faut voir...
Mais on entre la température qui nous semble la plus exacte, pas forcément la température de flamme.
NB: c'est peut-être aussi bien que la température soit un peu descendue par rapport à la flamme pour la tenue des matériaux et étanchéité...?

 

[SULREN]

Bonjour,

Si la pression dans le cylindre lors de l'admission n'est pas la pression atmosphérique, c'est que l'orifice d'admission est bien trop petit..

Si la pression dans le cylindre n’est pas la pression atmosphérique c’est peut-être aussi parce que le moteur atteint un régime trop élevé (mais je ne connais rien en avaleeur de flammes)

Il faut de la cohérence dans la vision des choses : on ne peut pas négliger dans sa simulation des éléments qui ont des effets quadratiques en fonction de la vitesse du volant, sans risquer de voir ensuite son simulateur avoir un comportement surprenant :
« ....c'est que dans certaines conditions on ne trouve pas de limite supérieure à la vitesse, puissance et rendement continuent d'augmenter à perpette.... ».

Comme l’a fort justement laissé entendre Motorix dans un des posts du début, on peut se passer de tous ces calculs et réaliser des avaleurs de flamme qui fonctionnent très bien…..et si on veut en réaliser un sans avoir à réfléchir, on peut même trouver des plans partout.

Quelle est donc l’intérêt de faire un simulateur, que ce soit sur Excel, ou autre chose, en essayant de le peaufiner au mieux ?

-1) C’est déjà de se faire plaisir tout en faisant travailler ses neurones, comme l’a dit gégé62.
Et là, j’ajouterais qu’on peut aussi bien les faire travailler en remplissant soi-même une feuille blanche, qu' en essayant de comprendre une modélisation plus fine faite par d’autres.

-2) C’est aussi de pouvoir tester toutes sortes de cas de marche, y compris des configurations quasi hors limites , etc, sans avoir chaque fois à commencer par faire des pièces, les ajuster, etc. (La grande extension de la simulation dans les labos et l’industrie a bien une explication).

-3) C’est ensuite à partir des connaissances fines qu’on a acquises en 1, et de l’outil de simulation élaboré qu’on a réussi à créer en2, de pouvoir aider des gars qui n’ont pas trouvé de réponses aux questions (peut être tordues) qu’ils se posent.

PS
Un peu hors sujet car il s’agit d’un autre domaine, mais je ne regrette pas d’avoir suivi ces 3 étapes dans le domaine des horloges astronomiques, qui est une de mes passions.
Avec la compréhension de l’étape 1, des outils numériques que je me suis créé dans l’étape 2 (comme ici gégé62 avec ses tableaux Excel) j’ai pu atteindre l’étape 3 et aider un membre d’un forum qui réalisait avec sa compagne des merveilles de mécanismes astronomiques, mais qui ne parvenait pas à calculer le train de rouages dont il avait besoin (photo ci-dessous, de sa réalisation en impression 3D)

Il s’agit de la réalisation de SergeViellard, du forum Webastro, dans la discussion
(à suivre à partir de octobre 2017; le rouage est donné vers la fin de la discussion):
https://www.webastro.net/forums/top...tivations-histoire-difficultés-avenir/?page=3

 

[mvt]

Bonsoir,

PS : @mvt Grand merci pour les liens qu’il a partagés avec nous.

Ce n'est pas moi, c'est Internet.
Je n'ai pas eu le temps de m'y pencher, en dehors de la cellule 180°

Cela me donne envie, quand je serai sorti de la « phase de surcharge » que je connais aujourd’hui, d’écrire en langage de programmation un simulateur numérique d’avaleur de flamme sur la base de ces équations.

C'est un peu ce que je pensais aussi. Un peu compliqué en ce moment. Dans l'idée, c'était de reproduire le dessin de KJ Bladt avec Tkinter p. ex. Il y a peut-être plus simple.

Je n'ai qu'un regret... que la fonction print n'existe plus :'(

 

[gégé62]

Bonjour,

Je viens de regarder le fichier de KJ.Bladt. C'est une présentation beaucoup plus élaborée que la mienne, je ne domine pas assez Excel pour en faire autant. Cela dit j'aimerais savoir comment ce fichier réagit avec un moteur connu dont on peut comparer le fonctionnement avec ce que le calcul dit. Quelqu'un ayant un moteur a t-il déjà fait ? Il y a cette question d'angle de fermeture de clapet qui semble être fixé à 180°, or ça ne devrait pas marcher...
Alors je m'interroge, ce calcul est-il resté purement théorique, sans confrontation avec le réel ?

@mvt, SULREN,
vos propos sur l'utilisation d'un simulateur m'intéressent, mais je n'en connais pas. Je suis impatient d'en savoir plus.... .
Pour ma part j'en suis resté à excel. Mais il y a des difficultés liées aux références circulaires, dans ce genre d'application où tous les paramètres interfèrent, c'est presque à tous les coups. C'est sans doute pour cela que KJ.Bladt fait trois itérations. Alors je suis obligé de biaiser, parfois en utilisant en référence la colonne précédente par rapport à celle qu'il faudrait, mais ça fausse un peu le calcul. Le fait de développer sur deux cycles successifs m'a bien aidé de ce point de vue. Je n'ai pas essayé de décortiquer les calculs de KJBladt, c'est trop compliqué quand on n'est pas l'auteur, et en plus je ne comprends pas toute la langue de Goethe....que j'ai pourtant apprise à l'école, mais c'était il y a longtemps
Alors, le simulateur, se serait un nouvel horizon qui s'ouvre, pas seulement pour ce moteur...!

J'ai pris un incrément de 3° au pif, pour limiter à 120 colonnes par cycle. Lui il a pris 1°, ça diminue les erreurs. Ce ne serait pas compliqué de passer à 1° mais la version du fichier sous Excel 2003 limite à 256 colonnes. Il faudrait donc que j'inverse la présentation, c'est du boulot....
A propos de présentation, je dois m'excuser mais aussi expliquer pourquoi mon fichier est si bordélique. Déjà c'est construit sans plan préalable, au fur et à mesure du déroulement des calculs. Mais chaque fois que j'ai fait une modif, j'ai essayé de ne pas tout chambouler, alors j'ai utilisé les lignes libres, qu'importe où elles se trouvent....du coup ça fait un peu du n'importe quoi. Je me demande ce qui est le plus pratique, avoir une page de données/résultats et les calculs sur une autre, mais je ne suis pas parti dans ce sens....
Bref il faudrait que je revoie tout, mais je ne veux pas le faire maintenant, trop de boulot.

C’est aussi de pouvoir tester toutes sortes de cas de marche, y compris des configurations quasi hors limites

oui en gros c'est bien ça. Tant qu'on n'a pas fait, on ne sait pas tout à fait ce qu'on peut en retirer. Au début, c'était surtout l'histoire des neurones....puis je me suis aperçu que cela affinait ma propre compréhension du phénomène, pratiquement dès la première version, qui avait pourtant des problèmes. Enfin cela a apporté un éclairage nouveau et fait découvrir certaines particularités par exemple l'effet d'un désaxage, ou d'une irrégularité de vitesse, influence du coefficient d'échange, bien que restant en grande partie inconnu). J'espère que la pratique confirmera tout cela.....

 

[SULREN]

Bonjour,

C'est un peu ce que je pensais aussi. Un peu compliqué en ce moment. Dans l'idée, c'était de reproduire le dessin de KJ Bladt avec Tkinter p. ex. Il y a peut-être plus simple.

On peut faire plus ou moins simple selon le temps qu’on veut consacrer à l’écriture du code, la convivialité qu’on cherche dans son interface d'utilisation, la richesse en visualisation graphique qu’on s’impose. Je suis mal placé pour parler de Python et TKinter parce que je ne les utilise pas.
Je n’avais pas connaissance de leur existence quand j’ai voulu, en 2005, créer par codage mes propres outils logiciels pour répondre aux besoins de mes bricolages et passions.
Je voulais :
- Acheter la licence d’un langage, et pas pirater, et si possible pour pas cher
- Un langage procurant une grande rapidité de traitement, parce que j’avais besoin de faire tourner aussi des algorithmes « force brute », donc itératifs.
- Des possibilités graphiques étendues.
- Un langage compilé avec debuggage facilité.
PureBasic a eu ma préférence (à tord ou à raison?). J'ai acheté sa licence à vie, et le l’utilise encore, parce que je reçois les mises à jour et qu’il répond à mes besoins.
https://fr.wikipedia.org/wiki/PureBasic

Parmi les outils que je me suis créés avec ce langage:
- Génération de profil d’engrenage à la norme British Standard Part 2 et génération des commandes pour tailler ces engrenages avec une simple fraise scie, et s’éviter les très coûteuses fraises module en horlogerie.
- Idem pour la génération de profil de fly-cutter pour taillage d’engrenages en développante.
Présenté ici lors de mon inscription à Usinages. Aller au post #49
https://www.usinages.com/threads/taillage-de-roues.2155/page-4

- Calcul de trains de d’engrenage réalisant un rapport de transmission précis (pour horloges astronomiques, réalisation de filetage)
- Résolution de systèmes d’équations non linéaires
- Profilage de cames (pour une même fonction, le profil de la came dépend de la taille du galet et de la tringlerie qui suit)
- Simulation de phénomènes astronomiques

Dans le cas du travail fait par gégé62, une alternative possible à Excel, tout en procédant de la même façon, consisterait à écrire un code qui remplacerait par une boucle (For Next, While Wend, Repeat Until) les nombreuses colonnes du tableau et éviterait le problème des références circulaires.

For i = 1 To 360 Step 3
Gosub OuvertureClapet
Résultat1 (i) = Equation1
Résultat2 (i) = Equation2
……..
...….
RésultatN (i) = EquationN
Next i

Le Step peut être 3, comme pour gégé62, ou 1 comme pour K.J. Bladt, …..ou mettre 3600 à la place de 360.
Les N équations seraient exactement les formules que gégé62 à logées dans les cellules de sa première colonne.
Le sous-programme OuvertureClapet, appelé à chaque indice de la boucle, donnerait l’état du clapet. Il permettrait, par exemple, de générer des angles d’ouverture et de fermeture variables en fonction de certaines grandeurs (ex. la vitesse, la charge, etc) pour éviter la surpression, pour réguler la vitesse, ou……..
Mais je n’y ai pas encore vraiment réfléchi et je dis peut-être des bêtises. Je vient juste de m'impliquer dans le problème du fonctionnement des avaleurs de flamme,...…. que j'aimais déjà bien cependant, pour les avoir vus entre autres dans les expositions (Le Grès, Montpitol) auxquelles Motorix nous convit tous les ans.

Je n'ai qu'un regret... que la fonction print n'existe plus :'(

Bizarre que la commande print ait été supprimée. Elle a peut-être juste changé de mode d’utilisation.

@gégé62
Je répondrai plus tard, de mon mieux, à ton post.

Cordialement.

 

[mvt]

Bonjour,

Bizarre que la commande print ait été supprimée. Elle a peut-être juste changé de mode d’utilisation.

Apparemment, elle causait des bugs.
Je ne connais pas PureBasic. Comme j'utilise alternativement Linux Mint et W8.1, python me va bien, pour ce que j'en fait.
Je ne fais plus que des bidouilles aujourd'hui, même si j'ai conservé certains réflexes comme le moins de globales possibles, passage par valeurs, gestion systématique des exceptions, etc.

Malgré tout, je suis devenu un utilisateur quoi

je devrait avoir plus de temps disponible d'ici un mois en gros pour commencer à regarder la chose plus sérieusement.
Là, je suis dans la sociologie des orga

 

[SULREN]

Bonjour,

@gégé62
En préambule il faut reconnaître que toi et K.J. Bladt avaient fait un extraordinaire travail de fond, dans la compréhension du fonctionnement de ce moteur, l’élaboration de sa modélisation et dans la création d’un outil pour animer cette modélisation.
K.J. Bladt a franchi une étape de plus, en remettant toute sa présentation sous une forme très soignée. Mais il ne s’agit que de forme, certes pas négligeable, mais pas de fond. En particulier il serait bon de savoir comment son modèle a été confronté à la réalité.
Il serait malvenu, dans un cas comme dans l’autre, que ceux comme moi qui n’ont jamais rien fait sur ce sujet se permettent de faire des critiques sur ces travaux. Au mieux il peut s’agir de corrections de bugs ou de suggestions d’amélioration.

Comme support du modèle vous avez choisi Excel.
- C’est un outil extrêmement puissant et facile d’emploi, mis à part quelques fonctionnalités.
- Il est très précis : flottant double précision (pas indispensable dans le cas de notre moteur, mais dans bien d’autres cas).
- Il est connu de tous, contrairement aux Matlab et aux langages de programmation : Python, C, PureBasic, etc.

Je l’utilise pour la plupart de mes calculs, y compris lorsque des grandeurs à rentrer dans le tableau doivent être affinées de façon itérative (itérations que je fais à la mano). C’est le cas par exemple du calcul des pertes de charge dans une tuyauterie, où le coefficient de frottement qu’on doit rentrer se calcule par la formule de Colebrook White, qui dépend du nombre de Reynolds, ce qui nécessite qu’on connaisse déjà la vitesse dans la tuyauterie, donc qu’on ait déjà fait tourner le calcul. 3 à 4 itérations suffisent.
Dans les cas où il faudrait trop de lignes ou de colonnes (comme dans ton cas) ou bien les cas demandant de très nombreuses itérations, je passe en langage de programmation. Avec les algorithmes « force brute » on peut avoir des millions de milliards d’itérations.

Dans le cas de ce moteur j’aurais choisi la programmation, mais maintenant que tu as fini le travail sur Excel, il n’y a aucune raison que tu le refasses sur autre chose.
Le vrai travail important d’enrichissement à venir, c’est d’affiner de plus en plus ton modèle par la prise en compte des remarques de ceux qui ont des avaleurs de flamme.

De même, tu dis que ton fichier est bordélique. Personne n’aurait fait mieux, dans un travail qui s’est construit petit à petit. Ceux qui sont passionnés acceptent volontiers le petit droit d’entrée pour comprendre tes tableaux et ils naviguent ensuite très vite dedans (il n’y a que les « SI » qui sont un peu chiants parce qu’on n’a pas forcément leur syntaxe en tête).

Par contre, une transposition de ton modèle (même approche par incrémments, mêmes équations, mêmes coefficients) sur un autre support, pourrait être faite par des volontaires et partagées ici.
Je vais essayer en PureBasic si j’arrive à trouver deux ou trois jours, d’autres pourraient essayer en Python, ou en C.
Si cela se faisait, une concertation pourrait s’ouvrir ici sur la façon de désigner les variables et les constantes, pour faciliter la communication future, et sur le choix du moteur (soupape ou pas, desaxage ou pas, came ou maneton …) pour que les travaux portent sur la même cible.

@+
Cordialement.

 

[philippe2]

Bonjour,

.......
Là, je suis dans la sociologie des orga

Etude du comportement des générations Papy-Boomers, X, Y et Z, et génération alpha ??? Pire qu'un Excel sur un moteur thermique.

Bon courage,

@SULREN : lu et approuvé.

 

[gégé62]

@SULREN nous sommes bien en phase. Je compte sur ceux qui ont un moteur et qui auraient la patience de regarder ce que ça donne.
J'ai conscience qu'en ayant ajouté peu à peu des fonctionnalités cela devient de plus en plus minutieux de remplir les données, et si on ne les choisit pas bien ça peut dévier beaucoup de la réalité.

Pour le choix de la méthode, je n'ai même pas pensé à la programmation, je n'ai pour l'instant travaillé que sur Excel, et encore, en apprenant sur le tas (et sur le tard surtout ). Cela dit tu parles de calcul de perte de charge, j'avais fait dans les années 2000 un calcul sur excel pour un pb au boulot qui sortait de l'ordinaire. il s'agissait de calculer la perte de charge dans un écoulement annulaire (entre deux tuyauteries l'une dans l'autre). Je crois savoir qu'on peut le faire assez facilement en passant par le diamètre hydraulique, mais j'ai voulu me servir de ça pour connaitre un peu excel. Et je me suis amusé à imaginer que les deux tuyaux n'étaient pas forcément bien centrés.....amusant, il y avait donc plusieurs itérations à gérer en même temps, donc obligation de passer par une macro écrite en VBA. J'y ai passé 3 mois (tous les soirs chez moi !) mais je l'ai fait....j'avoue que j'en étais assez fier. A l'occasion de le mettrai ici, ça peut intéresser du monde, mais à force d'y bricoler(*) j'ai un bug dedans et ça plante (au niveau de l'itération de base avec Colebrook).
(*) j'ai voulu ajouter un choix "laminaire" ou "turbulent" en fonction du Re, et évidemment c'est la solution de continuité entre entre les deux qui pose problème.
Cela dit je l'utilise en ce moment avec sa page "orifices" qui est indépendante, pour notre moteur....
Pour en terminer sur la programmation, j'ai abordé le C avec Arduino, je ne sais pas s'il y des points communs avec ton PureBasic

Bonne soirée à tous

 

[SULREN]

Bonsoir,

@SULREN nous sommes bien en phase. Je compte sur ceux qui ont un moteur et qui auraient la patience de regarder ce que ça donne.
J'ai conscience qu'en ayant ajouté peu à peu des fonctionnalités cela devient de plus en plus minutieux de remplir les données, et si on ne les choisit pas bien ça peut dévier beaucoup de la réalité

La vraie question est bien celle là : celle de la validité du modèle.
A côté de cela, la question de savoir s’il valait mieux le faire tourner sur Excel, ou sur tel ou tel outil, prend un caractère secondaire.

L’effort de réflexion pour établir le modèle a dû être immense, personne n’en doute, mais la difficulté de la tâche était immense elle aussi.
Comment vérifier cette validité :
-1) Obtenir le maximum de retours de ceux qui ont ce type de moteur.
-2) C’est une suggestion : étudier ce qu’a fait K.J. Bladt et chaque fois que cela diverge de ton modèle, essayer d’en déduire où est la vérité.
Mais c’est plus facile à dire qu’à faire : difficulté de la langue car tout n’est pas traduit en Anglais, complexité des équations, de la notation, approche différente des problèmes, etc.

Je crois savoir qu'on peut le faire assez facilement en passant par le diamètre hydraulique

Oui il résulte des notions de « section de la tuyauterie » et de « périmètre mouillé » et il ne faut pas oublier que le « rayon hydraulique » est le quart du « diamètre hydraulique », contrairement à ce qui se passe en géométrie, où le rayon vaut la moitié du diamètre.

Pour en terminer sur la programmation, j'ai abordé le C avec Arduino, je ne sais pas s'il y des points communs avec ton PureBasic

Tant qu’on reste dans le calcul mathématique, et c’est le cas pour notre moteur, les instructions se ressemblent beaucoup d’un langage à l’autre, et ressemblent même beaucoup à celle du Fortran IV que j’utilisais vers la fin des années 1960, à l’école d’ingénieurs, sur la « babasse » que nous avions.
Pour tout le reste, chaque langage a ses spécificités.
PureBasic est hyper développé dans le domaine graphique, par exemple, parce qu’il est beaucoup utilisé pour les jeux vidéo. Je n’utilise pas le 1/1000 de ses possibilités dans ce domaine.
J'envisage aussi de me mettre au C, à cause de Arduino. J'ai déjà le gros bouquin....mais ne l'ai pas encore souvent ouvert.

Bonne nuit!

 

[mvt]

Bonsoir,

Entièrement d'accord avec vous.

Me concernant, il y a deux options possibles, pour lesquelles l’effort est similaire...
Côté "simulateur" :
* Se concerter pour faire un truc hors office. L'avantage d'un langage compilé est qu'il ne nécessite normalement pas d'installation (en dehors des DLL dans le cas du choix de Visual C/C++, etc. mais cela contraint à windows) mais est dépendant d'un OS.C'est un choix engageant qui conditionne la suite. C, C++ sont disponibles en natif sous linux, mais dépendants de l'OS ou nécessitent une bibliothèque spécifique sous windows, genre Cygwin et la portabilité du code à faire qui va avec)
* La même chose, mais avec un langage interprété. Avantage : la portabilité, disponible en natif sous linux pour Python. Inconvénient, nécessite l'installation de l'interpréteur. C'est pas pire qu'Office Disponible aussi sur arduino. Peut être utile pour la validation du modèle "en réel". Nécessite de toutes façon un apprentissage comme tout autre langage.
* Se concentrer sur le super travail de Gégé, c'est fait, ça existe, à nous (et d'autres si intéressés) de l'aider dans la maintenance/évolution de la chose, si tant est que cela intéresse quelqu’un. je n'ai pas eu le temps de regarder comme a été faite la simulation allemande.

Côté réalisation
Me construire un moteur, comme travail de mise en pratique, à partir d'un plan existant. Il va bien falloir que je m'y mette un jour.

J'ai une petite préférence pour la seconde options, ce qui ne m'empêche pas de participer à la première aussi. Par contre, je ne maîtrise absolument pas les théories que vous mettez en oeuvre.
Mon dada depuis quelques années serait plutôt la théorie de l'activité

Entièrement d'accord avec vous.

Etude du comportement des générations Papy-Boomers, X, Y et Z, et génération alpha

Non, c'est pire, le monde de la santé. Aujourd'hui, c'était les représentations sociales et les analyses textométriques (similarité, CHD et AFC)

 

[gégé62]

Côté "simulateur" :

bonsoir à tous
je ne savais pas trop quoi répondre à mvt..
car je pige à peine ....linux, python, les DLL, les OS, c'est pour ainsi dire de l'hébreu pour moi.
Mais je suis curieux d'apprendre....
D'ailleurs je crois que je vais être obligé d'entrer un peu plus dans VBA pour la macro "recherche auto de la vitesse maxi", car avec la fonction Solveur ça plante vraiment trop, c'est principalement pour ça que je retarde la sortie de la version 11. J'avais bidouillé un peu déjà dans VBA mais il y a 10 ans.... et ce n'est pas très convivial, je trouve.

Au fait, on ne parle pas de Open Office et surtout les macros qui vont avec. Quelqu'un connait ? avec moi elles ne veulent pas marcher (rien ne s'enregistre) est-ce que ça vaut le coup de s'y atteler ? est-ce que c'est comme VBA, ça semble un peu différent comme syntaxe, mais c'est gratuit, avantage non négligeable...

 

[mvt]

Bonsoir,

En gros, il y a la solution d'utiliser un langage de programmation, gratuit ou payant, interprété (nécessitant l'utilisation de l'interpréteur pour son exécution, comme le basic à l'époque du DOS par exemple sur les PC IBM ou le VBA d'office), ou compilé. Le compilateur est un programme qui transforme un code source (langage de programmation, compréhensible par un humain) en un langage utilisable directement par la machine (un fichier .exe par exemple). L'inconvénient des fichiers ainsi générés est qu'ils sont dépendants du système d'exploitation. Certains langages (destinés à être compilés ou interprétés) ont l'avantage de la portabilité, c'est à dire qu'ils peuvent s'utiliser sur des OS différents, aujourd'hui, pour faire simple, windows, linux, android ou l'OS d'Apple. Certains langages interprétés offrent eux-mêmes des compilateurs permettant leur utilisation sans interpréteur (c'est le cas de python p. ex.)
Dans les temps anciens, nombre de programmeurs ont fait leurs armes avec turbo pascal de Borland (largement piraté, y compris par les écoles et universités).
Aux langages sont souvent associés des bibliothèques offrant des fonctionnalités complémentaires, graphiques, statistiques ou scientifiques.
Une autre solution pourrait être d'utiliser R qui est largement utilisé par la communauté scientifiques (dans con acception la plus large). C'est un outil très puissant qui a les avantages... et les inconvénients de sa puissance. Pour un utilisateur lambda comme moi, la syntaxe est un peu déroutante, mais on s'y fait aussi. Les analyses textuelles que je fais utilisent une interface graphique développée en python et Qt qui génère des scripts R, exécute R et récupère le résultat. J'avais oublié cette alternative.

Dans tous les cas, cela demande un effort et un investissement. Pour faire "propre", il est aussi nécessaire de sortir de sa paillasse et de s'imposer quelques règles... Entre autres pour que cela puisse être repris par d'autres et évoluer, sous réserve qu'il intéresse une communauté.
A mon sens, il serait dommage que ce bel exercice intellectuel soit perdu même si, apparemment, nombre de ces moteurs résultent plus de l'empirisme que de la science (Et ce n'est pas un reproche )

Je suis assez d'accord avec Gégé concernant LibreOffice, qui offre l'avantage de la gratuité (et de la portabilité). J'ai parlé de LibreOffice, qui est un fork (une branche //, apparue suite au rachat de Sun Microsystems (qui faisait des très bonne machines, les Sparks entre autres, et assurait le développement de Java) par Oracle) d'OpenOffice, avec une communauté bien plus active.

J'ai parlé de Python car Gégé a aussi évoqué Arduino...

Quoi qu'il en soit, je n'ai toujours pas redémarré le Bangood (alias BG), trop de boulot. Je vais me lancer dans la réalisation de l'un des plans récupérés, certainement avec un peu de customisation. Priorité au fonctionnement, plus que l'esthétique

 

[SULREN]

Bonjour,
Il est tout à fait possible d’écrire un programme qui fasse tourner le modèle de ce moteur, avec des possibilités plus puissantes et nombreuses qu’avec Excel.
Tous les langages de programmation le permettent, mais avec des avantages et inconvénients dont parle mvt.
Je ne veux pas participer à la discussion à leur sujet, faute de connaissances complètes et parce que dans mon cas ce serait de toutes façons PureBasic, que j’utilise depuis 2005.
https://fr.wikipedia.org/wiki/PureBasic

Je regrette infiniment de ne pas pouvoir m’y atteler de suite, à cause de gros problèmes disons de « charge » en ce moment, parce qu’il eût été préférable de « faire et montrer », plutôt que de « dire ».
Mais pour être prêt à le faire au premier créneau de disponibilité qui se présentera, je veux avoir sous la main tous les éléments de base de l’analyse. Ils sont déjà dans cette discussion et dans les tableaux de gégé62 et de K.J. Bladt, auxquels on pourrait cependant ajouter des fonctionnalités supplémentaires.

Je voudrais par exemple revenir sur deux points qui ont déjà été évoquées au début de cette discussion, bien avant que j’y entre.
-1) La température du métal du cylindre est considérée comme homogène sur toute sa longueur. Gégé62 avait envisagé 2 zones, mais finalement n’en a gardé qu’une.
-2) De même, la température dans la masse de gaz présente dans le cylindre a été considérée comme homogène. Du fait du brassage créé par la turbulence lors de l’admission, on peut penser qu’elle l’est, mais est-ce bien sûr ?
Il me semble, par exemple, qu’au moment de la fermeture du clapet, la tranche de gaz qui vient juste d’être admise (celle proche de la culasse) est plus chaude que celle située contre le piston, surtout si on travaille en longue course (en moteur "super carré", pas de pb).

Sauf s’il a été démontré par l’expérience que les températures de 1) et de 2) sont chacune quasiment homogènes, je préfèrerais les traiter dans la simulation comme variables le long du cylindre (au moins au stade de l’objectif initial, quitte à réviser ensuite ma position si des difficultés énormes en résultent, ou si après plus ample réflexion l’intérêt se révèle être bien mince).
Cela veut dire qu’il ne faudrait plus calculer l’échange thermique globalement : masse globale de gaz sur surface globale d’échange, mais tranche par tranche le long du cylindre.
En Excel il a fallu simplifier, à moins d’accepter de superposer plusieurs feuilles de calcul. En programmation il y a d’autres possibilités.

Merci d’avance de vos commentaires.
Cordialement.

 

[Gedeon Spilett]

je suis aussi plutôt de l'avis que ce genre de modélisations sont plus faciles avec un vrai programme, plutôt qu'un tableur, je ne sais pas pourquoi excel, cet outil d'une lourdeur immense, a remplacé des programmes "vite fait" en Basic (c'était sympa d'introduire des variables au moment ou on en a besoin) ou autres mais je suis loin d'être un spécialiste, c'est juste un avis comme ça...

pour en revenir au tableur de Gégé62, je n'arrive pas à voir pourquoi quand je rentre les données physiques de mon moteur (ou du moteur Bangood), il me donne in fine un moteur avec une puissance négative, alors qu'il tourne bien mon petit moteur !
il me semble que c'est à cause des pertes de charges in out lignes 44 et 45...et la surface entre les longues lignes horizontales, j'y reviens je sais, mais la faible puissance de ces moteurs peut facilement disparaitre en introduisant une correction surdimensionnée....
si je supprime cette correction dans les formules lignes 107 et 112, tout va bien, je retrouve une puissance conforme à celle que je mesure.

 

[gégé62]

Bonsoir à tous
merci à mvt pour ses explications.
D'après ce que je lis, si j'ai bien compris, le langage C aurait peut-être pu être utilisé aussi ? sur Arduino je n'utilise que celui-là, mais de façon assez basique, même si j'essaie de sortir un peu du système Arduino avec ses fonctions propres, bien pratiques mais mangeuses de performances. Mais en fait j'ai un peu de mal à détacher ma vision du C de l'utilisation d'Arduino. Avec Excel, ce qui me rassure, c'est probablement la présentation en lignes/colonnes, c'est du concret. Mais j'admets que c'est psychologique...

@SULREN
l'homogénéité de température dans un gaz, c'est une chose que j'ai déjà essayé de comprendre, mais on ne parle rarement, je n'ai pas trouvé grand-chose. Il est vrai que dans la vie courante on peut facilement avoir un courant d'air chaud ou froid localisé, le mélange et l'homogénéisation ne semblent pas très rapides.
Mais prendre cela en compte dans mon calcul me parait difficile et on ne pourrait établir qu'une loi de variation pifométrique, dont on ne sait pas ce qu'elle vaudrait, pour un effet probablement du second ordre, mais je n'en sais rien.

Gégé62 avait envisagé 2 zones, mais finalement n’en a gardé qu’une.

je ne voulais pas trop encombrer, mais au point où j'en suis, je l'ai remis (je pensais l'avoir remis dans la version 10 ?). Je n'ai pas pour l'instant de conclusion sur l'intérêt de cela, je n'y ai pas regardé assez. Je pensais avoir un gros bénéfice avec une première zone très chaude et une seconde plus froide, c'est pas si évident.

si je supprime cette correction dans les formules lignes 107 et 112, tout va bien, je retrouve une puissance conforme à celle que je mesure.

je ne peux pas donner d'avis bien sûr. J'espère publier la version 11 qui a pas mal de différences (progrès j'espère)
- calcul de la perte de charge au clapet d'entrée, avec correction du débit gaz entrant
- idem soupape de sortie
- évolution du coefficient d'échange en fonction des vitesses et températures.
cela semble OK, mais je merdouille encore un peu avec la vitesse oscillante....

bonne soirée
heu....elle touche à sa fin...

 

[mvt]

Bonjour,

Côté langage, l'important est de pouvoir s'y retrouver et arriver à faire ce que l'on souhaite. je n'ai malheureusement pas pris le temps de m’intéresser à Arduino, Raspberry ou autres systèmes de ce genre. J'ai pourtant ce qu'il faut à la maison (avec un autre système, ESP32), en dehors du temps. Tous utilisent micropython ou équivalent.

Si simulateur reste un peu un grand mot, à mon sens, la réalisation avec un langage suppose de définir au départ deux ou trois éléments de fond :
* les variables à tester, j'entends par variables, les éléments influant sur les résultats ag. cylindrée, rapport alésage course, angle de came, durée d'ouverture, fermeture, etc. Deux options possibles : faire un fichier de paramètre modifiable par un éditeur de texte standard ou par une saisie à l'écran (avec une sauvegarde tant qu'à faire, intégrant éventuellement un versionning simple du type param_moteurAAMMJJHHMM
* les formules d'usage (codage)
* la présentation des résultats. On peut très bien sortir un fichier csv (fichier tabulaire permettant sa lecture par un tableur aisément) pour exploitation ultérieure (result_moteurAAMMJJHHMM.)
L'intérêt du tableur est de pouvoir tout en une seule fois, l'inconvénient est sa (relative) lourdeur.

Excellente journée à tous

 

[gégé62]

bonjour,
merci pour ces explications claires. Pour l'instant ( y a d'l'espoir !) ce n'est pas pour moi.....

 

[SULREN]

Bonjour,
A prendre parmi toutes les autres, voici mes suggestions pour que cette discussion se poursuive intensément, comme elle le mérite.
J’indique, à la fin du message, les points sur lesquels je pourrais moi-même contribuer.

Pour des motivations qu’il a expliquées, gégé62 a modélisé un avaleur de flamme, c’est-à-dire traduit la « réalité » de ce moteur dans le langage mathématique. Il est déjà passé par des étapes qui l’ont amené à l’état actuel.

A) ETAT ACTUEL :

ETAPE A1 : Description de l’objet à modéliser :
- a) Choix de quelques options (ex : pas de soupape de surpression, vilo desaxé…)
- b) Liste des éléments descriptifs pris en compte : éléments dimensionnels, critères de passage d’une phase de fonctionnement à une autre (ici : angles relatifs au clapet), charge appliquée au moteur, hypothèses simplificatrices (sur les jeux par ex). Cette liste pourrait être étendue : ajouter la nature des matériaux constitutifs, leur épaisseur, etc.

ETAPE A2 : Etablissement du modèle:
- a) Données d’entrée du modèle, sur la base des éléments descriptifs retenus.
- b) Equations décrivant le comportement (thermodynamique, mécanique, etc) liant les variables retenues et forcément aussi la variable temps.
- c) Logique d’articulation de ces équations dans les différentes phases de fonctionnement du moteur (les fameux « SI » et « ET » du tableau Excel de gégé62).
- d) Paramètres et coefficient entrant dans ces équations (coefficient d’échange, etc).

ETAPE A3 :
- a) Choix d’un outil pour faire « tourner » le modèle, en l’occurrence Excel.
- b) Implémentation du modèle dans cet outil.

ETAPE A4 : Création de possibilités de simulation, c’est-à-dire la possibilité de faire varier les éléments descriptifs du modèle et d’analyser leur impact sur son fonctionnement, donc en principe aussi sur le fonctionnement de l’objet réel.


B) EVOLUTIONS POSSIBLES :

Sur la base du savoir déjà acquis, considérable, il me semble que l’objectif est de motiver ceux qui sont intéressés par cette discussion, à savoir :
- Les mordus de modélisme et en particulier ceux qui ont déjà réalisé un avaleur de flammes. Leur participation est des plus précieuses, par les retours d’expérience quelle apporte.
- Ceux qui ont envie d’en construire un et qui voient l’explication de ses aspects théoriques comme une motivation supplémentaire.
- Ceux qui trouvent dans cette réflexion une opportunité de faire travailler leurs neurones.

ETAPE B1 : Renforcer autant que faire se peut la confiance dans le modèle actuel.
-a) Dénicher les bugs éventuels d’écriture dans le tableau Excel.
-b) Signaler les écarts entre ce que dit le modèle et ce qui est constaté sur les moteurs réels, comme l’ont déjà fait certains intervenants. C’est la meilleure contribution à l’affinage des paramètres du modèle, comme par exemple l’ELEMENT CLE qu’est le COEFFICIENT D’ECHANGE.
-c) Par réflexion, par analyse du travail de K.J. Bladt, par recherche documentaire, essayer d’affiner aussi les équations actuelles du modèle.

ETAPE B2 : Etendre la portée et l’acuité du modèle:
- a) A d’autres éléments descriptifs : par exemple la nature des matériaux, les surfaces de fuite, la mesure du profil de température le long du cylindre,…
- b) A une prise en compte plus fine de la répartition des températures dans la masse de gaz aspirée et dans la répartition le long du cylindre, à la variation cyclique de vitesse (gégé travaille déjà sur la vitesse).
Il en résulterait des équations bien plus complexes à écrire et donc une obligation à changer d’outil pour faire tourner le modèle, les limites d’Excel étant alors dépassées.

ETAPE B3 : Basculer sur un outil plus puissant qu’ Excel : la programmation :
-a) Choisir un langage (chacun s’est déjà exprimé là dessus).
-b) Implémenter le modèle dans le nouvel outil.

ETAPE B4 :
Mettre un simulateur à disposition des membres de ce forum qui ne connaissent rien à la programmation, mais juste l’utilisation d’un PC et qui n’auraient pas à acheter la licence d’un langage de programmation.
Ce simulateur pourrait être:
-a) une feuille Excel dans laquelle il suffirait de rentrer les éléments descriptifs du moteur, ceux de l’ETAPE A1 –b
-b) un fichier exécutable (donc : fichier.exe)

La feuille Excel et le fichier « .exe » seraient à charger dans le disque C : de ceux qui voudraient utiliser le simulateur.
L’exécution du fichier déclencherait le déroulement du modèle et l’édition des résultats, par la création dans le disque C : de fichiers au format « csv » et de leur équivalent au format « .txt » dans lesquels on trouverait tous les résultats qu’on trouve actuellement dans les tableaux de gégé62.
J’ai déjà fait ce type de manip avec des membres d’un autre forum, en créant un exécutable avec PureBasic.

A noter qu’Excel peut importer ou exporter des données à partir de fichiers .txt ou .csv.

MA PARTICIPATION :
Dès maintenant je travaille en faisant de mon mieux sur:
B1-a
B1-c
B2-b (en ce qui concerne la répartition dans la masse de gaz)

Comme je l’ai déjà dit dans des messages précédents, si j’en trouve la disponibilité, je serais très motivé par : B3-b
Il est clair que B4-a et B4-b découleraient de façon naturelle de B3-b.

 

[mvt]

Bonsoir,

Je me suis trompé, ce n'est pas important, ce sont des NXP (ARM) LCP800 et LPC1768 (RISC 32bits), programmables en C. Je peux récupérer aussi un Raspberry PI3B+. On peut déjà faire pas mal de choses avec un encodeur rotatif p. ex. Un shunt (ou moteur CC utilisé en dynamo couplé à une charge résistive variable) doit donner une évaluation de la puissance.
Les pro d'usinages en R PI pourraient peut-être nous faire gagner du temps et éviter certaine écueils. Par contre, il y a trop longtemps que je n'ai pas touché à l'électronique pour être efficace sur le sujet (j'en suis resté aux composants discrets et n'ai pas franchi le cap des cms.)

Sur le BG, je regarderai comment remplacer le support du cylindre actuel par un autre permettant de faire varier "simplement la chose" de 0 à + ou - quelque chose. Sur le fonte, je pense à un autre système mais ce sera pour plus tard.

Ce découpage des tâches est intéressant.

Je me permettrais cependant une remarque... Le disque C n'est pas forcément le meilleur endroit. Personnellement, et je ne suis pas le seul, je sépare OS des données sur des partitions, tout comme sous Linux.
L’inconvénient des .exe tout prêts est qu'ils ne permettent pas à d'autre d'apporter des modifications ou de faire évoluer le sujet. Et restent contraints à un environnement singulier. Mais cela est un autre débat.

Je devrais avoir un plus de disponibilités d'ici 15j - 3 semaines.
D'ici là, j'aurai reçu mes nouveaux mors durs et tendres
Et commencé à attaquer la fonte
Et je pourrai consacrer aussi un plus de temps à l'un des deux fichiers Excel à définir avec vous.
On ne peut pas peaufiner les deux, à mon sens celui de Gégé est prioritaire.
Pour autant celui de K.J. Bladt est aussi fort utile, au regard de la documentation associée.
Si quelqu'un parle allemand, échanger avec lui devrait permettre de lever certains écueils qu'il a certainement rencontrés sur lesquels nous nous trouvons éventuellement.

Je reviens donc au point précédent : isoler les variables et paramètres liés au fonctionnement. Il y en a en gros deux :
* les caractéristiques du moteur : 1) nommer les paramètres de base et 2) en déduire ou calculer les paramètres dérivés eg. cylindrée, etc. (2 dans le programme)
* les caractéristiques du chauffage, la flamme, selon des paramètres "simples" (pour alimenter les calculs), p. ex. alcool à brûler (70°), alcool à 90, brûleur gaz (si les caractéristiques de la flamme sont "standard")

Lancer les calculs (l'algo est plus important que le langage)

Sauvegarder les résulats :
* Ressortir les paramètres moteur optimisés si nécessaire
* Sauvegarder les fichiers de calcul pour chargement dans un tableur, de la suite office ou autre, chaque suite est à même de charger un fichier csv, c'est aussi le cas de R pour faire des analyses complémentaires pour ceux qui le souhaitent.

C'est tout pour ce soir (aussi)

 

[SULREN]

Bonjour,

Le disque C n'est pas forcément le meilleur endroit

On peut charger la feuille Excel, le fichier exécutable, et les fichiers qu’il génère lui-même, dans n’importe quelle disque ou partition de disque.
Chacun se les met où il veut.

L’inconvénient des .exe tout prêts est qu'ils ne permettent pas à d'autre d'apporter des modifications ou de faire évoluer le sujet.

J’ai parlé d’exécutable pour des utilisateurs qui ont un PC mais qui n’ont pas envie de s’embêter avec des problèmes informatiques, comme installer un langage, lire le code du simulateur et encore moins d’aller le modifier.
Ceux qui veulent y tripatouiller recevraient le code source….. bien sûr.

Pour en revenir à la répartition de la température le long du métal du cylindre, sur sa face extérieure, et le long de la masse de gaz à l’intérieur, je pense après y avoir réfléchi qu’on peut très bien faire comme l’a fait gégé62 : c’est-à-dire raisonner sur les températures moyennes de ces masses.
Inutile de raisonner par tranche, ce qui amènerait à insérer une boucle dans la boucle au niveau du programme.
Vis à vis de ce problème Excel n'a pas de handicap.