NatLabRockies / NatLabRockies/H2Integrate
Units convention for varying dt
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.
hydrogen_outunits are alwayskg, assumed to bekg/dt(I prefer this one)hydrogen_outis in units ofkg/dt*swheredtis set to the timestep. For hourly simulations, the units would bekg/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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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