Re: New Bug Reports/Feature Requests

[Dirk Hohndel]

On Tue, Feb 23, 2016 at 11:18:42PM -0800, Linus Torvalds wrote:
> On Feb 23, 2016 15:46, "Linus Torvalds"  wrote:
> >
> 
> >  (b) air is not actually entirely compressible.
> >
> >  This is a fairly small factor at 3000psi, but it's a factor.
> > HOWEVER. The rule for cylinder sizing is that the stated cylinder size
> > is basically the "theoretical" size, not the real size.
> 
> Actually, doing the math, the compressibility of air is enough to
> bring that 80 cuft down to about 78 cuft. So that may actually be the
> biggest effect.
> 
> We currently approximate the gas volume as being linear below 200 bar,
> and eat that up-to-3% error.
> 
> Maybe we could do better.
> 
> Does somebody have curve fitting software to generate a better
> function for the air compressibility factor? From Wikipedia (staying
> at 300K, which is warm water), we have
> 
>barcompressibility
>------
>  10.
>  50.9987
> 100.9974
> 200.9950
> 400.9917
> 600.9901
> 800.9903
>1000.9930
>1501.0074
>2001.0326
>2501.0669
>3001.1089
>4001.2073
>5001.3163
> 
> and we could probably do better than our current "linear plus
> second-order" approximation.
> 
> Somebody with R (or matlab) could probably get a reasonable curve from
> the above data. With a function for the compressibility factor, we
> could improve on our current "gas_volume()" function.

Robert is the usual suspect for stuff like this :-)

> Of course, we could also just do it the stupid way and do the above
> table and just do linear interpolation in between entries. Sometimes
> simple and stupid is good.

Let's see if Robert comes up with something nice, alternatively we'll go
with segment approximation.

In the meantime I have fixed the rounding issue with weights (and oh boy
did we have a serious bug in there for people big enough to dive with 20kg
or more in weight...)

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: New Bug Reports/Feature Requests

[Linus Torvalds]

On Feb 23, 2016 15:46, "Linus Torvalds"  wrote:
>

>  (b) air is not actually entirely compressible.
>
>  This is a fairly small factor at 3000psi, but it's a factor.
> HOWEVER. The rule for cylinder sizing is that the stated cylinder size
> is basically the "theoretical" size, not the real size.

Actually, doing the math, the compressibility of air is enough to
bring that 80 cuft down to about 78 cuft. So that may actually be the
biggest effect.

We currently approximate the gas volume as being linear below 200 bar,
and eat that up-to-3% error.

Maybe we could do better.

Does somebody have curve fitting software to generate a better
function for the air compressibility factor? From Wikipedia (staying
at 300K, which is warm water), we have

   barcompressibility
   ------
 10.
 50.9987
100.9974
200.9950
400.9917
600.9901
800.9903
   1000.9930
   1501.0074
   2001.0326
   2501.0669
   3001.1089
   4001.2073
   5001.3163

and we could probably do better than our current "linear plus
second-order" approximation.

Somebody with R (or matlab) could probably get a reasonable curve from
the above data. With a function for the compressibility factor, we
could improve on our current "gas_volume()" function.

Of course, we could also just do it the stupid way and do the above
table and just do linear interpolation in between entries. Sometimes
simple and stupid is good.

 Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: New Bug Reports/Feature Requests

[Dirk Hohndel]

On Wed, Feb 24, 2016 at 08:10:04AM +0200, Miika Turkia wrote:
> On Wed, Feb 24, 2016 at 12:52 AM, Dirk Hohndel  wrote:
> > On Tue, Feb 23, 2016 at 01:55:28PM -0500, Richard Houser wrote:
> >> #4 Dives exported from subsurface to divelogs.de are now showing an
> >> additional 0.1lb more than what they show in subsurface.
> >
> > Rounding error somewhere. Silly American pounds.
> 
> Both Subsurface and divelogs.de work in metric units internally. I
> just did a quick test and 5lb turns out to be 2.268 kg in Subsurface
> and is displayed as 2.2 kg on the divelist. Divelogs.de displays this
> as 2.3 kg (as is correct rounding). However, it seems that divelogs.de
> uses this rounded number when displaying the imperial weight (5.1
> lbs). What has changed, I have no idea, but Rainer might be able to
> clarify. (Us showing incorrect metric rounding is irrelevant regarding
> divelogs.de import/export as we use the exact value in calculations
> and export.)

