<p>After my original answer, and some back and forth in the comments, turns out I got the answer right by a bit of fools luck, and we sorted it out...</p>

<p>The thing is, despite flux being commonly thought of in physics as <a href="https://betterexplained.com/articles/flux/" rel="noreferrer">BetterExplained.com suggests</a>:</p>

<blockquote>
  <p>Timing: We measure flux at a single point in time. Freeze time and ask
  “Right now, at this moment, how much stuff is passing through my
  surface?”. If your field doesn’t change over time, then all is well.
  If your field does change, then you need to pick a point in time to
  measure the flux.</p>
</blockquote>

<p>But, fairly counter-intuitively to many, meteorological models often, despite naming their variables as flux (such as sshf... <strong>s</strong>urface <strong>s</strong>ensible <strong>h</strong>eat <strong>flux</strong>), actually store them as <strong>accumulations</strong>.  <a href="https://www.ecmwf.int/sites/default/files/radiation_in_mars.pdf" rel="noreferrer">This ECMWF whitepaper</a> on archive data specifications explains:</p>

<blockquote>
  <p>Physical fluxes archived by the ECMWF model are accumulated since the
  start of the relevant forecast, and therefore in units of
  $\mathrm{Jm^{−2}}$ (or $\mathrm{W m^{−2}\cdot s}$).  Thus, a daily
  mean (in $\mathrm{W m^{− 2}}$) is obtained by retrieving the
  accumulated fluxes at $\mathrm{t_1=t}$ and $\mathrm{t_2=t}+ \mathrm{24\;hours}$ (where
  $\mathrm{t}$ is the time of the start of the average), taking the difference
  and dividing by 86400, the number of seconds in a day.</p>
</blockquote>

<p>So, though intuitively, you might think the surface sensible heat flux at 6 hours would just be the sshf variable in the 6 hour file, it isn't.  To get the best estimate of the flux, you'd need to calculate it as:</p>

<p>$$\mathrm{\frac{fluxvar_{(this\;timestep)} - fluxvar_{(previous\;timestep)}}{timestep_{(in\;hours)}\cdot3600}}$$</p>

<p>So if you want to find the average flux between hours 3 and 6, you'd do:</p>

<p>$$\mathrm{\frac{fluxvar_{(t=6hr)} - fluxvar_{(t=3hr)}}{3\cdot3600}}$$</p>

<p>A couple of questions that Vidhi asked about that may be worthwhile understanding to others:</p>

<ol>
<li>Why did the website quoted show the calculation as $\mathrm{({fluxvar_{(t=6hr)} - fluxvar_{(t=3hr)})/10800}}$, but not $\mathrm{({fluxvar_{(t=3hr)} - fluxvar_{(t=0hr)})/10800}}$... instead just using $\mathrm{{fluxvar_{(t=3hr)}}/10800}$

<ul>
<li>Because indeed, in this strange accumulation form $\mathrm{fluxvar_{(t=0hr)}}$ by definition is zero.  The variable may or may not exist in the $\mathrm{t=0hr}$ file, but if it does, it should be pointless to include as it had better be 0 if it is indeed accumulation.</li>
</ul></li>
<li>The site quoted only mentions hours 3, 6, 9, and 12.  I have 15, 18, and 21 as well, how do I deal with this?

<ul>
<li>The same math applies... but remember, if you're dealing with forecast model archive (rather than reanalysis data), you want to use the shortest future hour possible.  So actually, rather than use 00Z's $\mathrm{t=12hr}$, you want to be using 12Z's $\mathrm{t=0hr}$, such that, when calculating the 9Z to 12Z flux average, best is$\mathrm{({fluxvar_{(12Z\;t=0hr)} - fluxvar_{(00Z\;t=9hr)})/10800}}$.  Because you only need steps 0, 3, 6, and 9 before the next archived model/reanalysis file (for a twice a day model), the 12/15/18/21 values really are the 0/3/6/9 values (just from the next model run).</li>
</ul></li>
</ol>

<p>Anytime derived values (variables that aren't in the model itself, but require a formula to determine) need calculating, such as total surface heat flux, just make sure that when you combine the variables (in this case the shortwave, longwave, sensible, and latent heats), you only divide by the timestep once (don't divide by 10800 in the separate input variables beforehand, then divide by 10800 again after combining them).</p>

