I think that currently first_stop is being calculated for each stop (so
isn't actually first_stop) rather than just the first. That's what it
looked like from my limited running under gdb with a break every time
first_stop is calculated, and printing the depth variable.
To calculate the
On 17 August 2015 at 19:46, Jan Darowski jan.darow...@gmail.com wrote:
I think that currently first_stop is being calculated for each stop (so
isn't actually first_stop) rather than just the first. That's what it
looked like from my limited running under gdb with a break every time
I think I've worked out at least one difference in the programs' algorithms,
and sorry I doubt you'll like it. Subsurface calculates required stops
considering the ascent rate and the time to reach the stop. The Fortran
program calculates the 'instantaneous' ceiling, i.e. the depth
On 18 Aug 2015 12:13 am, Jan Darowski jan.darow...@gmail.com wrote:
I think I've worked out at least one difference in the programs'
algorithms,
and sorry I doubt you'll like it. Subsurface calculates required stops
considering the ascent rate and the time to reach the stop. The Fortran
Hi Jan,
On 17 August 2015 at 20:59, Rick Walsh rickmwa...@gmail.com wrote:
On 17 August 2015 at 19:46, Jan Darowski jan.darow...@gmail.com wrote:
I think that currently first_stop is being calculated for each stop (so
isn't actually first_stop) rather than just the first. That's what it
On Mon, Aug 17, 2015 at 06:41:03PM +0200, Jan Darowski wrote:
2015-08-17 17:54 GMT+02:00 Robert C. Helling hell...@atdotde.de:
Hi,
On 17 Aug 2015, at 15:44, Rick Walsh rickmwa...@gmail.com wrote:
Which approach is more justified? Debatable. The method used by Subsurface
should be
DIrk,
On 15 Aug 2015, at 16:11, Jan Darowski jan.darow...@gmail.com wrote:
Here is my next pull request,
this is definitely progress and nothing is obviously wrong (modulo what was
said in this thread, so please pull:
ACK by me.
There are some things to work on, but this gets easier, once
Hi,On 17 Aug 2015, at 15:44, Rick Walsh rickmwa...@gmail.com wrote:Which approach is more justified? Debatable. The method used by Subsurface should be 'better', but when the depth of the first stop/ceiling is given a special significance thanks to the Boyles law compensation process, I'm not so
On 17 Aug 2015, at 18:41, Jan Darowski jan.darow...@gmail.com wrote:
In my opinion we shouldn't leave this as a preference, it's to
technical and complicated to explain to most of users. We have the
conservatism levels already, so users can manipulate how aggressive
their schedule is.
2015-08-17 17:54 GMT+02:00 Robert C. Helling hell...@atdotde.de:
Hi,
On 17 Aug 2015, at 15:44, Rick Walsh rickmwa...@gmail.com wrote:
Which approach is more justified? Debatable. The method used by Subsurface
should be 'better', but when the depth of the first stop/ceiling is given a
Hi,
I've looked at and tested your latest series of VPM-B commits. From what I
can see, it looks like it's doing the correct thing, except that
first_stop_pressure is reset to zero every iteration, so it then gets set
each stop (rather than just at the first stop) before running the Boyle's
Hi Jan,
On 17 Aug 2015 12:32 am, Jan Darowski jan.darow...@gmail.com wrote:
Hi,
I've looked at and tested your latest series of VPM-B commits. From
what I
can see, it looks like it's doing the correct thing, except that
first_stop_pressure is reset to zero every iteration, so it then
Hi Jan,
On 16 August 2015 at 00:11, Jan Darowski jan.darow...@gmail.com wrote:
Hi!
Here is my next pull request, it adds all the remaining vpm-b
elements. What is left to code is some way of logged dives rating
against vpm-b and probably some fixes.
I've looked at and tested your latest
Hi!
Here is my next pull request, it adds all the remaining vpm-b
elements. What is left to code is some way of logged dives rating
against vpm-b and probably some fixes.
The following changes
since commit 342479586d1f34a2b7f3d1d69037cb0d631489fa:
Planner: use the heap for note buffers
Dirk, Jan,
On 5 July 2015 at 23:56, Dirk Hohndel d...@hohndel.org wrote:
On Sat, Jul 04, 2015 at 12:27:23AM +0200, Jan Darowski wrote:
Hi,
Here is another pull request. I hope now it's better. Everything was
reorganized from scratch, the final code is almost the same.
I like the patches
On Sat, Jul 04, 2015 at 12:27:23AM +0200, Jan Darowski wrote:
Hi,
Here is another pull request. I hope now it's better. Everything was
reorganized from scratch, the final code is almost the same.
I like the patches much better.
I agree with Robert that you could have squashed a couple
Hi,
On 4 July 2015 at 18:29, Jan Darowski jan.darow...@gmail.com wrote:
eh... from deepocean.net: 7500 fsw min = 250 bar min
It's not the first mistake I found there. And it seems that the author
of existing
c code based his implementation on this site also.
I multiplied 7500 fsw by 0.304
Hi,
On 04 Jul 2015, at 10:29, Jan Darowski jan.darow...@gmail.com wrote:
I guess I need to implement Boyle's law as soon as possible and only
test against
the original fortran code...
just a brief comment: Indeed testing against other code is quite essential (not
only since our software
Hi,
On 04 Jul 2015, at 11:23, Rick Walsh rickmwa...@gmail.com wrote:
I multiplied 7500 fsw by 0.304 (feet to metres) divided by 10 (metres salt
water to ata) and multipled by 1.01325 (ata to bar).
7500 * 0.304 / 10 * 1.01353 = 231.021 bar
It's close, but I think my conversion was very
On Sat, Jul 04, 2015 at 10:29:17AM +0200, Jan Darowski wrote:
Thanks for checking it.
But then I checked the configuration parameters adopted, and there are
differences. I altered vpmb_config to match what was used in the Fortran
code.
critical radius of N2 was 0.6, changed to 0.8
On Sat, Jul 04, 2015 at 07:23:12PM +1000, Rick Walsh wrote:
I multiplied 7500 fsw by 0.304 (feet to metres) divided by 10 (metres salt
water to ata) and multipled by 1.01325 (ata to bar).
7500 * 0.304 / 10 * 1.01353 = 231.021 bar
It's close, but I think my conversion was very slightly out,
Hi, here is the link to the results of some tests I did.
https://docs.google.com/spreadsheets/d/1jrafQsE9bwHLszJadYzRlD2zBD57UB7TIAh2Xz0o-XQ/edit?usp=sharing
Some comments:
As you can see the are some cases when results differ.
Test 4: starting gradients are the same, final gradients differ a lot.
On 30 Jun 2015 10:01 p.m., Robert C. Helling hell...@atdotde.de wrote:
I second all of Dirk’s suggestions (of course, how could I?) and should
maybe point out (as I learned this only very recently) that
git rebase —interactive
and
git add -p
are both extremely useful when rewriting
Dirk: fine, I agree that these commits aren't of the highest quality.
One of the reasons is that this work is based in huge part on the
existing implementation which I had to discover part by part and which
has a lot of strange solutions (including units and constants scaled
all the time). The
On Tue, Jun 30, 2015 at 12:02:08AM +0200, Jan Darowski wrote:
Hi, here is the request for the basic vpm algorithm. Right now it
doesn't include Boyle's law compensation so the deco plans it
generates can be too short in some situations.
Jan, thanks for sending this. I have asked Robert to look
Hi Jan,
On 30 Jun 2015, at 15:38, Dirk Hohndel d...@hohndel.org wrote:
Jan, thanks for sending this. I have asked Robert to look at the code from
the algorithmic side, but let me give you some general feedback in
addition to the comments that I made on github:
I have pulled your patches
Hi, here is the request for the basic vpm algorithm. Right now it
doesn't include Boyle's law compensation so the deco plans it
generates can be too short in some situations.
The following changes since commit f763da66b3db17347954272b9f856df6f8b9888d:
Implement planner option to switch only
27 matches
Mail list logo
