Vlad,
> On 30. Apr 2023, at 04:09, Vlad A <elf...@gmail.com> wrote:
>
> Hi Robert,
>
> I don't want to spam everybody with my questions, so will send it directly to
> you. The question is rather lengthy cause it require long explanation of how
> did I get there.
I understand your intention but please really use the mailing list for anything
that does not discuss personal matters: Not only possibly more people can help
with an answer (and others typically have means to ignore threads they are not
interested in) but also there is the archive and information can be found there
in the future.
>
> So, I can see, for a long time deco_state was kinda a singleton.
In fact, these were global variables that got bundled away in this structure to
localise them.
> One structure everyone used for deco simulation. Obviously, due to the fact
> that in many cases you want to "roll back" the simulation, there was a system
> in place to save and restore that global state.
> […]
> Ok, with this being said, here's the question itself. Aside from some
> technicalities, plan function gets two instances of deco state. One as ds and
> another as cached_datap, without looking inside I would assume that ds is the
> data we care about. It is initialised with data prior the dive and it will
> have the record of deco state after the dive we plan.
> In the same time, cached data is just a temporary data planner need, cause...
> reasons. So, I would assume this will be completely temporary data functions
> need and both initial and result content of the cache is irrelevant. It will
> be allocated if you pass nullptr.
>
> Right? At least that's what I though. I thought that cache is just and
> artifact caused by limitations of plain-C. It lost its sense to be visible
> outside of planner the moment deco_state stopped being singleton. It's just
> legacy and it has to be removed as unnecessary entity. But looking at the
> code inside of the planner I got confused, cause it's seems both ds and
> cached_datap is used to pass initial state into planner.
>
> Am I right so far?
>
> It's seems, like cache has dual purpose. If you pass nullptr, everything will
> be the way I describe, but if it's initilised, first call of tissue_at_end
> will partially initialise ds with data from cache...
>
> Is it true? and if so, why? It doesn't look like bug, cause roots of this
> behavior are decade long, which make me assume, that's intentional.
> Is it legacy from old times when deco_state was a singleton and cache was the
> only way to pass something into the planner. Do we still want that?
>
> One the other hand, I cannot rull out the posibility it's a bug, cause we
> almost never hit that case. All of existent calls of the plan function, pass
> nullptr as cache so this behavior is not used. Well, all but one case, where
> we calculate variations of the dive. Which was the whole point to drop
> deco_state as singleton in the first place, but I'm not sure how common it's
> is for users to use that feature. At least I heard from multiple people that
> they've seen the check box in the menu but never quite understood what it
> does.
>
> Anyway. Do you have any reasons to keep that cache around, let alone to use
> it for data transfer into planner? Can I just get rid of it and pass all data
> through one structure?
See, it is a cache. Like pretty much all caches, technically, you can get rid
of it. But the price is that things get slower as they have to be recalculated.
To know tissue loadings in a dive, you have to know what the tissue loadings
are at the beginning of a dive from previous dives. This is determined by going
back in time through the divelist (until you hit a 48 hour surface interval)
and sum up the deco data for those dives. This is what init_decompression()
does. Depending on how many dives this involves this can be an expensive
calculation.
When we compute plan variations, we compute deco for five different versions of
the same dive (effectively we compute the partial derivatives of the deco
schedule with respect to the depth and duration of the last manually added leg
of the dive plan which typically will be the bottom segment). This gives the
user information that can easily be turned into „deco on the fly“ type changes
of the dive plan.
Quoting from the Subsurface user manual: "Dive plan variations: The planner has
a check box Display plan variations. By checking this box, the planner provides
information about a dive that is a little deeper or slightly longer than the
planned dive. This is found near the top of the Dive plan details where the
dive duration is indicated. The information is intended to be used if it is
necessary to modify the ascent "on the fly" in the case of unexpected
deviations from the dive plan during the dive. For example, if it says
"Runtime: 123min, Stop times + 2:49 /m + 1:30 /min" this means: if you dive
deeper than planned, you should add almost 3 minutes per meter you go deeper to
your decompression (and you can subtract 3 minutes per meter that you stay
shallower). If you overstay your bottom time, you need to add one and a half
minutes to the stops for each minutes you overstay and similarly, you can
shorten your deco time by one and a half minute for each minute you stay
shorter. These variations of depth and time are based on the last manually
entered segment of the dive (not necessarily the deepest). The additional
minutes should be distributed over the different stops in a way proportional to
the stop length, i.e. add more of the additional minutes to the longer,
shallower stops. The given times refer to the duration of the decompression
phase and do not include the extended bottom time! This way of altering dive
plans becomes inaccurate for large deviations from the original plan. So it
should not be trusted for more than a few minutes or meters of deviations from
the planned bottom time. Checking this option creates a lot of additional
computation, to such a degree that the planner is slower than otherwise.“
We do not want to recompute the tissue loadings from the previous dives when we
have already computed them for a different version of the current dive (which
obviously has the same history). So, this is why we save a snapshot of all
tissue variables at the beginning of the dive to the cache data. It is visible
outside the planner function since planner is called once for each version of
the plan and this information has to persist between calls.
Does this help?
Best
Robert
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
