Blabla rerevival - it really can't die

[OrOoX]

Y'en a qui se sont déjà amusé à calculer la teneur en eau de l'air ? Je bloque complètement sur les formules, tu va sur une page t'en a une,
tu va sur une autre, t'en a une autre ... ils le font exprès ? ( Formule de Rankine par exemple )

Par exemple :

avec :

• psat : pression de vapeur saturante de l'eau, en atm ;
  
• T : température absolue, en K.
  

Avec une température de 20°C soit 293.15K ça me sort -3,765461.... Hors si tu essais de le passer en ln() ou log(), la calculette plante ...


Je suis débile ... Ou ?


EDIT : La page la plus compréhensible avec résultats c'est celle-là lol : http://processs.free.fr/Pages/VersionWeb.php?page=2154

[Kissagogo27]

[BiduleOhm]

Qu'est-ce que tu veux calculer exactement ? combien de g d'eau il y a par m³ d'air ?

Edit: en fait ça c'est l'humidité absolue. Le teneur en eau c'est g d'eau par g d'air --> https://fr.wikipedia.org/wiki/Humidit%C3...idit%C3%A9

[OrOoX]

La formule que j'ai posté est donnée pour connaitre la pression de saturation de l'eau qui permet d'obtenir le
poids d'eau par une autre formule oui.

Lhumidité absolue fonctionne mais moins précis que l'humidité spécifique non ?

[BiduleOhm]

Ok, ben selon le site que t'as posté la formule pour le rapport g eau / g air sec est (entre 0 et 50 °C): 0.6221 / ((1.0135 / HR) / (10^(-2.2138 + ((7.5526 * T) / (239.21 + T)))) - 1) avec HR l'humidité relative en ratio (donc diviser par 100 si t'as un pourcentage) et T la température en °C.

Mais ça ne marche que pour une plage de température très limitée et c'est garanti qu'à 5 % près. La formule de Rankine n'est pas exacte non plus et ne marche que pour une plage de température.

Si tu veux un résultat plus précis il faut utiliser la formule de Dupré pour la Psat et ce pdf ajoute même une correction supplémentaire qui permet d'avoir une erreur ridiculement faible (< 0.1 %) de 0 à 250 °C ce qui donne (après un peu de simplification): Psat en Pa = 101350 * exp((6999.123 * (0.00267989 - (1 / T)) - 5.713172 * ln(T / 373.15)) + 1.511 * 10^-9 * T^3 + 3.001 * 10^-6 * T^2 - 0.002142 * T + 0.3033) avec T la température en K. Exemple pour 20 °C

Donc la formule finale pour le rapport g eau / g air sec est (après beaucoup de simplification): 0.6221 / (1 / (HR * (9.36146 * 10^22 * exp(1.511 * 10^-9 * T^3 + 3.001 * 10^-6 * T^2 - 0.002142 * T - 6999.12 / T)) / T^5.71317) - 1) avec HR l'humidité relative en ratio (donc diviser par 100 si t'as un pourcentage) et T la température en K. Exemple pour 20 °C et 0.6 HR

Si tu veux en g/kg t'as juste à changer 0.6221 par 622.1

Je ne pense pas qu'on puisse faire plus précis sans avoir une équation d'une dizaine de lignes...