<p>The models are strange to many.  I just happened to incorrectly remember what a flux was, and get the "divide by 10800" math right (probably in part due to horror memories of working with similar files in years gone by!).  But hopefully this helps some confused people!  </p>

CC BY-SA 3.0
2017-05-27T12:19:27.267Z
+1. The fluxes end up being defined this way because numerical model time is discrete, so the fluxes during a period are what shift the model from a state at time _t_ to another state at time _t+1_.  In the limit of the model timestep going to zero, time becomes continuous and fluxes become instantaneous like the traditional physics definition.
Deditos
CC BY-SA 3.0
2017-05-28T07:55:50.503Z
@Deditos And yet (correct me if I'm wrong on any of these things!) the actual temporal resolution [appears to be 15 minutes](https://ghrc.nsstc.nasa.gov/uso/ds_docs/tcsp/tcspecmwf/ECMWFUserGuideofForecastProductsm32.pdf)... and we do instantaneous windspeed at each output, despite it likewise being fundamentally just a derivative of a variable over time? (Perhaps has something due to usage of spectral functions [way over my head!], or because wind is in the primitive equations??) But glad to get a few thoughts on it, and that's the way I've thought too, though it still doesn't add up totally.
JeopardyTempest
CC BY-SA 3.0
2017-06-01T08:53:29.290Z
Well, the instantaneous windspeed thing is less high level than that.  When you apply the basic conservation laws (mass, momentum, energy) to a fluid continuum you end up with system of differential equations that solve for a handful of state variables, including the flow velocity field, e.g., _u(x, t)_.  In a loose sense, you can think in terms of a velocity/density state subject to mass and momentum fluxes.  Sort of.
Deditos
CC BY-SA 3.0
2017-06-01T15:56:30.957Z
@Deditos Alright, sounds reasonable enough at least, sounds like where I was going with those thoughts.  Of course the question becomes in model output, why can't they just divide out the 3 hours (or whatever timestep) and provide average flux?  I guess since it'd just lead to extra work, when a few people may rather want a 6 hr or 12 hr or 24 hr averaged flux.  But seems a clearer variable name (ACCUMULATED flux in the variable name\abbreviation) would be less confusing for folks new to the models :-)  Thanks for taking the time to discuss though, you added very useful insight.
JeopardyTempest
CC BY-SA 3.0
2017-05-26T07:19:34.473Z
2017-05-26T12:05:11.507Z
2017-05-26T12:05:11.507Z
JeopardyTempest
<p>Referring to the post: </p>

<p><a href="https://www.myroms.org/forum/viewtopic.php?f=30&amp;t=3003" rel="nofollow noreferrer">https://www.myroms.org/forum/viewtopic.php?f=30&amp;t=3003</a></p>

<p>I understood how to calculate the slhf and sshf for 03, 06, 09 and 12 time steps. But I have values for 00, 15, 18 and 21 time steps as well. If the accumulated fields have base time for forecast values at 00:00:00 and 12:00:00, then how average values for 00, 12, 15, 18 and 21 time steps are calculated. I need average flux values for every 3-hour.</p>

<p>Thanks for your inputs. </p>

