-
Notifications
You must be signed in to change notification settings - Fork 135
temp_cosmos_description
Uwe Krien edited this page Jan 8, 2018
·
3 revisions
The framework and its underlying concept are implemented using an objectoriented approach
in the high-level programming language Python
- . It is published under the GNU GPL3 license and consists of different libraries
- that can be grouped according to their mutual compatibility, resulting in the layer structure shown
- in Figure 2.
+ , published under the GNU GPL3 license.
+ The content of the framework is grouped in functional and organisational units.
+ To lower the entry and review barriers between the libraries as many commonalities as possible
+ are used/ensured/implemented(?).
- Four main layers can be used to categorize the libraries:
+ Therefore four layer are used to categorize the libraries with their dependencies and commonalities.
+ (All layers in the oemof cosmos should be related to the field of energy system modelling ???)
1. At the core layer the generic graph structure is implemented. At this layer
the basic application programming interface (API) is defined. Additionally,
the description of an energy system as well as the format of input and output
data for core-objects is defined.
+ As this structure is generalisable this layer is intended to be the base for existing and
+ future model approaches. Beispiel(?)
2. The namespace layer contains these associated libraries that
- are based on the core
+ share the same basic system formulations. Therefore they depend on the basic
+ API and inherit from core-objects.
+ This makes it easier to use similar system formulations for different models.
- These could be libraries
+ This includes libraries
- for cost or power-flow optimization or other purposes.
+ for all kind of models as cost, power-flow or any kind of optimisation approaches.
+ By now only one library is based on the core layer is implemented but the structure is
+ capable to add further concepts such as rule based optimisation...
+ (da würde ich noch gucken, wie alternative Ansätze prägnant heißen)
3. The oemof layer contains libraries
- associated with oemof. It is not based on a cross-level API.
+ from the field of energy system modelling that are associated with oemof
+ in organisational way without sharing the basic API. Therefore these libraries are technically
+ independent and can be used, reviewed and developed by third part modellers and experts as well.
However, it is developed within the framework and consequently follows common development rules (Section 3.3)
- . These libraries can either be used independently or combined with all other libraries.
+ , which makes it easy to combine them within an application.
+ As most modellers are not primarily programmers, sharing the same developing, structure and
+ documentation rules helps to learn the ropes of useful libraries.
+ Examples. Windpowerlib - feed-in time series of wind energy turbines from metrological data.
- 4. Finally, the outermost linked packages layer includes open source projects
- known to be used by or to use libraries from the layers below. These open
- source projects complete the toolbox for energy modelling. With this layer
- the advantage of synergies with energy related open source projects that link
- to or are linked to the framework is used.
+ 4. As Pfenning et. al [...] mentioned that open source does not necessarily leads
+ to cooperation the fourth layer contains libraries that could be part of the layers below but
+ already exist as a community project and have been proofed to be integrable in oemof models due
+ to their general structure. Therefore the focus lies on the provision of adapters and the
+ contribution to these projects.
+ These libraries are written in python but do not necessarily share they same rules. However,
+ associated should meet general standards in quality, code developing, longevity and community structure.
+ Example pvlib: Adapters in feedinlib / examples, contribution to implement the needs of energy system modellers.