The max Y value of the partial pressure graph grid tends to be way too
high when only pO2 or pHe is enabled.
Signed-off-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
With Pierre-Yves' commit with a map widget, here are a couple of example
GPS locations from my own dives.
Signed-off-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For each dive recorded, place their GPS coordinates onto a map using the
OSM-GPS-MAP library.
This map is accessible via the "log" menu or the shortcut ctrl+M (M as map).
We check for the GPS coordinates "0, 0" which are the default when we do not
have real GPS coordinates set.
[Dirk Hohndel: fixed int/float math confusion, fixed some whitespace and
coding style issues, cleaned up some comments, added a
missing cast to prevent a compiler warning]
Signed-off-by: Pierre-Yves Chibon <pingou@pingoured.fr>
Signed-Off-By: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
.. and add the usual logic to not save the default values.
This also simplifies the initial system-specific setup of both of these:
since we have defaults for all the preferences that get set up at
startup, we can just initialize those defaults to the system-specific
fonts then and there.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Testing the new "don't even bother saving default values" showed that the
default values for the deco gradient factors were undefined.
Or rather, they were over-defined.
We had defaults for the UI (30 and 75 for GFlow/GFhigh respectively - the
config ones are in percent), *and* we had defaults in deco.c for the deco
code itself (0.35 and 0.75 respectively - in deco.c they are represented
as fractions, not percent).
And if the config entries had never been written, and were assumed to be
the defaults, the UI code thought the defaults were 30/75, but they had
never been *set* to those defaults, so actual default calculations
silently used the 35/75 in deco.c, which is very confusing (you could go
to the preferences page, see the 30/75 there, and it would not actually
match th evalues used for computation).
Of course, with an old config file that saves even default entries, you'd
never see that if you ever changed anything in the preferences, because
you'd always have explicit gflow/high values. But now it's much easier to
see the conflicting default values.
Fix it by just always using the UI defaults (or set values) to set the
actual deco values.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Loading an xml file with dive computer information without any
preexisting nickname data would try to "remember" that NULL nickname.
Causing a SIGSEGV if there was no nickname information.
The bug was introduced by commit ec38d3708d ("Move device_info handling
into a new 'device.c' file") when I inadvertently removed a bit too much
code. It actually wants to remember a missing DC nickname as an empty one.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This does the "don't save defaults" for numeric values too.
Also, move the preferences loading/saving to a new "prefs.c" file.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
A new file download-dialog.c now contains all code related
to the download dialog, which was previously defined in gtk-gui.c.
Also, a new file callbacks-gtk.h now has two macros
OPTIONCALLBACK, UNITCALLBACK shared only between
download-dialog.c and gtk-gui.c.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The old code (on purpose) didn't try to differentiate "nonexisting
boolean configuration" with "existing boolean configuration set to
false", which is problematic if we optimize the saving to not save
default preferences at all.
Which this does.
So in addition to the logic to know about default preferences, this has
to change the interfaces for the PREF_BOOL reading code so that you can
tell the difference between "no value" and "false".
And since the previous calling convention was an abomination of doing
pointer casting and having case-statements for the config types, change
that while at it. Both from a usage perspective *and* from a back-end
perspective it is actually much simpler to just have different functions
for the string vs boolean config read/write versions. The OSX versions
in particular end up being one-liners.
(The GConf library is a nightmare, and doesn't seem to have any way to
know whether a boolean value exists or not, so you have to read it as a
GConfVal and then turn it into a gboolean rather than just get the "oh,
it didn't exist" as an error value).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes it explicit what the default preferences are, so that we can
more easily avoid unnecessarily saving default settings. It also makes
imperial metrics the default for the US (Burma and Liberia always get
forgotten!)
Right now we tend to be somewhat confused about defaults. We do have
them, but then even if something has a default value, we tend to write
it out to the config file. Which is not just unnecessary, but makes it
really hard to see after-the-fact whether the user actually wanted that
*specific* value, or whether they just wanted the default behavior.
So this prepares for having explicit configuration for when we want
something different than the defaults.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
.. and rename the badly named 'output_units/input_units' variables.
We used to have this confusing thing where we had two different units
(input vs output) that *look* like they are mirror images, but in fact
"output_units" was the user units, and "input_units" are the XML parsing
units.
So this renames them to be clearer. "output_units" is now just "units"
(it's the units a user would ever see), and "input_units" is now
"xml_parsing_units" and set by the XML file parsers to reflect the units
of the parsed file.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This moves the point where GF_low applies up which implies that at all
shallower depth (i.e. during deco) a lower GF results which makes the deco
longer compared to the previous implementation.
Of course, "GF_low" applies at first deco stop is a bit tricky since the
depth of the first deco stop again depends on GF_low, i.e. there is
another equation to solve. You can do this by inverting the equation for
the ambient pressure and use GF_low as the gradient factor. This yields
amb = (b * M_value_corrected - GF_low * a * b) / ((1-b) * GF_low + b)
Signed-off-by: Robert C. Helling helling@atdotde.de
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It turns out that the serial number returned by libdivecomputer isn't
really the serial number as interpreted by the vendor. Those tend to be
strings, but libdivecomputer gives us a 32bit number.
Some experimenting showed that for the Suunto devies tested the serial
number is encoded in that 32bit number:
It so happens that the Suunto serial number strings are strings that have
all numbers, but they aren't *one* number. They are four bytes
representing two numbers each, and the "23500027" string is actually the
four bytes 23 50 00 27 (0x17 0x32 0x00 0x1b). And libdivecomputer has
incorrectly parsed those four bytes as one number, not as the encoded
serial number string it is. So the value 389152795 is actually hex
0x1732001b, which is 0x17 0x32 0x00 0x1b, which is - 23 50 00 27.
This should be done by libdivecomputer, but hey, in the meantime this at
least shows the concept. And helps test the XML save/restore code.
It depends on the two patches that create the whole "device.c"
infrastructure, of course. With this, my dive file ends up having the
settings section look like this:
<divecomputerid model='Suunto Vyper Air' deviceid='d4629110'
serial='01201094' firmware='1.1.22'/>
<divecomputerid model='Suunto HelO2' deviceid='995dd566'
serial='23500027' firmware='1.0.4'/>
where the format of the firmware version is something I guessed at,
but it was the obvious choice (again, it's byte-based, I'm ignoring
the high byte that is zero for both of my Suuntos).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The legacy nickname wrappers (that use the device_info structure) are
left in gtk-gui.c. We can slowly start moving away from them, we don't
want to start exporting that thing as some kind of generic interface.
This isn't a pure code movement - because we leave the legacy interfaces
alone, there are a few new interfaces in device.c (like "create a new
device_info entry") that were embedded into the legacy "create nickname"
code, and needed to be abstracted out.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We'll start recording more than just nicknames in it, like serial
numbers and firmware version etc. Start off just renaming it, and
re-ordering the members to reflect how the nickname is not the primary
issue.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We have several places where we interpolate the depth based on two
samples and the time between them. Some of them use floating point, some
of them don't, some of them meant to do it but didn't.
Just use a common helper function for it. I seriously doubt the floating
point here really matters, since doing it in integers is not going to
overflow unless we're interpolating between two samples that are hours
apart at hundreds of meters of depth, but hey, it gives that rounding to
the nearest millimeter. Which I'm sure matters.
Anyway, we can probably just get rid of the rounding and the floating
point math, but it won't really hurt either, so at least do it
consistently.
The interpolation could be for other things than just depth, but we
probably don't have anything else we'd want to interpolate. But make the
function naming generic just in case.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This change ended up being quite a bit bigger than expected as it
uncovered a number of bugs in the existing code.
The planner now handles gas changes correctly by creating (and later
parsing) events in the simulated divecomputer. At the end of the dive
specified in the input form the algorithm starts with the deepest
interesting depth: either the first stop below our ceiling or the deepest
depth at which we can change gases. It then traverses all the stop and all
the gas change depth and at each stage ensures that we are allowed to
ascend further before going on.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
An entry with no time is considered special and not considered when
constructing the profile.
This should allow us to add support for two different ways of adding
information about available gas:
changedepth 0 gasmix
0 0 gasmix @ po2
The first syntax basically says "during the ascent, switch to this gas at
this depth.
The second one says "switch to this gas once the pO2 allows for it"
Neither of these are implemented, yet, but this commit is necessary in
order for the rest of the code to ignore entries with a time field of 0.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In commit d163a68ac69e "Clean up the rewritten deco.c" I apparently made
one more change than I intended - I changed the last deco stop back to 3m
instead of allowing the smooth mode to go all the way back to 0 without
any discrete steps.
This fixes that mistake.
Reported-by: Robert C. Helling <helling@lmu.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This commit makes sure we have a reasonable default surface pressure (we
need an input field for that).
It also adjusts the debug level settings so that compiling this with
make CLCFLAGS=-DDEBUG_PLAN=3
will print out an almost usable dive plan.
This is of course still lacking air consumption calculations and will show
deco stops that we just transit through (if the ceiling lifts far enough
during the transition to an intended stop that this stop can be skipped;
this sometimes happens for the first stop (haven't seen it for a later
one). But it's better than nothing, I guess.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We may want to make this configurable, but I haven't seen any software
that doesn't do deco stops in full minutes.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The existing code incorrectly started all calculation at the depth at the
end of the first segment. So if you went to 50m in 5min in your first
segment, you incorrectly got 5 minutes at 50m (instead of a progression
from 0 to 50m, over 5 minutes).
This commit fixes that and now gives us planned dives that then match what
is shown in the profile.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This shouldn't change the the actual stops we do or the travel time how we
get there, but it makes the code more logical. From the end depth of the
planned dive we have ONE transition to the first stop depth (which may be
the surface). And then for every stop we (potentially) have a wait and
travel to the next stop.
Once we are in the while loop, we know that we are at a stop level, so
there is no point to keep checking if we first need to transition to the
stop.
It does create one additional improvement: if we don't need any stops at
all, then we don't transition to the first stop and then from there to the
surface. We do it in one step. The overall profile / traveltime remains
the same, we just drop one intermediate sample on the way.
This also improves a few ugly (and in one case, wrong) debug statements.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Commit c92e4535a6de "Prevent time travel in planner dive edit" almost got
it right but had a stupid think-o. This commit should fix it the right
way. If the duration that is passed in is before the previous timestamp,
then this is most likely intended to be a relative time.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
While one might argue that multiple samples with the same time are 'odd'
that still shouldn't be an excuse to incorrectly reset the ceiling value
for them back to 0.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Not sure about the future of the current planner.c as we have new
approaches now but as this annoyed me for some days now I just decided
to come up with this trivial stuff to make my life easier.
More a cosmetic fix than a patch, but actually it fixes a bug one might
face planing a dive using low oxygen mixes and where stop levels at just
90m, 60m, 30m and nothing in between will not allow subsurface to finish
a deco ceiling which ends before the universe collapses. Allows to plan
20min@130m using a 10/70 now (f.i.).
Signed-off-by: Jan Schubert / Jan.Schubert@GMX.li
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In commit a7902f279a57 "Rewrite of the deco code" Robert kept the old code
that he replaced around; I removed all that as it's in the git history if
we ever need to look at it again but doesn't really help us in the file as
it is.
I also removed constants, variables and config parameters that aren't used
in the new implementation and did some coding style / formatting changes
to make deco.c more consistent with the rest of Subsurface. I also updated
the comments at the top of the file to reflect reality.
I did one change that actually affects the code. In the explanation of his
changes Robert said that gf_low_pressure_this_dive is initialized to the
exquivalent of 20m, yet his code added the surface pressure twice. I
decided to change the default config value from 3 (bar) to 2 so that this
indeed reflects (about) 20m (as in the code below surface_pressure is
added to this value).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
o) Instead of using gradient factors as means of comparison, I now use
pressure (as in: maximal ambient pressure).
o) tissue_tolerance_calc() now computes the maximal ambient pressure now
respecting gradient factors. For this, it needs to know about the
surface pressure (as refernce for GF_high), thus gets *dive as an
argument. It is called from add_segment() which this also needs *dive
as an additional argument.
o) This implies deco_allowed_depth is now mainly a ambient-pressure to
depth conversion with decorations to avoid negative depth (i.e. no deco
obliation), implementation of quantization (!smooth => multiples of 3m)
and explicit setting of last deco depth (e.g. 6m for O2 deco).
o) gf_low_pressure_this_dive (slight change of name), the max depth in
pressure units is updated in add_segment. I set the minimal value in
buehlmann_config to the equivalent of 20m as otherwise good values of
GF_low add a lot of deco to shallow dives which do not need deep stops
in the first place.
o) The bogus loop is gone as well as actual_gradient_limit() and
gradient_factor_calculation() and large parts of deco_allowed_depth()
although I did not delete the code but put it in comments.
o) The meat is in the formula in lines 147-154 of deco.c. Here is the
rationale:
Without gradient factors, the M-value (i.e the maximal tissue pressure)
at a given depth is given by ambient_pressure / buehlmann_b + a.
According to "Clearing Up The Confusion About "Deep Stops" by Erik C.
Baker (as found via google) the effect of the gradient factors is no
replace this by a reduced affine relation (i.e. another line) such that
at the surface the difference between M-value and ambient pressure is
reduced by a factor GF_high and at the maximal depth by a factor
GF_low.
That is, we are looking for parameters alpha and beta such that
alpha surface + beta = surface + gf_high * (surface/b + a - surface)
and
alpha max_p + beta = max_p + gf_low * (max_p/b + a - max_p)
This can be solved for alpha and beta and then inverted to obtain the
max ambient pressure given tissue loadings. The result is the above
mentioned formula.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The dive will start with gas 0. If things change during the planned part
of the dive, this will be represented by an event. Use the last gas for
the ascent.
Obviously this still doesn't handle deco gases, but at least we now no
longer switch back to the first gas after the planned part of the dive.
This also adds quite a bit of debugging code to be able to trace what's
happening in the planner.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Stupid Gtk. Seriously. So in order to get a notification if the user
selects the drop down for the gas with the mouse I need to connect to the
"changed" signal for the combobox. But that also fires whenever the user
types something into the GtkEntry. Which means we once again get called
for all kinds of silly partial names.
Instead we want to handle the manual entry in the "focus-out" callback
(the user has hit tab or something else to move away from the GtkEntry -
let's assume that this is the text he wants us to use) and only respond to
the changed signal on the combobox if the user selected something from the
dropdown.
The easiest way to do that (I think) is to check the text with the strings
stored in the model. If this indeed matches a string stored in the model
then most likely this is something the user selected from the dropdown.
But more importantly if it isn't in the model, then we KNOW that this is
just a partial string that was typed in. And we can ignore that one.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the user enters an absolute time that is before the previous waypoint,
silently assume that this is a relative time.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
A strange and buggy dive where time goes backwards (right now easy to
create with the dive plan editor) can cause us to run out of plot info
elements.
This prevents that from causing memory corruption by refusing to go back
in time.
Reported-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We do want to compare "loose" dives too, but we need to be a bit
careful, and always use the trip date as the primary sort key for any
dives that are not in the same trip.
Reported-and-tested-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Good night.
Here is the corrected patch. It would need to be tested in other
languages because of the size of the units string in imperial.
It performs well in spanish and (I supose) in english, but if a language
make grow the string it could easily be wrapped and make a mess.
On Mon, Jan 07, 2013 at 10:50:31AM -0800, Dirk Hohndel wrote:
>
> Thanks. I appreciate your patience with this. I'm very happy for every
> contibutor we have and I am especially happy to have someone working on
> the print layout code.
>
Thaks to all of you, Dirk, for all your efforts in the gui, the deco, the
planner ... That's the real hard work.
Regards.
Salva.
From 51dace93a1dae68960fee2229d4f274e8e4543fd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Salvador=20Cu=C3=B1at?= <salvador.cunat@gmail.com>
Date: Mon, 7 Jan 2013 22:58:09 +0100
Subject: [PATCH] Add SAC to the printout
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
- Add the SAC to the printout, displacing the less utils OTUs.
- Substitute repetitive math operations with variables.
- Correct bad translations (correct with *0.90 scaling).
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This simplifies the dive planning code by:
- allowing empty gas mixes (which means "pick previous gas")
- avoiding unnecessary strdup/free calls (this requires us to handle
"const char *" in the parsers, but that was already true from a code
standpoint, just not a type one)
- re-use the "plan()" function for a successful dive plan, rather than
open-coding the dive plan segment handling.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This appears to happen if we have impossible dive sequences in the
dive_list (i.e., merging XML files from two different divers with
overlapping trips).
We need to fix the underlying cause for this issue (i.e., only pick the
'right' dives to calculate the residual tissue saturation), but at least
this code prevents the hang in an infinite loop.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
First, I forgot to pass in the idx into the gas callback function - this
way for the dynamically created dives we always used air for anything but
the first segment.
Second, when selecting a gas from the drop down (with the mouse or by
typing), the GtkEntry doesn't receive that text and therfore we never
picked up those gases.
We now also track the 'changed' event for the GtkComboBox, but never add
the text we get their to the completions (as by definition they are
already there).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
There should be NO other changes in this commit - just moving the code and
adjusting the includes (and adding the entry point to display-gtk.h).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This was just a crutch to get something out there for people to play with.
With the ability to input a plan in place this is now obsolete.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When incrementally building dives with gas changes there are still some
serious issues and inconsistencies. But at least now the gases in the dive
we create appear to be correct.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Now that the pressure_time calculations are done in our "native"
integer units (millibar and seconds), we might as well keep using
integer variables.
We still do floating point calculations at various stages for the
conversions (including turning a depth in mm into a pressure in mbar),
so it's not like this avoids floating point per se. And the final
approximation is still done as a fraction of the pressure-time values,
using floating point. So floating point is very much involved, but
it's used for conversions, not (for example) to sum up lots of small
values.
With floating point, I had to think about the dynamic range in order
to convince myself that summing up small values will not subtly lose
precision.
With integers, those kinds of issues do not exist. The "lost
precision" case is not subtle, it would be a very obvious overflow,
and it's easy to think about. It turns out that for the pressure-time
integral to overflow in "just" 31 bits, we'd have to have pressures
and times that aren't even close to the range of scuba cylinder air
use (eg "spend more than a day at a depth of 200+ m").
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I fixed the pressure-time calculations to use "proper" units, but
thinking about it some more, it turns out that units don't really
matter. As long as we use the *same* unit for calculating the
integral, and then re-calculating the step-wise entries, the units
will cancel out.
So we can simplify the "pressure_time()" function a bit, and use
whatever units are most natural for our internal representation. So
instead of using atm, use "mbar".
Now, since the units don't matter, this patch doesn't really make much
of a difference conceptually. Sure, it's a slightly simpler function,
but maybe using more "natural" units for it would be worth it. But it
turns out that using milli-bar and seconds has an advantage: we could
do all the pressure_time integral using 32-bit integers, and we'd
still be able to represent values that would be equivalent to staying
at 24 bar for a whole day.
This patch doesn't actually change the code to use integers, but with
this unit choice, we at least have that possibility.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This splits up the function to create the estimated pressures for
missing tank pressure information.
The code now has a separate pass to create the beginning and ending
pressures for segments that lack them, and fill them in to match the
overall SAC-rate for that cylinder.
In the process, it also fixes the calculation of the interpolated gas
pressure: you can see this in test-dive 13, where we switch back to the
first tank at the end of the dive. It used to be that the latter
segment of that cylinder showed in a different color from the first
segment, showing that we had a different SAC-rate. But that makes no
sense, since our interpolation is supposed to use a constant SAC-rate
for each cylinder.
The bug was that the "magic" calculation (which is just the pressure
change rate over pressure-time) was incorrect, and used the current
cylinder pressure for start-pressure calculation. But that's wrong,
since we update the current cylinder pressure as we go along, but we
didn't update the total pressure_time.
With the separate phase to calculate the segment beginning/ending
pressures, the code got simplified and the bug stood out more.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The code was using bar, not atm to calculate the pressure_time
multiplier. But SAC-rate is relative to atm.
We could do the correction at the end (and keep the pressure_time in
"bar-seconds"), but let's just use the expected units during the
integration. Especially since this also makes a helper function to do
the calculations (with variables to keep the units obvious) instead of
having multi-line expressions that have the wrong units.
This fixes what I thought were rounding errors for the pressure graphs.
They were just unit confusion.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
