Du choix des bons Gradient Factors (GF) en plongée ...

[iove]

il y a 7 minutes, nics a dit :

Euh... un enseignant qui plonge avec un débutant, il ne plonge pas en solo du coup ?

Si, et en l'expliquant comme ça, les gens comprennent bien généralement  

[LGF]

Il y a 3 heures, emmanuelC a dit :

Qui n'a jamais plongé autrement que selon "les bonnes pratiques" qu'il enseigne à ses élèves ?

 

La plongée solo n'est pas une mauvaise pratique quand on en a les compétences et que c'est fait en prenant les précautions nécessaires, c'est juste interdit en structure en France mais parfaitement légal hors structure dans tous les endroits qui ne l'interdisent pas explicitement.

Je n'en fais pas l'apologie mais je ne m'en cache pas et je n'en dissuade pas spécialement mes élèves, je leur dis juste qu'il faut développer les compétences nécessaires avant de se lancer.

[papiboilo]

Je viens d'utiliser, à sec : https://www.decobuddy.org/fr/planner

Je retrouve que ce planificateur est bien fait.

J'ai aussi comparé avec le planificateur Shearwater Peregrine.

 

Données communes

• Plongée à l'air / 40m 15mn
• Buhlmann ZHL16C / GF 80/80
• Conso par défaut 14L
• CNS de départ 0%
• Pallier sécu désactivé sur Peregrine

 

Petites différences, minimes, probablement liées aux arrondis.

 

https://www.decobuddy.org/fr/planner 

 

 

 

 

Peregrine

 

 

[LGF]

il y a 3 minutes, papiboilo a dit :

Petites différences, minimes, probablement liées aux arrondis.

 

en général les différences sont principalement liées aux vitesses de descente et de remontées qui sont configurées différemment.

[Pan34]

il y a 7 minutes, papiboilo a dit :

 

Données communes

• Plongée à l'air / 40m 15mn
• Buhlmann ZHL16C / GF 80/80
• Conso par défaut 14L
• CNS de départ 0%
• Pallier sécu désactivé sur Peregrine

 

 

 

 

 

A noter que palier de secu activé ou pas dans son calcul de DTR en mode planification il ne tient pas compte des palier de secu.

 

Désolé c'est ma marotte en ce moment 

[papiboilo]

il y a 4 minutes, Pan34 a dit :

 

A noter que palier de secu activé ou pas dans son calcul de DTR en mode planification il ne tient pas compte des palier de secu.

 

Désolé c'est ma marotte en ce moment 

 

Effectivement

 

 

 

Modifié le 3 novembre 2023 par papiboilo

[JMarcB]

Il y a 2 heures, LGF a dit :

 

en général les différences sont principalement liées aux vitesses de descente et de remontées qui sont configurées différemment.

 

Pour ceux que les sources de différences intéressent, le billet du blog d'un des auteurs de subsurface donne une idée de ce qui peut intervenir :  https://thetheoreticaldiver.org/wordpress/index.php/tag/buhlmann/

[McLean]

il y a 37 minutes, JMarcB a dit :

 

Pour ceux que les sources de différences intéressent, le billet du blog d'un des auteurs de subsurface donne une idée de ce qui peut intervenir :  https://thetheoreticaldiver.org/wordpress/index.php/tag/buhlmann/

 

En dehors du fait d'être un homme splendide et d'écrire un excellent blog, Robert a une très bonne compréhension des mathématiques et de la mise en œuvre de ZHL. Néanmoins, il (et donc les simulations subsurfaces) a tort quand il écrit :

 

Citation

So, in  a strict sense, for this diver, GFlow never applies (or only at the surface). Of course, this does not really make sense and thus, to avoid this paradox, in Subsurface we use the deepest ceiling encountered during the dive as the anchor depth for GFlow 

 

 

 

L'utilisation du plafond instantané pour ancrer le GFlow dans le contexte d'un ordinateur de plongée entraîne une instabilité numérique. À la place, il faut utiliser le plafond de remontée.

 

Modifié le 3 novembre 2023 par McLean

[whodive]

Il y a 5 heures, papiboilo a dit :

J'ai aussi comparé avec le planificateur Shearwater Peregrine.

sur le peregrine t"es en mode multigaz pour faire cette simulation ?

[JMarcB]

Il y a 1 heure, McLean a dit :

L'utilisation du plafond instantané pour ancrer le GFlow dans le contexte d'un ordinateur de plongée entraîne une instabilité numérique. À la place, il faut utiliser le plafond de remontée.

 

