NatLabRockies / NatLabRockies/H2Integrate

Units convention for varying dt

Open
#244 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
26
Forks
44
Avg merge
3d 22h
Merged PRs (30d)
16

Description

Expected units on inputs/outputs for varying dt and n_timesteps

For timeseries outputs, should units be represented as a rate or amount? Most of the models in H2Integrate assume hourly timesteps (dt = 3600) and a year-long simulation (n_timesteps=8760). However, as noted in Issue #204, it would be great if models could handle varying timestep duration and number of timesteps.

For timeseries inputs/outputs, should we have outputs be presented in rates or amounts? The ElectrolyzerPerformanceBaseClass has an input of electricity_in in units of kW and output of hydrogen_out in kg/h (and an output of total_hydrogen_produced in units of kg/year).

If dt!=3600 then hydrogen_out would actually not be in kg/h but in kg/dt. I think there are two possible ways to handle this.

  1. hydrogen_out units are always kg, assumed to be kg/dt (I prefer this one)
  2. hydrogen_out is in units of kg/dt*s where dt is set to the timestep. For hourly simulations, the units would be kg/3600*s.

This gets a little funky for things like electricity, where power (kW) and energy (kWh) are commonly used interchangeably due to past usage of strictly hourly simulations. For hourly simulations, electricity_in would most accurately be represented as kW*h/h, rather than just kW. A kW represents power produced per second (1 kW = 1 kJ/s). For hourly simulations, electricity per timestep is actually the sum of electricity per second over that timestep (1 kWh = (1 kW)*(3600*s/h) = (1 kJ/s)*(3600*s/h) = 3600 kJ).

Similarly, for simulations that aren't a year long, should totals over the simulation would be in units of kg/n_timesteps*dt*s? Or should models be expected to convert these values to be represented annually (so units could always be kg/yr).

Total electricity production is in units of kWh/year (this is correct for hourly simulations that are for a year).

A minor note on this topic, in OpenMDAO units, a year is 365.242199*d (d is a day, which is 86400*s), which is not equal to 8760 hours (8760 hours is the number of hours in a year that isn't a leap year, there are 8784 hours in leap years. The "average length of a year" over a 4-year period is 8766 hours, which is 365.25 days).

Proposed solution

Timeseries units represented as amounts rather than rates:

  • hydrogen profile would be kg
  • electricity profile would be kW

But, this makes it difficult to distinguish the timeseries units from total(s) units:

  • sum of hydrogen profile would also be kg
  • sum of electricity profile would be be kWh

if electricity profile is assume to be in kW, power profile (kW) is converted to energy profile (kWh)

  • hourly simulations (dt = 3600), if electricity profile at time t is 1 kW, this means that for each second in the hour, there is 1 kW of power being produced. Over the entire hour, there is 1 kWh of energy produced
  • 15 minute simulations (dt = 900), if electricity profile from time t to t+4 is [0.25 kW,0.25 kW,0.25 kW,0.25 kW], this means that for each second in the 15 minute timestep, there is 0.25 kW of power being produced. Over the 15 minutes, there is 0.25 kWh of energy produced. . Over an hour there is 1 kWh of energy produced.

Alternatives considered

Additional context

Related to Issue #223 and #231

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing Issue #204 and the related Issues #223 and #231, then inspect the ElectrolyzerPerformanceBaseClass inputs and outputs described here. Clarify how varying dt and n_timesteps should affect timeseries and total units, including the year-length convention. Done means an agreed, consistently applicable units convention for these cases.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.