That's odd, Rainer. Why would you convert the rounded value?

I can see where our code is wrong and will fix the rounding on our side.
That's what I get for using the convenient Qt functions instead of doing
the display string conversion by hand :-)

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: New Bug Reports/Feature Requests

[Miika Turkia]

On Wed, Feb 24, 2016 at 12:52 AM, Dirk Hohndel  wrote:
> On Tue, Feb 23, 2016 at 01:55:28PM -0500, Richard Houser wrote:
>> #4 Dives exported from subsurface to divelogs.de are now showing an
>> additional 0.1lb more than what they show in subsurface.
>
> Rounding error somewhere. Silly American pounds.

Both Subsurface and divelogs.de work in metric units internally. I
just did a quick test and 5lb turns out to be 2.268 kg in Subsurface
and is displayed as 2.2 kg on the divelist. Divelogs.de displays this
as 2.3 kg (as is correct rounding). However, it seems that divelogs.de
uses this rounded number when displaying the imperial weight (5.1
lbs). What has changed, I have no idea, but Rainer might be able to
clarify. (Us showing incorrect metric rounding is irrelevant regarding
divelogs.de import/export as we use the exact value in calculations
and export.)

>> #6 Feature Request: Any chance of getting a SAC graph option?
>>
>> I think it would be useful to see where breathing went up, in particular
>> paired with other events there, like timestamped photos and other trackable
>> events.  In particular, on one of my recent dives, I added about 25-30lb of
>> weight on the bottom.  It would be nice to see how much something like that
>> acquisition or chasing an elusive lobster actually cost me in bottom time.
>
> We have that. See other emails.

Yeah, I have been happy enough with the color coding of pressure
graph. Anyway can also see quite precise SAC for any given moment on
the information overlay box on the dive graph. Just hover mouse over
the spot you want the detailed info and look at the Info box.

miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: New Bug Reports/Feature Requests

[Dirk Hohndel]

Everything Linus said is of course correct... small number twister in that
last paragraph:

On Tue, Feb 23, 2016 at 06:53:49PM -0800, Linus Torvalds wrote:
> 
> But with high-pressure cylinders at 300 bar (~3400 psi) it's about

300 bar is ~4300psi (actually, 4351psi)

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: New Bug Reports/Feature Requests

[Linus Torvalds]

On Tue, Feb 23, 2016 at 5:20 PM, Thiago Macieira  wrote:
>
> You can do an isothermal expansion of air, or let the captured air warm back
> up to ambient temperature. Not that I expect people do it.

So that theoretical calculation is exactly what we do to turn the
imperial size into the metric size.

It's how we get 11.1l from 80 cuft.

But as mentioned, it's actually unphysical for various reasons. Not
only isn't air an ideal gas, but "isothermal" is just not realistic in
practice.

At 3000 psi, the ideal gas differences aren't big, but with
high-pressure cylinders (ie 300 bar, so the 4300psi ones) you not only
want to use DIN valves, but the difference between air compression and
the ideal gas compression is actually pretty big - even when doing
isothermal expansion in theory (and isothermal expansion is likely
even harder to get in practice, since the pressure drops are even
bigger).

See for example


https://en.wikipedia.org/wiki/Compressibility_factor#/media/File:Compressibility_Factor_of_Air_250_-_1000_K.png

and follow the black 300K line ("warm water"): it's within a couple of
percent up to ~175 bar (so about 2500 psi), and is still just 3% off
at 3000 psi. For things like SAC rate, even 3% is still largely in the
noise.

But with high-pressure cylinders at 300 bar (~3400 psi) it's about
10%, and keeps rising after that. At that point the errors of not
taking compressibility into account start being noticeable.

  Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: New Bug Reports/Feature Requests

[Thiago Macieira]

On terça-feira, 23 de fevereiro de 2016 15:46:44 PST Linus Torvalds wrote:
>  I don't have any hard data for this, but I think that what the
> true capacity test does is let the air out and measure it. Which,
> thanks to bernoulli's law will actually measure colder air than is in
> the cylinder (air cools down when it expands), which in turn by boyle
> will shrink the air (colder air is denser).

