• Sign In
  1. Requests

Total Area MS1 differs slightly from sum of MS1 areas

support

View Request

view list print
Total Area MS1 differs slightly from sum of MS1 areas Tobi  2019-03-25 03:51
 

Dear Skyline team,

sry to add to this topic but I sadly could not find this exact problem in the forum. It is more for understanding than an actual problem.

When calculating the total Area MS1 myelf in Excel and via Pivot (Sum of Areas) the number differs slightly from the Total Area MS1 from the results grid but the difference is more than what I would expect from rounding errors.

Quant is set to MS1 and DDA and Product Ions are non-quantitative (and I excluded product ion areas from the pivot sum of areas).

Is this behaviour expected or are some settings wrong? Do you have a recommendation on how to retrieve the area of a peptide as the sum of all charges and isotopes?

Thank you very much for the great support
tobi
 
 
Nick Shulman responded:  2019-03-25 11:31
The numbers look correct to me.
Here's my Excel spreadsheet with the areas that I got. The TotalAreaMS1 really is the sum of the areas of the Quantitative transition results.

Are you maybe confused because TotalAreaMS1 is on the Precursor Result and you were hoping to get a total area at the Peptide level?

On the peptide result, there is a column called "Normalized Area". That area gets normalized based on whatever setting you have in:
Settings > Peptide Settings > Quantification
If you don't have any normalization specified then it is the area summed across the precursors.

-- Nick
 
Tobi responded:  2019-03-25 12:31
Dear Nick,

thank you very much for the fast response.

I took your excel file and i find the same issue again, hopefully now better illustrated and without any normalization as before. The sum of Areas is not exactly the same as the total Area MS1 but very close to it. However, the difference is much larger than +-1, so how does this occur?

The key is that the sum of Total Area MS1 for 3 Charge states is also different to your pivot table.

in general such a relativly small difference does not matter, but it would be nice to know why there is a difference larger than +-1 (up to 200) to see under which circumstances this might cause an actual error.


Best regards,
tobi
 
Nick Shulman responded:  2019-03-25 12:46
Oh. The peak areas are stored in the .skyd file as 4 byte ("single precision") floating point numbers. That gives you only about 8 decimal digits of precision.

The way that we calculate the Total Area MS1 could have been more precise, but we did not write the code that way. The more precise way to do this would have been to use 8 byte numbers for the intermediate calculation of the sum, but we are still just using 4 bytes for the running total. As a result, we end up with an even less precise final result.

We did not expect anyone to care about the precision of these numbers that much. It would probably be straightforward to improve on this.
-- Nick
 
Tobi responded:  2019-03-25 13:24
Dear Nick,

thank you very much, knowing where the difference comes from and that the sum of areas is more precise already solves the issue. (I was concerned some other feature was set incorrectly).

Thank you for taking a look on this but from my point of view this does not seem to be urgent.


Best,
tobi