<p>The temperature readings are point samples which can occur at various depths depending on who took the reading, how they were taken &amp; the conditions at the time when they were taken.</p>
<p>If modeling heat in ocean water is similar to modeling metal content in rocks it is useful to get the average for a particular band, such as 0-10 m, 10-20 m, etc., by way of example. If a reading occurs at 6 m, a second one at 12 m &amp; a third one at 14 m they have to assigned to the correct band &amp; the readings for 12 m &amp; 14 m, if the band interval is 10-20 m, need to be averaged appropriately &amp; one way to do this is to apply weighted averaging to the data so there is only one value for each band.</p>

CC BY-SA 4.0
2021-12-30T11:05:16.430Z
2021-12-30T11:05:16.430Z
Fred
<ol>
<li>You are adding all the heat in the vertical direction. Since your vertical layers have varying depth (as do most ocean/climate models) you need to account for this. Imagine the surface layer has 10 meters depth, and the second layer 20 meters depth. Both contain 100 Joules of heat each. Then, in the first, you have 10 Joules per meter in the vertical. In the second, you have 20 Joules per meter in the vertical. If you only have the specific heat, or the &quot;per meter&quot; value, you will need to multiply by &quot;how many meters&quot; in each layer. It's the same principle.</li>
<li>I'm not aware of a specific OHC routine. But if you are working with NetCDF files, I would strongly recommend you check <a href="https://code.mpimet.mpg.de/projects/cdo/wiki" rel="nofollow noreferrer">CDO</a>, which makes such multiplications much easier to code, keeping the structure of files and applying conventions. In specific, CDO's <a href="https://code.mpimet.mpg.de/projects/cdo/embedded/index.html#x1-4410002.8.11" rel="nofollow noreferrer">vertical sum operator</a> uses depths as weights by default.</li>
</ol>

CC BY-SA 4.0
2022-02-12T01:16:33.557Z
2022-02-12T01:16:33.557Z
ouranos
<p>I have subsurface temperature data for up to 300 m oceanic depth (at varying depth intervals). I want to calculate the ocean heat content for 0-300 m.</p>
<p>The formula is:</p>
<p>OHC = seawater density * Specific heat capacity * integrating the temperature over this depth.</p>
<p>But, the depth is not at the same interval. So I have read that there is a need to use weighted temperature.
I want to ask two questions.</p>
<ol>
<li>Why do we have to use weighted temperature?</li>
<li>Is there any module or code available to do this? So that it will help me to compute the OHC?</li>
</ol>

CC BY-SA 4.0
2021-12-30T05:44:40.257Z
With variable intervals, different temperature data represent different volumes of water.
Poutnik
CC BY-SA 4.0
2021-12-30T15:42:45.033Z
the formula seems to be incomplete; it's dimensionally density · spec. heat capacity · depth = mass / volume · energy / (temperature difference · mass) · (distance difference) · temperature = energy / area, and from a practical point of view it should just be energy. You don't only integrate over depth, you have to integrate over volume.
Marcus Müller
<climate><oceanography><data-analysis><python>
How to calculate Ocean heat content?
Nayan
# How to calculate Ocean heat content?

(Asked by: username_0 on 2021-12-30)

I have subsurface temperature data for up to 300 m oceanic depth (at varying depth intervals). I want to calculate the ocean heat content for 0-300 m.

The formula is:

OHC = seawater density \* Specific heat capacity \* integrating the temperature over this depth.

But, the depth is not at the same interval. So I have read that there is a need to use weighted temperature.
I want to ask two questions.

1. Why do we have to use weighted temperature?
2. Is there any module or code available to do this? So that it will help me to compute the OHC?

**Tags:** climate, oceanography, data-analysis, python

> **Comments:**
> **username_1**: With variable intervals, different temperature data represent different volumes of water.  
> **username_2**: the formula seems to be incomplete; it's dimensionally density · spec. heat capacity · depth = mass / volume · energy / (temperature difference · mass) · (distance difference) · temperature = energy / area, and from a practical point of view it should just be energy. You don't only integrate over depth, you have to integrate over volume.  

---

## 2 answers

### Answer by username_3 on 2021-12-30. Score: 3

The temperature readings are point samples which can occur at various depths depending on who took the reading, how they were taken & the conditions at the time when they were taken.

If modeling heat in ocean water is similar to modeling metal content in rocks it is useful to get the average for a particular band, such as 0-10 m, 10-20 m, etc., by way of example. If a reading occurs at 6 m, a second one at 12 m & a third one at 14 m they have to assigned to the correct band & the readings for 12 m & 14 m, if the band interval is 10-20 m, need to be averaged appropriately & one way to do this is to apply weighted averaging to the data so there is only one value for each band.


---

### Answer by username_4 on 2022-02-12. Score: 1

1. You are adding all the heat in the vertical direction. Since your vertical layers have varying depth (as do most ocean/climate models) you need to account for this. Imagine the surface layer has 10 meters depth, and the second layer 20 meters depth. Both contain 100 Joules of heat each. Then, in the first, you have 10 Joules per meter in the vertical. In the second, you have 20 Joules per meter in the vertical. If you only have the specific heat, or the "per meter" value, you will need to multiply by "how many meters" in each layer. It's the same principle.
2. I'm not aware of a specific OHC routine. But if you are working with NetCDF files, I would strongly recommend you check [CDO](https://code.mpimet.mpg.de/projects/cdo/wiki), which makes such multiplications much easier to code, keeping the structure of files and applying conventions. In specific, CDO's [vertical sum operator](https://code.mpimet.mpg.de/projects/cdo/embedded/index.html#x1-4410002.8.11) uses depths as weights by default.


---