You can do an isothermal expansion of air, or let the captured air warm back 
up to ambient temperature. Not that I expect people do it.

But if they did, that would be a 3000 psi / 1 atm = 204.13x expansion in 
volume

11.1 L * 204.13 = 2265,9 L = 80.02 ft³

This is including the 11.1L of air at 1 atm that was left inside the bottle.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: New Bug Reports/Feature Requests

[Linus Torvalds]

On Tue, Feb 23, 2016 at 2:18 PM, Richard Houser  wrote:
> In my classes back in Michigan, and during checkout dives I witnessed as a
> bystander in Ohio and Florida, instructors with at least 5 different shops
> (SSI/PADI/NAUI) have explicitly reminded students that when doing their
> logs, air capacity in an AL80 is 77cuft, NOT 80.

That's complete bullshit. Sorry. That's an oversimplification of the
problem, and it's an over-simplification to the point of just being
wrong.

The fact is, it depends on the exact manufacturer, but also people are
entirely confused about what "true capacity" is.

For example, a Luxfer AL80 (which is just about the most common one
out there) is a 11.1L bottle ("wet volume", aka "metric size", aka
"not completely buggered and screwed up idiotic imperial units").

That's the only _real_ "true capacity". The wet volume of the cylinder
is the *actual* volume of the cylinder, with no idiotic "air at
rpessure and temperature" effects.

And guess what? When you look at what we translate "AL80" into, that's
*exactly* what we give:

cylinder vol=11.097l workpressure=206.843bar

so our cylinder calculations are 100% correct. We never actually use
"80" in any calculations, except to initialize that metric volume that
we got right.

So we actually use a 11.1 liter volume (and the "workpressure" is
actually immaterial for everything, the _only_ use for that is for the
crazy imperial conversion).

Now, where does that "true capacity" come from? It's some fairly BS
measure that comes from how idiotic the imperial cylinder measurements
are to begin with, and involves a test of how much air you can
actually get out of the cylinder. The difference to actual 80 cuft
seems to come from a few places:

 (a) when you empty a cylinder, it ends up not empty (as in a vacuum),
but full of air at 1 atm.

 So even if there was 80 cuft of air in the cylinder, you won't
get all out of *out* of the cylinder, there will be that 11.1L
(roughly 0.4 cuft) remaining in the bottle.

 It's somewhat unclear whether people use absolute pressure or
gauge pressure for the working pressure, so that 0.4 cuft is actually
debatable, but the "naive" math model (which is what I'd expect the
cylinder sizing to be, considering all the other things going on)
would give you a 0.4 cuft deficit.

So that accounts for part of it, but only 0.4 cuft. Where did the rest go?

 (b) air is not actually entirely compressible.

 This is a fairly small factor at 3000psi, but it's a factor.
HOWEVER. The rule for cylinder sizing is that the stated cylinder size
is basically the "theoretical" size, not the real size.

 As seen before, we actually use the correct _real_ size for a
Luxfer AL80 bottle. Don't believe me? Go look at the Luxfer data
sheets, it really is 11.1 liter wet size. And just turn Subsurface
into metric mode, and you really will see 11.1 liter, not 80 cuft.

So that's another small part of it, but at 3000 psi it's probably not
noticeable. We're (again) talking about fractions of cuft. It gets
much more noticeable with HP cylinders.

 (c) I suspect that the defining *test* for "true capacity" is
somewhat misleading in itself.

 I don't have any hard data for this, but I think that what the
true capacity test does is let the air out and measure it. Which,
thanks to bernoulli's law will actually measure colder air than is in
the cylinder (air cools down when it expands), which in turn by boyle
will shrink the air (colder air is denser).

So when you measure the amount of air coming out of a cylinder, you
are inherently also measuring the effects of a temperature
differential.

In other words, there are several causes of confusion here.

But what you should take away from this is:

 - there's a hell of a lot of confusion about imperial cylinder sizes

 - the people who wrote the code in subsurface do actually know what
