Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DOD Documentation for StorageInput is not clear #872

Open
t-ober opened this issue Aug 28, 2023 · 3 comments · May be fixed by #942
Open

DOD Documentation for StorageInput is not clear #872

t-ober opened this issue Aug 28, 2023 · 3 comments · May be fixed by #942
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@t-ober
Copy link
Contributor

t-ober commented Aug 28, 2023

"Maximum permissible depth of discharge. 80 % dod is equivalent to a state of charge of 20 %."

We use this value differently in SIMONA :

private val minEnergy = eStorage * dod.toEach

We should either adapt the documentation or change the SIMONA implementation.

@t-ober t-ober added documentation Improvements or additions to documentation good first issue Good for newcomers labels Aug 28, 2023
@SimonHuette SimonHuette self-assigned this Nov 14, 2023
@SimonHuette SimonHuette linked a pull request Nov 27, 2023 that will close this issue
SimonHuette added a commit that referenced this issue Dec 2, 2023
@sebastian-peter
Copy link
Member

sebastian-peter commented Dec 2, 2023

From what I've read now, the defintion in PSDM seems correct and the implemetation in SIMONA incorrect. (Besides the point, maybe we should rename the parameter to dodMax, because that seems to be more descriptive. dod on its own is just the counterpart to soc).

@sebastian-peter sebastian-peter removed the good first issue Good for newcomers label Dec 13, 2023
@danielfeismann
Copy link
Member

I also checked the defintion and agree to @sebastian-peter. Thinking about this I come to the conclusion, that in my opinion we don't need the dod at all if we agree to see the eStorage as the storage usable capacity. For all application cases we have so far we don't deep-discharge the battery and if one would do so this only makes sense if there are implications on the battery life time modeled which isn't so far. So I would opt to change this issue into one removing dod from documentation and code.

@sebastian-peter
Copy link
Member

Thinking about it more, I tend to agree with @danielfeismann. dod is not a parameter that we're (currently) interested in. Same goes for lifeTime and lifeCycle, which we do not consider for any other asset as well. If we'd come to the conclusion in the future that we'll need this again, we could just add it back in.

So if no-one disagrees, I'd go ahead and give green light for removing said parameters above from code and documentation.

danielfeismann added a commit that referenced this issue Apr 30, 2024
# Conflicts:
#	CHANGELOG.md
#	docs/readthedocs/models/input/participant/storage.rst
#	src/main/java/edu/ie3/datamodel/io/factory/typeinput/SystemParticipantTypeInputFactory.java
#	src/test/groovy/edu/ie3/datamodel/io/factory/typeinput/SystemParticipantTypeInputFactoryTest.groovy
#	src/test/groovy/edu/ie3/datamodel/io/source/csv/CsvTypeSourceTest.groovy
#	src/test/resources/edu/ie3/datamodel/io/source/csv/_types/storage_type_input.csv
danielfeismann added a commit that referenced this issue Apr 30, 2024
…nto sh/#872-storage-documentation

# Conflicts:
#	docs/readthedocs/models/input/participant/storage.md
danielfeismann added a commit that referenced this issue Apr 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants