Poseidon CCR dives: Nitrogen loading

[Willem Ferguson]

On 05/11/2014 20:55, Robert C. Helling wrote:
>
> On 05 Nov 2014, at 17:37, Willem Ferguson 
> <willemferguson at zoology.up.ac.za 
> <mailto:willemferguson at zoology.up.ac.za>> wrote:
>
> Willem,
>
>> 1) This patch has an unintended consequence: The ending cylinder 
>> pressure for the diluent cylinder (as seen on the equipment tab) is 
>> changed to reflect that of the ending pressure of the oxygen 
>> cylinder. The diluent cylinder index for the Poseidon diluent is the 
>> dreaded and infamous 1. We hardcode the cylinder IDs here while 
>> reading in the dive log because it is very specific to the Poseidon. 
>> In addition, even though these specific two cylinders have already 
>> been assigned to enum values of oxygen and diluent respectively, we 
>> are in the process of setting up the cylinders, so we cannot already 
>> use the functions that use these enum values.
>> So: dive->cylinder[1].sample_end.mbar for this sample dive has a 
>> value of 141, that of the oxygen cylinder. The correct ending value 
>> for this variable is 137. I have carefully looked around the code 
>> around line 600 in file.c but cannot see the cause of this problem. 
>> Run the code with and without your patch and see the difference.
>
> my suspicion is that something fishy is going on in gas pressures.c in
> populate_pressure_information
> and the functions called from there. Right now, I am not able to 
> follow the logic with diluent handling there but maybe, since you 
> wrote that, you can more easily debug this (figure out when the 
> different gases are actually used) than me.
>
> BTW, I think the prototypes should be in header files and not in profile.c
>
> Best
> Robert
Thanks for the comment, Robert. There is a debug function in profile.c 
called debug_print_profiledata() that prints out the final results of 
everything to do with cylinder pressures (and o2 partial pressures) and 
the output produced there is correct. The start and end pressures of the 
cylinders are accurate, as they should be. By this I am not saying that 
the error is not there, but the problem is not systemic. I am continuing 
to check there....
Kind regards,
willem

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20141105/3de0c649/attachment.html>