they are talking about, to the point where I can pretty much guarantee
that we know _better_ than your poor scuba instructors who just "know"
that the "actual size" of a cylinder isn't the one stamped on it, but
have little idea why.

   Don't get me wrong: I'm not trying to call out the scuba
instructors. They are right, its' just that things are more
complicated, and imperial sizes are laughably crap.

   Dirk actually has a math major, I have just a strong minor in math,
and both of us kind of know the physics. We've actually *cared* about
this issue, because it keeps coming up.

 - subsurface actually does get the calculations right, in that we
only ever use the metric wet volume (11.1l) for real calculations, and
we actually do take both the "cylinder still contains air" _and_ the
"air isn't actually perfectly compressible" into account when we do
our SAC rate calculations.

 - however, subsurface cannot take the temperature differential into
account, so I'm not claiming our math is perfect either. Our math is
_good_, but in the end, you will have to 

Re: New Bug Reports/Feature Requests

[Dirk Hohndel]

On Tue, Feb 23, 2016 at 05:18:52PM -0500, Richard Houser wrote:
> > The weight of the metal changes at least for different manufacturers so
> unless you weight your cylinder, which value are you going to use? The
> weight of the gas is of course always the same.
> 
> Well, the weight of the metal itself isn't so important, but rather the
> bouyancy when switching between tanks.  These are published for each tank,
> however, and they will be in a similar ballpark at least between
> manufacturers.  For example with valve, an empty HP 120 PST is about -1.3,
> Worthington is about -2 and a Faber is -0.65.  Pick a center point and that
> whole range is less than 1lb +/- for the range of tanks.
> 
> My LP72 comes in about neutral, and my AL80 is around +4.4lb.  I just think
> it would be really helpful to have that information on the same equipment
> page with the rest of the weighting, so it's less mental math and manual
> notes to figure out what all went into a dive (including which pony bottle,
> etc.) to adapt that portion of the weighting back to something usable for
> other dives with different details.

And the relative buoyancy is different depending on the manufacturer and
even the year when it was manufactured. So no, you can't just assume that
all AL80 are +4.4lbs (I assume that you are quoting empty buoyancy). E.g.,
the very popular XS Scuba AL80 right now is +3.4lbs empty and -1.4lbs
full.

> > As you see, we indeed use the nominal sizes even though they are not
> exact. We had a discussion in the past (but I am not able to find it either
> in the mailing list archives or trac) if we should use the „real“ values as
> shown on that web page but ended up the conclusion that that would actually
> be even more confusing.
> 
> In my classes back in Michigan, and during checkout dives I witnessed as a
> bystander in Ohio and Florida, instructors with at least 5 different shops
> (SSI/PADI/NAUI) have explicitly reminded students that when doing their
> logs, air capacity in an AL80 is 77cuft, NOT 80.  So, the software's

Just because many people are saying this doesn't make it right.
The XS Scuba tank above is indeed 77.4cuft.
There's a Luxfer that's 78.2cuft. There's an older Luxfer that's 79.8cuft.

Frankly, if you are worried about 3% "incorrect" data - remove the valve,
fill the tank with water, measure the amount of water and use it like a
metric tank.

And oh, btw: don't use ideal gas laws much beyond 200bar because those no
longer apply (and we do take that into account for HP cylinders).

> > A field is only changed when the keyboard focus leaves it (changing it
> with every keystroke would have strange side effects as you would end up
> with strange values in the middle of typing a number). But you can for
> example use the TAB key if you don’t want to change to the mouse.
> 
> This is exactly what I experienced, but I argue that is an aspect of bad UI
> design.  The workaround of clicking or tabbing to another field shouldn't
> be neccessary, IMO.  As a user, when I select save, I expect it to save.

You are confusing "UI design" and "shortcoming in the UI toolkit that we
haven't figured out a way to reliably work around". No, we didn't DESIGN
it that way. It turns out it works that way because no one has figured out
how to fix it. Patches are welcome.

