Open tpelser opened 4 months ago
Techno-economic potential determination method
is a methodology with the goal of assessing the economic viability of wind energy projects within the available area, based on the technical potential and incorporating cost factors and economic metrics.
Determine capital expenditures
is an action specification that describes the calculation of capital expenditures (CAPEX) required for the installation of wind turbines and associated infrastructure.
Determine operational expenditures
is an action specification that describes the estimation of ongoing operational expenditures (OPEX) for wind turbines, including routine maintenance and operational management. These include operating and maintenance costs.
Determine discount and interest rate
is an action specification that describes the selection of financial discount and interest rates, which are used in the economic analysis to account for the time value of money.
Calculate economic potential
is an action specification that describes the determination of the total economic potential of the available area under a maximum threshold LCOE value.
Unchanged:
Determine wind turbine lifetime
is an action specification that describes the process of estimating the operational lifespan of a wind turbine, based on design and site-specific conditions.
Calculate Levelized Cost of Energy
is an action specification that describes the computation of the Levelized Cost of Energy (LCOE) either for individual turbines or for sub-regions within the study area by applying a cost model based on the previously calculated economic parameters and the capacity factors.
Feasible potental determination method
is a methodology with the goal of calculating the wind energy potential that remains after applying additional social, regulatory, or market constraints to the available region.
Apply constraints
is an action specification that describes the process of integrating non-technical factors, such as social acceptance, land use regulations, or market conditions, into the potential assessment.
Calculate feasible potential
is an action specification that describes the calculation of the feasible wind energy potential, considering both technical and socio-economic constraints.
@tpelser @stap-m
I have a problem with this task:
Place turbines in area or determine capacity density
is an action specification that describes how turbines are spatially distributed within the available area, or how the capacity density (MW per unit area) is calculated.To me it seems like these are two different tasks on a forked path. I don't think this should be one class if this is the case.
Sure this task could be split into two - Maybe something like: Place turbines within the available area Define the spatial arrangement of wind turbines within the designated area, ensuring optimal positioning based on site characteristics and layout constraints.
Determine capacity density Calculate the installed capacity per unit area (MW per km²) by assessing the number and power rating of turbines within the available space.
Improve spatial resolution
is an action specification that describes the process of increasing the spatial resolution of wind data across a region to provide finer detail for wind resource assessment. This is done by horizontal interpolation.
I guess such a method would be applicable to other data as well, e.g. PV. @tpelser? Souldn't we generalize the definition in that sense? Else, we should refer to (meteorological?) wind data in the label.
EDIT:
Determine capital expenditures
is an action specification that describes the calculation of capital expenditures (CAPEX) required for the installation of wind turbines and associated infrastructure.
Determine operational expenditures
is an action specification that describes the estimation of ongoing operational expenditures (OPEX) for wind turbines, including routine maintenance and operational management. These include operating and maintenance costs.
Determine wind turbine lifetime
is an action specification that describes the process of estimating the operational lifespan of a wind turbine, based on design and site-specific conditions.
Calculate Levelized Cost of Energy
is an action specification that describes the computation of the Levelized Cost of Energy (LCOE) either for individual turbines or for sub-regions within the study area by applying a cost model based on the previously calculated economic parameters and the capacity factors.
I think these could also be generalized. Maybe both, a generalized and a wind specific classs (as subclass?) are sensible.
Wind variability identification
is an action specification that describes the process of identifying variations in wind characteristics across different seasons and times of day.
I'd like at add a specification (e.g. a second sentence) what is meant by "wind characteristics". Wind speed and air desity at different hights? Something else? @tpelser
Apply constraints
is an action specification that describes the process of integrating non-technical factors, such as social acceptance, land use regulations, or market conditions, into the potential assessment.
This label is too generic, since constraints could be applied in any context. Apply constraints for potential assessment
?
@stap-m
The old definition read like this:
Apply additional social/market constraints
is an action specification that describes the process of integrating non-technical factors, such as social acceptance, land use regulations, or market conditions, into the potential assessment.
If we wanted to stay as close to this as possible I would go with apply social/market constraints
instead. If however that is still too generic - and I feel like it might be - then I am also fine with your proposition.
Updated pending questions:
How should the subtasks relate to the task? Do all of them need to be done or just some of them? For now the axioms guessing the right appoach have been removed.
Will subtasks be reused in other tasks? Depending on this we could have parent classes for better readability or not.
Should the oeo always import this new module?
Should we add to the definitions or implement new classes to explain what things like "wind characteristics" even mean? Because there are goals of several object specifications now that don't really get elaborated on.
Should we generalize the definition or make some labels more specific?
Wind variability identification
is an action specification that describes the process of identifying variations in wind characteristics across different seasons and times of day.I'd like at add a specification (e.g. a second sentence) what is meant by "wind characteristics". Wind speed and air desity at different hights? Something else? @tpelser
I would update this to:
Wind variability identification
is an action specification that describes the process of identifying variations in wind characteristics—such as speed, direction, frequency, turbulence, and seasonal or diurnal patterns—across temporal scales.”
Apply constraints
is an action specification that describes the process of integrating non-technical factors, such as social acceptance, land use regulations, or market conditions, into the potential assessment.This label is too generic, since constraints could be applied in any context.
Apply constraints for potential assessment
?
An answer to this could be:
"Integrate non-technical constraints in potential assessments
is an action specification that describes the process of integrating non-technical factors, such as social acceptance, land use regulations, or market conditions, into the potential assessment.”
"Integrate non-technical constraints in potential assessments
is an action specification that describes the process of integrating non-technical factors, such as social acceptance, land use regulations, or market conditions, into the potential assessment.”
This label is even longer than the old one though and the goal was to make it more compact.
Thank you for the updated definition for wind variability. I updated it.
Improve spatial resolution
is an action specification that describes the process of increasing the spatial resolution of wind data across a region to provide finer detail for wind resource assessment. This is done by horizontal interpolation.I guess such a method would be applicable to other data as well, e.g. PV. @tpelser? Souldn't we generalize the definition in that sense? Else, we should refer to (meteorological?) wind data in the label.
EDIT:
Determine capital expenditures
is an action specification that describes the calculation of capital expenditures (CAPEX) required for the installation of wind turbines and associated infrastructure.Determine operational expenditures
is an action specification that describes the estimation of ongoing operational expenditures (OPEX) for wind turbines, including routine maintenance and operational management. These include operating and maintenance costs.
Determine wind turbine lifetime
is an action specification that describes the process of estimating the operational lifespan of a wind turbine, based on design and site-specific conditions.Calculate Levelized Cost of Energy
is an action specification that describes the computation of the Levelized Cost of Energy (LCOE) either for individual turbines or for sub-regions within the study area by applying a cost model based on the previously calculated economic parameters and the capacity factors.I think these could also be generalized. Maybe both, a generalized and a wind specific classs (as subclass?) are sensible.
For the first one, I agree it would make sense to generalize and we could update to:
Interpolate data horizontally
is an action specification that describes the process of increasing the spatial resolution of geospatial data across a region to provide finer detail for resource assessments. This is done through horizontal interpolation.
For the next ones I am not sure if generalizing makes sense because as I understand it this is describing a workflow that is specific to wind resource assessments? Therefore these cost calculations are always to do with wind. Or maybe I do not understand properly
"Integrate non-technical constraints in potential assessments
is an action specification that describes the process of integrating non-technical factors, such as social acceptance, land use regulations, or market conditions, into the potential assessment.”This label is even longer than the old one though and the goal was to make it more compact.
Okay, I did not see that the goal was to shorten this, I thought it was "too generic"?
I am not quite sure how we could possibly shorten it more than the original which was Apply constraints
. Maybe just Integrate non-technical constraints
or Apply non-technical constraints
?
We could shorten the entire description to something like:
“
Integrate non-technical constraints
is an action specification that describes the inclusion of factors like social acceptance, land use regulations, and market conditions into potential assessments.”
@tpelser
The original labels were very long. In some cases almost whole sentences. The label should be more compact with specifics reserved for the definition. However apply constraints
was so short that it became too generic. This is why apply constraints for assessment of potential
came up as an option.
What do you think of the proposed integrate non-technical constraints
or apply non-technical constraints
, @stap-m ? I think they both sound reasonable.
What do you think of the proposed
integrate non-technical constraints
orapply non-technical constraints
, @stap-m ? I think they both sound reasonable.
I still think, the "assessment of potential" is a relevant part in this label that we should not drop, despite the length.
In that case I think apply constraints for assessment of potential
is the best solution so far. Unless @tpelser would say that the non-technical aspect is so important that it needs to be in the label. In that case:
apply non-technical constraints for assessment of potential
is the still long but shortest version.
I don't think the definition needs to be shortened. I'd curently favor:
Apply constraints for assessment of potential
is an action specification that describes the process of integrating non-technical factors, such as social acceptance, land use regulations, or market conditions, into the potential assessment.
For the first one, I agree it would make sense to generalize and we could update to: Interpolate data horizontally is an action specification that describes the process of increasing the spatial resolution of geospatial data across a region to provide finer detail for resource assessments. This is done through horizontal interpolation.
@stap-m
Should I implement this change or do you see a problem? I am fine with how it sounds.
In that case I think
apply constraints for assessment of potential
is the best solution so far. Unless @tpelser would say that the non-technical aspect is so important that it needs to be in the label. In that case:apply non-technical constraints for assessment of potential
is the still long but shortest version.I don't think the definition needs to be shortened. I'd curently favor:
Apply constraints for assessment of potential
is an action specification that describes the process of integrating non-technical factors, such as social acceptance, land use regulations, or market conditions, into the potential assessment.
Actually, yes, since this is part of the feasible potential , it would be important to specify here that these are "non-technical" constraints: Determine the feasible potential 5.1 Apply additional social/market constraints 5.2 Calculate feasible potential for the region
The original was apply additional social/market constraints. This could also be:
Apply additional socio-economic constraints
Updated pending questions:
How should the subtasks relate to the task? Do all of them need to be done or just some of them? For now the axioms guessing the right appoach have been removed.
Will subtasks be reused in other tasks? Depending on this we could have parent classes for better readability or not. Right now we have that parent class.
Should we generalize the definition or make some labels more specific?
Should the oeo always import this new module?
Should we add to the definitions or implement new classes to explain what things like "wind characteristics" even mean? Because there are goals of several object specifications now that don't really get elaborated on.
To Do:
In progress
@stap-m In the pull request you commented:
The addition for wind characteristics seems to be still missing.
I added that to the To Do list but I am not sure what you are referring to. Do you possibly mean the change from:
apply constraints for assessment of potential
to either
apply non-technical constraints for assessment of potential
or
apply socio-economic constraints for assessment of potential
If so I don't think we agreed on one of them yet and that might be a thing wort doing.
@tpelser
Could you comment on the relationship between a task and its subtasks? For example if we look at
determine wind characteristics of a region
:
Do all the subtasks like wind speed calculation
need to be taken? Do some specific ones need to be taken or maybe a certain number of them? With that answered we could craft new axioms for the relationship of the action specification
s and the objective specification
(or maybe themethodology
).
We (researchers from Jülich Systems Analysis) would like to use energy-related task definitions to describe research data (e.g. in knowledge graphs such as the ORKG or the OEKG), and to allow task/problem-oriented search and discovery of research data.
What are "task definitions":
These refer to tasks within a workflow for analysing aspects of energy systems. As an example, the spreedsheet "workflow" in this Excel file contains an overview of the workflow tasks for literature looking at wind power potentials: https://data.fz-juelich.de/dataset.xhtml?persistentId=doi:10.26165/JUELICH-DATA/FXM9CB
These tasks include: Tasks 1 Determine wind speed characteristics of the region Definition: The tasks related to understanding the meteorological conditions of the study region and the theoretical wind potential. 1.1 Select appropriate wind data 1.2 Download & process wind data 1.3 Extrapolate wind speed vertically to hub height 1.4 Account for air density change 1.5 Determine wind speed frequency distribution 1.6 Determine theoretical potential / WPD 2 Determine available area for wind farm development Definition: The tasks related to estimating the areas which are available for development of wind parks, and the areas which are ineligible. 2.1 Download and process topographical data 2.2 … 3 Determine technical wind potential of the available land area 3.1 … 4 Determine economic potential of the available region 4.1 … 5 Determine feasible potential 5.1 … (*) -> optional task
Our aims
Our aim is to first have task definitions which are agreed upon in the domain (for referencing research data to it). Second step would be to introduce relationships between tasks (which can be used for knowledge transfer and data exploration/navigation). A relationship could be “sub/super task”. A third step could be the numbering of tasks within processes/(software)workflows to transparently describe, what data processing steps were performed in a study.
As an example of how a task could look like in an ontology, the BioAssay Ontology and the task "mitochondrial membrane potential assessment" can be used: https://terminology.tib.eu/ts/ontologies/bao/terms?iri=http%3A%2F%2Fwww.bioassayontology.org%2Fbao%23BAO_0000423&obsoletes=false
This task includes a definition, an IRI and a task hierarchy with “mitrochondrial…” being a SubClass Of “viability measurement method”.