NB: y'a les tables de l'ITS-90 pour la Psat à différentes températures si tu veux vérifier tes calculs (et j'ai vérifié ce que j'ai donné plus haut et c'est bon). Je n'ai pas trouvé de table fiable pour la teneur en eau mais les résultats sont très proches de ceux fournis par différent calculateurs et tables (qui sont eux-même un peu tous différents...).

[OrOoX]

Top la réponse


En fait le dernier lien posté j'ai réussi à l'utiliser sans problème mais c'est les autres formules qui pourtant semblent
simples que je n'ai pas réussi à utiliser, un coup c'est ln() sur un site, un coup c'est exp() sur un autre, etc ...

Déjà que je suis une bille en math alors si en plus les sources ne coïncident pas ...  


Dans mon cas c'est sur de l'air extérieur / intérieur donc la limite de 0 à 50°C ne me pose pas de problème, la précision de 5% non
plus vu que c'est plus pour de l'information que du process.

J'avais vu la formule de Dupré ouais, mais comment dire ... J'ai pris peur


Le problème avec les formules que t'as mis c'est que je suis censé les intégrer dans un automate ( Sofrel ) qui est loin d'être à la pointe
de la technologie, le simple fait que ce genre de chose ne soit pas intégré est une honte à mon sens ...

Tu te doute bien que si je le fais en bloc ça va être un carnage à faire, et je ne sais pas si je peux le faire en ST, je ne suis pas
familié avec ce langage. ( je sais que du calcul simple passe mais bonne question pour ceux là.

[BiduleOhm]

C'est parce qu'un ln() d'un côté d'un égal se transforme en exp() quand tu le passes de l'autre côté. C'est pareil que x / y = z --> x = y * z par exemple, la divison se transforme en multiplication.

Ben dans ce cas tu peux utiliser la première formule qui n'a pas de exp/ln mais il te faudra quand même les puissances (quoi que vu que c'est un 10^... y'a ptet moyen de faire sans mais c'est vraiment pas sûr...)

Ah wé, un automate qui gère pas les exp et ln c'est un peu abusé quand même

[OrOoX]

Je suis en train de faire un test en ST, à priori ça passe avec les mêmes fonctions mais il m'emmerde avec le type de variable comme d'hab ...
( REAL et LREAL ... Et bien sûr quand t'essais de le changer dans le hardware, access denied ... )

Ca donne ça dedans :

Code :

data0084 := 0.6221 / (1 / (data0072 * (9.36146 * pow(10,2) * exp(1.511 * pow(10,-9) * pow(data0011,3) + 3.001 * pow(10,-6) * pow(data0011,2) - 0.002142 * data0011 - 6999.12 / data0011)) / pow(data0011,5.71317)) - 1);

[BiduleOhm]

Note que tu peux facilement éviter la majorité des pow(). Par ex 1.511 * pow(10,-9) * pow(data0011,3) peut se transformer en 0.000000001511 * data0011 * data0011 * data0011 ou encore 1.511 * (data0011 / 1000) * (data0011 / 1000) * (data0011 / 1000) (dans ce cas idéalement il faut stocker data0011 / 1000 dans une variable au lieu de le répéter).
C'est moins lisible mais en général c'est plus perf et ça dépanne quand y'a pas de pow() dispo (et la dernière solution à l'avantage d'éviter d'avoir des nombres très petits ou très grands). Bref, je ne sais pas si ça te sera utile mais au moins tu sais maintenant.

Attention aussi à ne pas perdre en précision sur les nombres très petits et à ne pas overflow sur les grands (j'imagine qu'il utilise des flottants donc ça ne devrait pas être un pb mais c'est toujours mieux de vérifier...).

J'imagine qu'un REAL est équivalent à un float et qu'un LREAL est équivalent à un double. Si c'est le cas utilises des LREAL partout, déjà il ne devrait plus t'emmerder si tous les types sont les même et ensuite tu devrais être sûr de ne pas overflow/perdre en précision

Attention aussi à ce que le pow() prenne bien un exposant décimal et non pas seulement un entier, sinon pow(data0011,5.71317) sera arrondi à pow(data0011,6) ou plus probablement tronqué à pow(data0011,5).

Pour tester injectes à la main une température et une humidité constante et vois si ça te sort le bon résultat

[OrOoX]

Bon bah le machin veut plus en passant en LREAL ...

Code :

TEMP := ANY_TO_LREAL(data0011);
HYGRO := ANY_TO_LREAL(data0072);
OUT := data0084;

OUT := 0.6221 / (1 / (HYGRO * (9.36146 * powl(10,2) * exp(1.511 * powl(10,-9) * powl(TEMP,3) + 3.001 * powl(10,-6) * powl(TEMP,2) - 0.002142 * TEMP - 6999.12 / TEMP)) / powl(TEMP,5.71317)) - 1);

Code :

C:\ProgramData\Sofrel\Mod_Softools\17\Temp\$Root$\Nouveau dossier (2)\$PL00000\Automatism
Compiler V15.6.7.0
>> Variables Complexes stockées dans un segment séparé
Chargement des symboles...
test
test: (5): powl: Les opérandes de "*" ou "/" doivent être des nombres et avoir le même type
test: (5): +: Argument attendu
Erreur(s) détectée(s)

On dirait qu'il aime pas les négatifs dans les puissances ...


En passant ça :

Code :

TEMP := ANY_TO_LREAL(data0011);
HYGRO := ANY_TO_LREAL(data0072);
OUT := data0084;

OUT := 0.6221 / (1 / (HYGRO * (9.36146 * 100 * exp(1.511 * 0,000000001 * powl(TEMP,3) + 3.001 * 0,000001 * powl(TEMP,2) - 0.002142 * TEMP - 6999.12 / TEMP)) / powl(TEMP,5.71317)) - 1);

J'ai ça en sortie, mais là je sèche ... D'la merde ce truc, dit pas ou surtout

Code :

C:\ProgramData\Sofrel\Mod_Softools\17\Temp\$Root$\Nouveau dossier (2)\$PL00000\Automatism
Compilation de l'application en cours... Veuillez patienter...
Compiler V15.6.7.0
>> Variables Complexes stockées dans un segment séparé
Chargement des symboles...
test
test: (5): ,: ")" attendu après la liste d'arguments
Erreur(s) détectée(s)

[BiduleOhm]

Ok, bon, essaie des real simple alors.

T'as mis des virgules au lieu de points dans 0,000000001 et 0,000001. Y'a qu'en france qu'on utilise cette foutue virgule comme séparateur décimal, le reste du monde utilise le point.

Par ailleurs t'as une erreur d'exposant: 9.36146 * powl(10,2) (ou 9.36146 * 100 dans la seconde version) devrait être 9.36146 * powl(10,22) grosse différence...

NB: en principe la convention est de mettre un espace après les virgules séparant les paramètres de fonction; par ex powl(10, 22) au lieu de powl(10,22) c'est plus facile à lire et ça évite de confondre powl(10,22) avec powl(10.22)

NB²: si tu veux rendre le débug plus facile tu peux splitter le calcul et passer par des variables intermédiaires. Ici tu peux facilement extraire la Psat par exemple:

Code :

PSAT := (9.36146 * powl(10,2) * exp(1.511 * powl(10,-9) * powl(TEMP,3) + 3.001 * powl(10,-6) * powl(TEMP,2) - 0.002142 * TEMP - 6999.12 / TEMP)) / powl(TEMP,5.71317)
OUT := 0.6221 / (1 / (HYGRO * PSAT) - 1);

NB³: si jamais le 10^22 est trop grand pour être géré par l'automate, dis-le moi, j'ai une solution

[OrOoX]

Oops, j'avais même pas fait gaffe ...


Après correction des erreurs ça bug toujours à la compilation, j'ai viré les conversions et remis des pow() et non powl() et
là ça fonctionne ... Il me sortait l'erreur que l'exposant n'était pas un nombre, va savoir pourquoi.

Du coup en prod ça sort :

Code :

TEMP 293.149994  := data0011  20.0  + 273.15;
HYGRO  0.5  := data0072  50.0  / 100;
OUT 0.007263  := ANY_TO_REAL(data0084  0.0 );

OUT 0.007263  := 0.6221 / (1 / (HYGRO  0.5  * (9.36146 * pow(10, 22) * exp(1.511 * pow(10, -9) * pow(TEMP 293.149994 ,3) + 3.001 * pow(10, -6) * pow(TEMP 293.149994 , 2) - 0.002142 * TEMP 293.149994  - 6999.12 / TEMP 293.149994 )) / pow(TEMP 293.149994 , 5.71317)) - 1);

Et pour le fun j'ai intégré le calcul moins savant

Code :

TEMP_2  20.0  := data0011  20.0 ;
HYGRO_2  0.5  := data0072  50.0  / 100;
OUT_2 0.007264  := ANY_TO_REAL(data0085  0.0 );

PRESSION_VAP 0.023385  := pow(10, (-2.2138 + ( (7.5526 * TEMP_2  20.0 ) / (239.21 + TEMP_2  20.0 ))));

OUT_2 0.007264  := 0.6221 / (1.013 / HYGRO_2  0.5  / PRESSION_VAP 0.023385  - 1 );

[BiduleOhm]

Et le résultat est correct ?

[OrOoX]

Bah écoute, y a pas vraiment de quoi se plaindre, même l'appli sur mon tel est similaire ( HVAC Calculator Pro )

0°C	10°C	20°C	30°C	40°C	50°C
0.00188	0.003791	0.007263	0.013314	0.023523	0.04037
0.001882	0.003794	0.007264	0.013312	0.023525	0.040409

Merci bien pour le coup de main et les explications en tout cas, tu m'étonne que tu préfère programmer en ligne de code,
c'est un vrai casse tête en blocs pour ce genre de chose ...

Je vais pouvoir continuer ma petite intégration sous forme de fonction, j'ai jamais testé à partir de ST donc à voir.

[BiduleOhm]

Ok, niquel

[Sk_rmouche]

Avec de tels pavés, c'est possible d'avoir ce genre d'échange sur le topic du concerné ? Déjà qu'il avance pas des masses, faudrait pas que le peu de progrès bypasse son topic

[BiduleOhm]

Ben spa moi qui ai posé la question ici

[OrOoX]

Avance pas sur quoi ? En plus y'a pas de sujet c'était pour le boulot


PS : Ma PAC est autonome en refroidissement, chauffage et ECS Monsieur

[BiduleOhm]

[Sk_rmouche]