> > My guess is that this is a rounding error: divelogs.de uses metric units
> internally so converting from imperial to metric and back could change the
> least significant digit.
> 
> I agree, but this worked in December with 4.4.2 and divelogs.de at that
> time.  It certainly looks like a regression, but I can go back and confirm
> it's on the Subsurface side by re-exporting old dives in 4.5.3 and 4.4.2
> once I return from my trip and match it up to divelogs.de, if others don't
> see this same behaviour.  If divelogs.de is working in all metric
> internally though, and subsurface is working internally in metric, doesn't
> the fact that divelogs.de still displays the old values correctly indicate
> this is a problem between the subsurface export to divelogs.de?  Perhaps
> one or both sides started using a different precision or something?

We store all data in metric units because the imperial units are
completely braindead, anyway. It's interesting that something changed
there between 4.4.2 and 4.5.3. Something one of the developers could look
into to figure out what might have triggered that. Thanks for the report.

> > Do you realize that the color of the depth graph is already a
> representation of the momentary SAC? Given the resolution of the pressure
> sensor I guess it would make little sense to present finer granularity than
> a color coding (there is only very limited numerical precision).
> 
> I did not (thanks for pointing it out), but my logs (Aeris A300 CS - aka
> Oceanic VTX) seem to imply I have at least 1psi resolution.  I think this
> would be plenty to give a useful graph of the SAC calculations as well as a
> smoothed out 

Re: New Bug Reports/Feature Requests

[Robert Helling]

Richard,

thanks a lot for all your reports/suggestions. I believe I cannot help for many 
of these but here are some comments:

> On 23.02.2016, at 19:55, Richard Houser  wrote:
> 
> First off, I'd just like to say I thin Subsurface is an amazing piece of 
> software and far superior to the proprietary crap manufacturers push out 
> (kodos to you all), so please don't interpret this as a rant by any means. I 
> would have submitted these tickets directly, but the email verification 
> message still isn't coming through from the bug tracker.  If someone was to 
> "validate" this same email that was already confirmed via the mailing list, I 
> could submit these as tickets directly myself
> 
> 
> Anyhow, here they are...
> 
> 
> #1 Using 4.5.3 AppImage, I located a segfault on exporting to divelogs.de 
> .
> 
> Sequence:
> (a) I imported a dive from my computer and then added a location
> (b) I realized I added that location to the wrong dive and removed it, then 
> saved
> (c) any divelogs.de  export containing that dive causes 
> a segfault
> 
> Looking through the XML (which I no longer have - sorry!), it looked like the 
> dive was still associated to a location in the top of the xml, but that entry 
> had no location text.  Shutting down subsurface, deleting that particular id 
> attribute on the dive and then restarting the application let me complete the 
> export.  I would think the correct behavior when someone removes the location 
> text from then Notes tab and saves would be to automatically remove the 
> association with that site entirely.

I was not able to reproduce that here on my Mac.