C'est quoi exactement ce que tu appelles plafond de remontée? Je n'ai cru comprendre (*) l'utilisation d'un GFlow dans un ordi (en opposition à de la planification où c'est clair depuis plus longtemps) qu'après avoir lu son blog que parce que

lier le GFlow au plafond le plus bas comme il dit me semble éviter beaucoup de questions avec des profils plus ou moins tordus? Du plafond le plus bas on déduit des bandes de profondeur ou on ne peut pénétrer qu'avec certains GF.

 

(*) au sens où je vois comment le programmer sans être certain de ne pas me poser des questions en plus quand enfin je m'y tenterai. 

[McLean]

il y a 5 minutes, JMarcB a dit :

 

C'est quoi exactement ce que tu appelles plafond de remontée? Je n'ai cru comprendre (*) l'utilisation d'un GFlow dans un ordi (en opposition à de la planification où c'est clair depuis plus longtemps) qu'après avoir lu son blog que parce que

lier le GFlow au plafond le plus bas comme il dit me semble éviter beaucoup de questions avec des profils plus ou moins tordus? Du plafond le plus bas on déduit des bandes de profondeur ou on ne peut pénétrer qu'avec certains GF.

 

(*) au sens où je vois comment le programmer sans être certain de ne pas me poser des questions en plus quand enfin je m'y tenterai. 

 

Le plafond instantané est celui calculé par l'équation de Buhlmann, modifié par GF low :
 
pambtol = (pt - gf * a) / (gf / b - gf + 1.0f)

 

Si on utilise ça directement on tombe sur les cas où on a un plafond non zéro mais, dû à la saturation ou désaturation pendant le temps de remontée, on calcul la charge en gaz on arrive à la surface sans jamais atteindre le plafond. Le symptôme de ça est que on arrive à la fin de la NDL (calculée en fonction de l'instant où il y a un plafond) puis soit il faut attendre quelques minutes avant de voir apparaître des paliers soit on a immédiatement quelques minutes de paliers. Certains des ordinateurs Mares ont ce problème, il me semble.

 

Pour éviter ce problème il faut calculer le plafond de remontée ; le profondeur du plafond pendant la remontée en tenant compte de la saturation et désaturation pendant cette remontée.

 

Le code de subsurface utilise une double approximation dans la mesure où il place GFlow au plafond instantané et il utilise la forme analytique pour ce calcul même en présence des gaz ternaires.

 

Dans tous les, Robert a raison de toujours garder le plus profond des plafonds calculés pendant la plongée.

 

[JMarcB]

il y a 37 minutes, McLean a dit :

Le plafond instantané est celui calculé par l'équation de Buhlmann

 

Merci, je n'avais pas pensé à cela. Il va falloir que j'y réfléchisse et trouve des exemples pour être sûr d'avoir compris. J'ai déjà une question supplémentaire:

 

il y a 38 minutes, McLean a dit :

soit il faut attendre quelques minutes avant de voir apparaître des paliers soit on a immédiatement quelques minutes de paliers

 

N'est-ce pas (en plus du problème d'instabilité ci-dessus) un des effets de GFlow plus petit que GFhigh?  On n'a rien jusqu'à ce que GFhigh soit atteint en surface, alors GFlow entre en jeu et s'il est suffisamment bas on pourrait avoir de suite des paliers à 9m sans que ce soit la profondeur minimale de palier utilisée. (GFlow plus grand que GFhigh a l'effet inverse: on retarde l'arrivée du palier de 6m)

 

il y a 43 minutes, McLean a dit :

Dans tous les, Robert a raison de toujours garder le plus profond des plafonds calculés pendant la plongée.

 

Merci de confirmer. C'était ça que je croyais que tu remettais en cause et qui m'interrogeait. Cette incompréhension a été utile, j'ai un nouveau sujet de réflexion.

 

Note que j'ai un problème théorique avec les histoires de prise de seuils figés (présents aussi de ce que j'ai compris du blog dans VPM); je préférerais qu'on ajuste carrément la pente des Mfactor sans avoir besoin de choisir un point de référence (ce que j'ai compris que le [Dr Doolittle tente de faire avec son choix de GFlow=0.83 GFhigh](https://gue.com/blog/gradient-factors-in-a-post-deep-stops-world/), il a l'air de vouloir un surpression critique constante plutôt qu'affine en fonction de la pression ambiante).

[papiboilo]

Il y a 1 heure, whodive a dit :

sur le peregrine t"es en mode multigaz pour faire cette simulation ?

Oui, je me suis mis en mode Multi gaz : 1gaz 21%

puis ensuite il y a toujours le menu planification, et il apparaît après ce menu, un autre menu qui est planification déco

 

[McLean]

il y a 11 minutes, JMarcB a dit :

 

N'est-ce pas (en plus du problème d'instabilité ci-dessus) un des effets de GFlow plus petit que GFhigh?  On n'a rien jusqu'à ce que GFhigh soit atteint en surface, alors GFlow entre en jeu et s'il est suffisamment bas on pourrait avoir de suite des paliers à 9m sans que ce soit la profondeur minimale de palier utilisée. (GFlow plus grand que GFhigh a l'effet inverse: on retarde l'arrivée du palier de 6m)

 

 

En fait, les calculs sont plus stables avec GFlow superieur à GFhi.

 

Voici les Pigtol ZHL purs. Les Pigtol baissent gentiment vers leur valeur le plus contraignant en surface :

 

 

 

Avec des GFs 30/80 et un premier palier à 9m on voit tres clairement une bizarrerie sur le compartiment 5' ou le Pigtol augment legerement pendant la remontée avant de retomber à la meme valeur en surface qu'à 9m.

 

 

Et en 80/30 les Pigtols baissent comme dans ZHL pur mais avec plus de conviction :

 

[JMarcB]

@McLean intéressant.  Tu prends un GFlow suffisamment bas et tu peux même avoir un Pigtol en surface plus grand que celui au premier palier. En pratique, je suppose que les compartiments directeurs ne sont pas de ceux où ces effets sont possibles, surtout qu'ils changent vers du plus lent.

 

Amusant aussi si tu ne calcules plus le Pigtol par morceau mais avec la même formule qu'après le premier palier, il doit être sous la pression ambiante en-dessous d'une certaine profondeur.

 

En passant, je présume que l'inflexion à 10m plutôt qu'à 9m c'est parce qu'en fait les graphes sont pour un premier palier à 10m, est-ce que je me trompe?