Olá,

gostava de realizar um poll sobre quais softwares de planeamento são usados para o mergulho técnico aqui pelo pessoal do Forum.

Era possivél abrir uma poll para os seguintes softwares:

VPlanner
HLPlanner
ProPlanner
DecoPlanner
GAP
Outros

Cumprimentos

Compreendo o teu objectivo final, e deixa-me já dizer-te à partida que todos os modelos com VPMe (e nunca uses VPM sem ser o e), ABM e os Buhlman com Deepstops são todos iguais.

VPMe e ABM produzem prefis iguais e iguais ao Proplanner a 110% de conservadorismo. Softwares com RGBM teoricamente deviam produzir perfis mais "rapidos" mas visto existirem algumas variaveis empiricas que são introduzidas manualmente softwares de descompressão que o utilizem podem inclusivé ser mais "lentos".

Eu tenho 4 softwares de descompressão que utilizo para criar perfis que por vezes ajusto tendo em conta outra variaveis (como as paragens certas na altura certa com o gás certo)

HLPlanner
VPlanner
Decocheck
GAP

Tudo as ultimas versões, especialmente a do Decochek...

Eu utilizo dois softwares, o GAP e o Vplaner um usa Buhlman (GAP) e o Outro VPM.
por norma tenho seguido os planos do GAP. MAs considero que o Vplaner é tb muito bom, mas sinto-me mais à vontade com os calculos efectuados no GAP.
Ambos ultima versão

Boas,

em relação ao VPlanner vs HlPlanner, se tivérmos o safey factor a +2 no Vplanner e a 5% no HLPlanner, ainda não vi diferenças nas duas aplicações. Visto que o HLPlanner é gratuito e baseado no mesmo algoritmo, para já, para quê pagar pelo VPlanner?

As diferenças entre os softwares começam muitas vezes em mergulhos mais profundos e com mais tempo de fundo.
A diferença entre uma versão gratuita e uma versão paga é a responsabilização.
O facto de ser baseado no mesmo algoritmo não quer dizer que a solução seja a mesma. A forma como progaramaram o software vai fazer variar os resultados, erros obtidos.. Julgo que tu entendes bem o que quero dizer.
MAs no final a vida é tua e es tu que decides o que queres fazer, ou confias ou não confias no software.

Este post foi editado por jmascarenhas: Feb 8 2007, 12:05 PM

Ao contrário do que diz o jmascarenhas, eu não acho que seja uma questão de "confiança".

Existem algoritmos que são implementados. Essa implementação pode ter como é natural muitas diferenças, depende do "geek" que for escrever o programa e da maneira como gosta de programar.

Depende tambem do nivel de ajuste que o programa permite. Até agora dos que vi o Decocheck é o mais user friendly, e ao usar o ABM torna-se a meu ver muito fiavél.


O que é importante é conheceres não só a "filosofia" por trás de cada algoritmo, como os porquês de cada implementação. A biblioteca online da DIR Portugal é bastante completa e pode dar-te uma ideia dos vários algoritmos.

Todos eles estão disponiveis on-line, geralmente a pagantes, ou há sempre um amiguito que tem. Não são muito caros até porque são papers de universidades. Lê, e decide.

No fim vais ver que em vez de confiança, é mais gestão de risco. Isto se quiseres ir pelo caminho do auto conhecimento, podes sempre fazer um curso onde te darão estas informações já todas devidamente digeridas prontas para consumo.

Cul,

em relação à implementação do algoritmo, eu discordo, pois se o algoritmo é o mesmo, por mais diferente que seja o código, o resultado tem de ser o mesmo... se assim não fosse, estavamos lixados, e falo por experiência própria que trabalho com dezenas de "developers". Eu não conheço o algoritmo de uma forma descascada, mas o que posso presumir é que este algoritmo tem alguns "seeds", que podem ser inicializados com valores diferentes conforme decisão do developer... e aí sim.. pode dar valores bastante diferentes.
A escolha da linguagem de desenvolvimento também pode influenciar o resultado, mas mais na base de suporte a cálculos de alta resolução fráccionária... Imagina que uma certa linguagem só tem suporte para números reais com 3 algarismos após a virgula, e outra suporta 20... obviamente após centenas de cálculos com arredondamento somente a 3 algarismos, podemos ter valores muito diferentes em relação aos cálculos de precisão.

Isso seria verdade, se o teu algoritmo fosse algo simples e sem "variaveis" empiricas (por exemplo o RGBM tem cerca de 11).

Como são implementadas depende do programador. Não é a questão de escreveres ou não a equação em VB, C++ ou Fortram90 é a questão de como lidas com os valores empiricos...

Erros de Floating Point devido à implementação não me parecem sequer possiveis porque vamos trabalhar com inteiros no maximo na casa dos segundos e no maximo ao metro. E estamos no sec XXI caramba.

Cul,

foi o que eu disse. Chamei-lhe foi "seeds". Estes "seeds" (variaveis) podem ser inicializados de forma diferente por cada "developer", pois como dizes, este algoritmo tem partes "empiricas" como lhes chamas.




Eu não disse que possam existir erros na implementação a nivél de floating point, mas por exemplo, em C, se usares float ou double, após milhares de iterações, vê o resultado de um tipo de variavél e do outro. Imagina que o resultado no float é 3,144523343 e no double é 3,144523349. Agora se no algoritmo, tivessemos de multiplicar este resultado por 1.000.000.000? No caso do float, tinhas 3144523343 e no caso do double, tinhas 3144523349. Esta diferença é relativa, dependendo do enquadramento, mas se queres a maior precisão, o que escolhias?

O que eu quero afirmar, é que na implementação, as coisas que podem ser diferentes são:
- Inicialização de variáveis "empiricas"
- Escolha do tipo de variáveis (int, float, double, double float, etc)
- Escolha da linguagem de programação. Um int no C pode ter 32 bits, e na linguagem XPTO ter somente 16 bits. Depende da implementação da própria linguagem de desenvolvimento, e muitas vezes, até do próprio compilador. Tens compiladores de C, em que o int tem 32bits, e outros que só tem 16bits, e a linguagem é a mesma.

Cada modelo de descompressão tem subjacente uma ideia que se traduz numa ou mais equações.
Num ou noutro raro caso (RGBM e bulk model são os que me ocorrem de momento) a resolução numérica das equações exige umas "luzes" de análise numérica.
Dou de barato esse crédito ao Wienke e aos consultores do Hempleman.

Mas na maioria dos modelos é virtualmente impossível fazer implementações algoritmicamente instáveis - tudo são equações algébricas analiticamente resolúveis.
No caso do VPM e do RGBM é até típico utilizar-se sempre o mesmo código de cálculo(!).
O source do VPM é público. Vê no site do Maiken em Basic, Fortran e Mathematica.

As diferenças que se observam entre implementações do mesmo modelo são geralmente *voluntárias* e devem-se aos parâmetros secundários, cuja alteração é vista como uma "melhoria" no sentido da segurança.
Exemplos serão a tensão de vapor de água nos pulmões, a variação de pressão atmosférica entre o início e o fim do mergulho, tolerância a erros no profundímetro, na análise dos gases, na execução dos patamares, etc.
Toda a gente tem ideias próprias sobre isto.


Não tenho uma recomendação para dar. Não sei qual o melhor modelo ou o mais seguro, ou o mais testado. Duvido que alguém saiba.

Assim creio que a maioria dos que mergulham nos limites do recreativo faz planeamento(!) de um ou dois modos:
1) compara os perfis de diferentes softwares e modelos;
2) vai introduzindo a sua própria sensibilidade, preferindo este ou aquele software e até alterando ad-hoc os perfis obtidos, porque se "sente melhor".

Contudo o risco dos modelos XPTO, softwares, computadores, rebreathers e similares é levarem a pensar-se que existem soluções tecnológicas para os problemas mais importantes do mergulho. Não há.
A popularização recente do mergulho técnico obriga a repensar estratégias de ensino.
Não é possível exigir níveis absurdos de experiência prévia e não são eficazes as estratégias obscurantistas ou de demonização.
O que é eficaz é melhorar a qualidade dos instructores e dos cursos.
O que é eficaz é os mergulhadores superarem-se em pequenas doses, reavaliando criticamente cada mergulho.

João

Eu, como já disse noutro topico, acho que vai sempre haver dois tipos de mergulhador. Os que querem saber os porquês, e os que vão confiar no equipamento. (e quando digo equipamento quer dizer os computadores de mergulho, ou tabelas geradas por softwares de descompressão).

Acho que é justo dizer que neste momento ambas as soluções estão muito perto do numero minimo de acidentes possiveis (e que a unica maneira de realmente evitar um acidente descompressivo é ficar em casa).

Tambem acho que quem quer saber, vai à procura, e encontra. Não só formação como informação. Acho é que sendo o mergulho um actividade para todos não podemos esperar que todos queiram saber aprofundadamente de descompressão. É como nos demonstraste e bem nas conferência um tema imensamente vasto e com variadas incognitas que temos de saber gerir a nivél pessoal, se o quiseremos.

Mas tambem acho que quem quer seguir um "modelo" e os perfis por ele gerados sem se preocupar tambem o deve puder fazer.

Não fazia ideia que o codigo do VPM e RGBM eram iguais...

Desculpa, expliquei-me mal.
Nas implementações do VPM usa-se quase sempre o código original do Maiken (o VPM-B não está no site).
Nas implementações do RGBM usa-se sempre (uma excepção) o código do Wienke.

De acordo contigo no restante.

João