> #2 The imperial tank sizes appear to have some issues going back to at least 
> 4.4.2
> 
> It looks like someone used to metric tanks may have just taken the names of 
> the cylinders and assumed that matched the capacity?  Sadly our stuff doesn't 
> work that way :(.
> 
> AL80 in particular stood out.  Despite the name, these are ~77.4cuft capacity 
> when filled to working pressure of 3000.  It would be nice if we could get a 
> tenth position added for precision, but the big problem is the bad default.  
> I have to edit each and every dive after selecting AL80 at present.
> 
> The steel tanks seem to have a similar problem, but a subset of the more 
> common sizes just happen to match up.  For example, my Faber XS-120 is close 
> enough to 120 to look like a round off error.  However, things like the HP119 
> are significantly off.  This should give you a good idea what I'm talking 
> about: (ex.): http://www.xsscuba.com/tank_steel_specs.html 
> 
> 
> Older tanks might be a bit more complicated, but at least LP72s (6.9") are 
> still pretty common.  I have one and it's rated at 65cuft at 2250 working 
> pressure - (when over-filled by 10% as allowed by hydro + rating that only 
> some hydro facilities will check and stamped, that gets you up to 71cuft).  
> The default values listed seem to be 2466 psi, which I don't see a reference 
> to anywhere, although it's close to an overfill rating it probably won't 
> trash SAC calculations, but it's still a bit off.  It's definitely not the 
> stamped rated pressure, though.

Let me quote from our source code:

/* Most common AL cylinders */
{ "AL40", .cuft = 40, .psi = 3000 },
{ "AL50", .cuft = 50, .psi = 3000 },
{ "AL63", .cuft = 63, .psi = 3000 },
{ "AL72", .cuft = 72, .psi = 3000 },
{ "AL80", .cuft = 80, .psi = 3000 },
{ "AL100", .cuft = 100, .psi = 3300 },

/* Metric AL cylinders */
{ "ALU7", .ml = 7000, .bar = 200 },

/* Somewhat common LP steel cylinders */
{ "LP85", .cuft = 85, .psi = 2640 },
{ "LP95", .cuft = 95, .psi = 2640 },
{ "LP108", .cuft = 108, .psi = 2640 },
{ "LP121", .cuft = 121, .psi = 2640 },

/* Somewhat common HP steel cylinders */
{ "HP65", .cuft = 65, .psi = 3442 },
{ "HP80", .cuft = 80, .psi = 3442 },
{ "HP100", .cuft = 100, .psi = 3442 },
{ "HP119", .cuft = 119, .psi = 3442 },
{ "HP130", .cuft = 130, .psi = 3442 },

As you see, we indeed use the nominal sizes even though they are not exact. We 
had a discussion in the past (but I am not able to find it either in the 
mailing list archives or trac) if we should use the „real“ values as shown on 
that web page but ended up the conclusion that that would actually be even more 
confusing.

> Adding full/empty buoyancy stats to the cylinder page would be really useful, 
> IMO, as we can't always control what we get with rental tanks.  I was on 
> HP100s one day, AL80s the next, etc.

The weight of the metal changes at least for different manufacturers so unless 
you weight your cylinder, which value are you going to use? The weight of the 
gas is of course always the same.

> #3 When I'm editing the cylinder 

New Bug Reports/Feature Requests

[Richard Houser]

First off, I'd just like to say I thin Subsurface is an amazing piece of
software and far superior to the proprietary crap manufacturers push out
(kodos to you all), so please don't interpret this as a rant by any means.
I would have submitted these tickets directly, but the email verification
message still isn't coming through from the bug tracker.  If someone was to
"validate" this same email that was already confirmed via the mailing list,
I could submit these as tickets directly myself


Anyhow, here they are...


#1 Using 4.5.3 AppImage, I located a segfault on exporting to divelogs.de.

Sequence:
(a) I imported a dive from my computer and then added a location
(b) I realized I added that location to the wrong dive and removed it, then
saved
(c) any divelogs.de export containing that dive causes a segfault

Looking through the XML (which I no longer have - sorry!), it looked like
the dive was still associated to a location in the top of the xml, but that
entry had no location text.  Shutting down subsurface, deleting that
particular id attribute on the dive and then restarting the application let
me complete the export.  I would think the correct behavior when someone
removes the location text from then Notes tab and saves would be to
automatically remove the association with that site entirely.



#2 The imperial tank sizes appear to have some issues going back to at
least 4.4.2

It looks like someone used to metric tanks may have just taken the names of
the cylinders and assumed that matched the capacity?  Sadly our stuff
doesn't work that way :(.

AL80 in particular stood out.  Despite the name, these are ~77.4cuft
capacity when filled to working pressure of 3000.  It would be nice if we
could get a tenth position added for precision, but the big problem is the
bad default.  I have to edit each and every dive after selecting AL80 at
present.

The steel tanks seem to have a similar problem, but a subset of the more
common sizes just happen to match up.  For example, my Faber XS-120 is
close enough to 120 to look like a round off error.  However, things like
the HP119 are significantly off.  This should give you a good idea what I'm
talking about: (ex.): http://www.xsscuba.com/tank_steel_specs.html

Older tanks might be a bit more complicated, but at least LP72s (6.9") are
still pretty common.  I have one and it's rated at 65cuft at 2250 working
pressure - (when over-filled by 10% as allowed by hydro + rating that only
some hydro facilities will check and stamped, that gets you up to 71cuft).
The default values listed seem to be 2466 psi, which I don't see a
reference to anywhere, although it's close to an overfill rating it
probably won't trash SAC calculations, but it's still a bit off.  It's
definitely not the stamped rated pressure, though.

Adding full/empty buoyancy stats to the cylinder page would be really
useful, IMO, as we can't always control what we get with rental tanks.  I
was on HP100s one day, AL80s the next, etc.



#3 When I'm editing the cylinder sizes (and I assume all over the place
elsewhere), I have to enter the tank type, then select the volume, then
make the change, then click off somewhere else unrelated, then save.  If I
leave off that second to last step, then save, it reverts to the old
value.  I think that when a save is attempted, the equivalent field save
action of clicking out should be done automatically in the background so
the last change is not lost.



#4 Dives exported from subsurface to divelogs.de are now showing an
additional 0.1lb more than what they show in subsurface.  My dives as of
early September on 4.4.2 (from Mageia cauldron) are correct, but all dives
I have done this February on 4.5.3 have the extra 0.1lb.  I'm guessing this
subsurface is a regression post 4.4.2, but if it's not obvious, I could
back things up after this trip, delete them from divelogs.de and see what
happens between those two different versions.



#5 Feature Request: Any chance of getting a boat field added?

I'm looking for something like we have for Buddy and Divemaster.  Captain
(in some areas, they bounce around a lot between organizations) or dive
operation/charter organization might be useful too.



#6 Feature Request: Any chance of getting a SAC graph option?

I think it would be useful to see where breathing went up, in particular
paired with other events there, like timestamped photos and other trackable
events.  In particular, on one of my recent dives, I added about 25-30lb of
weight on the bottom.  It would be nice to see how much something like that
acquisition or chasing an elusive lobster actually cost me in bottom time.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: looking for information

[Dirk Hohndel]

On Tue, Feb 23, 2016 at 09:19:07AM +0100, Davide DB wrote:
> Looking back at my email I see I spent a godd effort to design this feature.
> It's a shame nobody found it interesting.

I continue to agree that this is something that I'd like to see
implemented. But I'm already the author of nearly half the commits since
4.5.0 was released (433 out of 878 according to git). So unless other
people step up and work on these things, it's not going to happen.

> In the meantime our loogbooks grow grow grow :)

They do. And soon you'll be able to do all these wonderful things on
Android. And yes, I prioritized Subsurface-mobile on Android ahead of the
statistics.

Finally, to respond to the implied question... Our experience with GSoC to
a) attract new developers who stick around and b) be a net positive when
it comes to contributions to Subsurface has not been great. The additional
work for me to administer the program and for the mentor for this project
would likely better be spend on us just working on Subsurface ourselves.