CC BY-SA 3.0
2017-05-26T06:50:44.613Z
What fluxes do you have and what fluxes are you trying to calculate?
JeopardyTempest
CC BY-SA 3.0
2017-05-26T06:53:57.780Z
It may be useful to know where you downloaded from (looks like ERA Interim's website only offers out to 12 hours?)
JeopardyTempest
CC BY-SA 3.0
2017-05-26T07:55:29.677Z
Thanks Jeopardy. I downloaded from their website itself like it is told in the reference link I posted above. Time- 00:00 and 12:00 and all time steps. So, it gave me 8 files for each day. I need radiation and latent and sensible heat fluxes basically.
Windy Day
CC BY-SA 3.0
2017-05-26T08:48:46.130Z
Thanks for finally understanding the problem. That's what I thought that flux basically should be instantaneous values. But then I stumbled across this: https://www.researchgate.net/post/Whats_wrong_with_ERA_INTERIM_sensible_and_latent_heat_flux

I need to compare ERA-interim flux values with flux tower data which records flux data at every 10 minutes. 3-hour is the best resolution I can get in ERA-Interim. I compared ERA values directly with flux tower values, but they were not matching up at all.
Windy Day
CC BY-SA 3.0
2017-05-26T11:05:59.697Z
yes, thanks a ton. Now I finally understand. I just divided the values by 10800 and now its fine. Also, I needed to multiply by -1 as downwards is positive in ERA-Interim. Thank you so much for your help and your patience. Have a great day !
Windy Day
CC BY-SA 3.0
2017-05-26T12:06:35.937Z
I removed some earlier comments I made that may have caused confusion, and are now properly reflected in my answer.
JeopardyTempest
<climate><weather-forecasting><atmospheric-radiation><reanalysis><era>
How to calculate 3-hour flux values in ERA-Interim?
Windy Day
# How to calculate 3-hour flux values in ERA-Interim?

(Asked by: username_0 on 2017-05-26)

Referring to the post:

<https://www.myroms.org/forum/viewtopic.php?f=30&t=3003>

I understood how to calculate the slhf and sshf for 03, 06, 09 and 12 time steps. But I have values for 00, 15, 18 and 21 time steps as well. If the accumulated fields have base time for forecast values at 00:00:00 and 12:00:00, then how average values for 00, 12, 15, 18 and 21 time steps are calculated. I need average flux values for every 3-hour.

Thanks for your inputs.

**Tags:** climate, weather-forecasting, atmospheric-radiation, reanalysis, era

> **Comments:**
> **username_1**: What fluxes do you have and what fluxes are you trying to calculate?  
> **username_1**: It may be useful to know where you downloaded from (looks like ERA Interim's website only offers out to 12 hours?)  
> **username_0**: Thanks Jeopardy. I downloaded from their website itself like it is told in the reference link I posted above. Time- 00:00 and 12:00 and all time steps. So, it gave me 8 files for each day. I need radiation and latent and sensible heat fluxes basically.  
> **username_0**: Thanks for finally understanding the problem. That's what I thought that flux basically should be instantaneous values. But then I stumbled across this: https://www.researchgate.net/post/Whats_wrong_with_ERA_INTERIM_sensible_and_latent_heat_flux  I need to compare ERA-interim flux values with flux tower data which records flux data at every 10 minutes. 3-hour is the best resolution I can get in ERA-Interim. I compared ERA values directly with flux tower values, but they were not matching up at all.  
> **username_0**: yes, thanks a ton. Now I finally understand. I just divided the values by 10800 and now its fine. Also, I needed to multiply by -1 as downwards is positive in ERA-Interim. Thank you so much for your help and your patience. Have a great day !  
> **username_1**: I removed some earlier comments I made that may have caused confusion, and are now properly reflected in my answer.  

---

## 1 answers

### Answer by username_1 on 2017-05-26. Score: 5 | Accepted answer

After my original answer, and some back and forth in the comments, turns out I got the answer right by a bit of fools luck, and we sorted it out...

The thing is, despite flux being commonly thought of in physics as [BetterExplained.com suggests](https://betterexplained.com/articles/flux/):

> Timing: We measure flux at a single point in time. Freeze time and ask
> “Right now, at this moment, how much stuff is passing through my
> surface?”. If your field doesn’t change over time, then all is well.
> If your field does change, then you need to pick a point in time to
> measure the flux.

But, fairly counter-intuitively to many, meteorological models often, despite naming their variables as flux (such as sshf... **s**urface **s**ensible **h**eat **flux**), actually store them as **accumulations**. [This ECMWF whitepaper](https://www.ecmwf.int/sites/default/files/radiation_in_mars.pdf) on archive data specifications explains:

> Physical fluxes archived by the ECMWF model are accumulated since the
> start of the relevant forecast, and therefore in units of
> $\mathrm{Jm^{−2}}$ (or $\mathrm{W m^{−2}\cdot s}$). Thus, a daily
> mean (in $\mathrm{W m^{− 2}}$) is obtained by retrieving the
> accumulated fluxes at $\mathrm{t\_1=t}$ and $\mathrm{t\_2=t}+ \mathrm{24\;hours}$ (where
> $\mathrm{t}$ is the time of the start of the average), taking the difference
> and dividing by 86400, the number of seconds in a day.

So, though intuitively, you might think the surface sensible heat flux at 6 hours would just be the sshf variable in the 6 hour file, it isn't. To get the best estimate of the flux, you'd need to calculate it as:

$$\mathrm{\frac{fluxvar\_{(this\;timestep)} - fluxvar\_{(previous\;timestep)}}{timestep\_{(in\;hours)}\cdot3600}}$$

So if you want to find the average flux between hours 3 and 6, you'd do:

$$\mathrm{\frac{fluxvar\_{(t=6hr)} - fluxvar\_{(t=3hr)}}{3\cdot3600}}$$

A couple of questions that Vidhi asked about that may be worthwhile understanding to others:

1. Why did the website quoted show the calculation as $\mathrm{({fluxvar\_{(t=6hr)} - fluxvar\_{(t=3hr)})/10800}}$, but not $\mathrm{({fluxvar\_{(t=3hr)} - fluxvar\_{(t=0hr)})/10800}}$... instead just using $\mathrm{{fluxvar\_{(t=3hr)}}/10800}$
   * Because indeed, in this strange accumulation form $\mathrm{fluxvar\_{(t=0hr)}}$ by definition is zero. The variable may or may not exist in the $\mathrm{t=0hr}$ file, but if it does, it should be pointless to include as it had better be 0 if it is indeed accumulation.
2. The site quoted only mentions hours 3, 6, 9, and 12. I have 15, 18, and 21 as well, how do I deal with this?
   * The same math applies... but remember, if you're dealing with forecast model archive (rather than reanalysis data), you want to use the shortest future hour possible. So actually, rather than use 00Z's $\mathrm{t=12hr}$, you want to be using 12Z's $\mathrm{t=0hr}$, such that, when calculating the 9Z to 12Z flux average, best is$\mathrm{({fluxvar\_{(12Z\;t=0hr)} - fluxvar\_{(00Z\;t=9hr)})/10800}}$. Because you only need steps 0, 3, 6, and 9 before the next archived model/reanalysis file (for a twice a day model), the 12/15/18/21 values really are the 0/3/6/9 values (just from the next model run).

Anytime derived values (variables that aren't in the model itself, but require a formula to determine) need calculating, such as total surface heat flux, just make sure that when you combine the variables (in this case the shortwave, longwave, sensible, and latent heats), you only divide by the timestep once (don't divide by 10800 in the separate input variables beforehand, then divide by 10800 again after combining them).

The models are strange to many. I just happened to incorrectly remember what a flux was, and get the "divide by 10800" math right (probably in part due to horror memories of working with similar files in years gone by!). But hopefully this helps some confused people!

> **Comments:**
> **username_2**: +1. The fluxes end up being defined this way because numerical model time is discrete, so the fluxes during a period are what shift the model from a state at time _t_ to another state at time _t+1_.  In the limit of the model timestep going to zero, time becomes continuous and fluxes become instantaneous like the traditional physics definition.  
> **username_1**: @username_2 And yet (correct me if I'm wrong on any of these things!) the actual temporal resolution [appears to be 15 minutes](https://ghrc.nsstc.nasa.gov/uso/ds_docs/tcsp/tcspecmwf/ECMWFUserGuideofForecastProductsm32.pdf)... and we do instantaneous windspeed at each output, despite it likewise being fundamentally just a derivative of a variable over time? (Perhaps has something due to usage of spectral functions [way over my head!], or because wind is in the primitive equations??) But glad to get a few thoughts on it, and that's the way I've thought too, though it still doesn't add up totally.  
> **username_2**: Well, the instantaneous windspeed thing is less high level than that.  When you apply the basic conservation laws (mass, momentum, energy) to a fluid continuum you end up with system of differential equations that solve for a handful of state variables, including the flow velocity field, e.g., _u(x, t)_.  In a loose sense, you can think in terms of a velocity/density state subject to mass and momentum fluxes.  Sort of.  
> **username_1**: @username_2 Alright, sounds reasonable enough at least, sounds like where I was going with those thoughts.  Of course the question becomes in model output, why can't they just divide out the 3 hours (or whatever timestep) and provide average flux?  I guess since it'd just lead to extra work, when a few people may rather want a 6 hr or 12 hr or 24 hr averaged flux.  But seems a clearer variable name (ACCUMULATED flux in the variable name\abbreviation) would be less confusing for folks new to the models :-)  Thanks for taking the time to discuss though, you added very useful insight.  

---

