On 12 Nov 2014, at 07:02, Willem Ferguson <[email protected]> wrote:
Willem, > I am quite dumb because I struggle to understand the real detail of what you > are saying. I get the broad message but not the precise implication. After > reading your message a few times here is what I understand against the > context of what I know from the code. It is about the use of variables > plot_data->po2 and plot_data->setpoint. I am insistent that setpoint should > mean the setpoint given to the dive computer and not anything else. To store > a setpoint value in a variable called ppo2 just destroys the > understandability of the code to anyone else. let me put this in a historical context. Before commit eaf6d564874ac838dc4f3cca7a781034ae60ef7f Author: Willem Ferguson <[email protected]> Date: Tue Jun 3 19:21:41 2014 +0200 CCR code: Change to sample structure we supported CCR logs (e.g. from Evolution divers and the like) that did not have O2 sensor logging by specifying a set point. That was stored in sample.po2 Maybe that was not the best name of all for this purpose but everywhere in the code we had pO2 variables mean “set point”. In particular that variable was used to determine the actual breathing gas of the CCR diver. Then, with the above mentioned patch, you introduced a member called o2setpoint. And that was getting the setpoint value but other places in the code, the ceiling calculation in particular, did not recive it anymore as you did not make that o2setpoint aware. The new situation was that we had two variables that would possibly contain the same information (but in reality didn’t). The, a few months later, in email, you wrote Willem Ferguson willemferguson at zoology.up.ac.za Sun Oct 12 09:41:08 PDT 2014 Robert, Attached a screenshot of the present state of the Poseidon CCR dive profile. The ceiling is not correct. Where does the software that draws the ceiling get the information from in order to draw the ceiling? Then I spend a Saturday evening figuring out where this came from resulting in commit 5f44fdd9cf6fba073837cbc1d89c6ed3ea28dd76 Author: Robert C. Helling <[email protected]> Date: Sun Oct 19 07:07:07 2014 -0700 Make planner work again for CCR dives Part of that patch was (maybe that was not the optimal resolution) was to merge the two variables into one. What I did was to rename your o2setpoint variables to po2 so they talked to the old ceiling code and then finally rename the remaing variable _back_ to o2setpoint as I thought that would make it clearer what the meaning of that variable was. What you are now proposing is to at least partially undo this patch. Of course, I agree that po2 and the set point are two different things. But the origin of the confusion is that lacking sensor data the set point is our best guess for po2. And only the Poseidon CCR provides us with sensor data, so in the _bulk_ of the CCR cases they are effectively the same. And by introducing the more sophisticated case of having sensor data you should take care not to break that majority of cases. So when you want to differentiate the two variables again, make sure they contain the same values when sensor data is not available. So feel free to rename the o2setpoint variable to anything (just make sure you rename it everywhere in the codebsae, “Refacetor/rename” is an easy way to do that) for example po2. This way unless sensor data is available it get’s filled by the set point value for all other rebreathers than the Poseidon. Then for the Poseidon you can differentiate between sensor data and set-point setting and introduce code that sets the variable that you just renamed accordingly. Just make sure that for other rebreathers the set-point setting is used as best guess for po2. Best Robert -- .oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO Robert C. Helling Elite Master Course Theoretical and Mathematical Physics Scientific Coordinator Ludwig Maximilians Universitaet Muenchen, Dept. Physik print "Just another Phone: +49 89 2180-4523 Theresienstr. 39, rm. B339 stupid .sig\n"; http://www.atdotde.de
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