I know that's disappointing - we had a thread about this where some people
spoke up that they would like to see us sign up again (moot point by now
as the deadline to sign up has passed) - but none of the people suggesting
we should do this volunteered to then be a mentor...

/D

> On 19 February 2016 at 18:12, Tomaz Canabrava  wrote:
> >
> >
> > On Fri, Feb 19, 2016 at 2:56 PM, Iurie  wrote:
> >>
> >> hello,
> >> first of all i would like to know if ur organization is going to try again
> >> to participate in this year GSOC 2016.
> >>
> >> if yes, then i would like to know what is the state of this project idea:
> >> http://trac.subsurface-divelog.org/wiki/Subsurface_GSOC_2015_Idea_List#Divestatistics
> >>
> >> i thank u in advance for the answer
> >> best regards
> >
> >
> > It will not, but why should that stop you by working on the Divestatistics?
> > :)
> >
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: looking for information

[Davide DB]

Looking back at my email I see I spent a godd effort to design this feature.
It's a shame nobody found it interesting.
In the meantime our loogbooks grow grow grow :)

On 19 February 2016 at 18:12, Tomaz Canabrava  wrote:
>
>
> On Fri, Feb 19, 2016 at 2:56 PM, Iurie  wrote:
>>
>> hello,
>> first of all i would like to know if ur organization is going to try again
>> to participate in this year GSOC 2016.
>>
>> if yes, then i would like to know what is the state of this project idea:
>> http://trac.subsurface-divelog.org/wiki/Subsurface_GSOC_2015_Idea_List#Divestatistics
>>
>> i thank u in advance for the answer
>> best regards
>
>
> It will not, but why should that stop you by working on the Divestatistics?
> :)
>
>
>>
>>
>> ___
>> subsurface mailing list
>> subsurface@subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>>
>



-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface