Code Monkey home page Code Monkey logo

pycopancore's People

Contributors

fmhansen avatar jakobkolb avatar jdonges avatar kilianzimmerer avatar marcwie avatar mensch72 avatar paulabreitbach avatar sduslu avatar tillkolster avatar wbarfuss avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

pycopancore's Issues

Plotting component

Write a plotting component which works with the trajectory dictionary which is returned by the runner.

Draft a first Code of Good Practice for coding

After the meeting, I was discussing with Wolf and he asked me to Draft a first Code of Good Practice for coding, that we could put in the README. The idea is to have some guidelines/recommendations/hints that we want to follow so the code is legible, easy to debug and easy to expand.
PS: I can't assign myself, could somebody with the correct rights do that?

Creation Routines

This is a question that came to my mind lately. When initializing the model, where do we have creation routines of cells etc.? At low levels, so for example at the planet or donut_world class that creates a grid or - in case of individuals - a network that includes individuals? Or at model level?

I prefer creating instances at lower level to make the model class more manageable, but I see probels with this idea too: So in my example, the donut_world class is made to work with the local_renewable_resource class. With another class it may not work...

I am not shure how connected these problems are, because I don't have a clear picture of the model structure in detail in my mind, yet. Maybe we can discuss this soon, I think otherwise we will have inconsequent structure later

Unit-test

Since now we are programming a lot in single classes without using them, it might be the right time to write some unit-test? If so, do we put them into the tests folder and name them something like filename_test.py? Or folder_filename_test.py? Is there an established naming scheme?

General Naming problems

While going through the code Svenja noticed some confusing use of naming. This led us to start a general discussion about it.

Each underlying class (Cell, Society, Individual, Nature, Culture, Metabolism) has an attribute called entities, which is a list containing the classes' instances. Since only objects of the classes Society, Individual and Cell should be called entities we have to find another name for this list.

Any suggestions?

Raising discontinuities during integration

Implement the option to raise events caused by a process during a integration. Until now the time an event takes place is decided before, a sudden event is not possible. Runner-logic must be changed to allow for this.

ENH: Mandatory Parameter Naming

Maybe include mandatory naming of variables when calling functions. Assure that this is the case for all functions by using the testing environment

Design MasterDataModel

#25 depends on the implementation of a MasterDataModel, where variables which are used by several components are defined

create a contributor agreement

From PIK's open source recommendations: "use http://contributoragreements.org to create a contributor agreement". They recommend the following settings:

  • Non-exclusive license: Giving the project owner the right to relicense it but does not retract any rights of the contributor on their contribution
  • Permission to relicense the code under any Open Source license which is either approved by the Free Software Foundation or Open Source Initiative (Option 3).
  • Permission to license provided documentations under cc-by (http://creativecommons.org/licenses/)
  • Traditional patent licensing agreement

Code style/enhancement

If there are any suggestion to improve or enhance the existing code leave them here.

Edit by Till:
This is just a thread to collect pieces of code to show how there is a more elegant way and to keep them as a sort of style guide by examples

Proposed lifecycle and workflow for Model Variable Definitions and Metadata

Goal: Allow for...

  • flexible addition of model variables (including static ones aka parameters) by model components
  • easy usage in other model components
  • possibility to be promoted into a centrally governed "master data model"
  • without having to maintain a variable's metadata (name, description, dimension, unit, scale type, bounds, quantum, default value, uninformed prior distribution, etc.) in more than one place.
  1. A new model variable (e.g. Cell.fossil_reserve) comes into being when some model component (e.g. pycopancore.components.fossil_extraction) introduces it the first time by defining it in their entity interface class by instantiating the Variable class with the variable's metadata, e.g. in pycopancore.components.fossil_extraction.interface.py:
class Cell (object):
    fossil_reserve = Variable(name="cellular fossil reserve", desc="...", dimension=Carbon)
  1. Another components (e.g. pycopancore.components.general_equilibrium_energy_sector) can then access that variable by importing that interface module in its own interface module and assigning the same Variable object to its own entity interface class, e.g. in pycopancore.components.general_equilibrium_energy_sector.interface.py:
import pycopancore.components.fossil_extraction.interface as FE
class Cell (object):
     fossil_reserve = FE.Cell.fossil_reserve
  1. As soon as the variable gets approved by the copancore-community's "data model committee" (to be defined), its definition gets copied into the master data model, a special module of the same format as the components' interface modules, whose classes are however never inherited directly. In the above example, on would then add to pycopancore.master_data_model.py:
class Cell (object):
    fossil_reserve = Variable(name="cellular fossil reserve", desc="...", dimension=Carbon)
  1. From that point on, all components using this variable should import it from the master data model, e.g., both pycopancore.components.fossil_extraction.interface.py and pycopancore.components.general_equilibrium_energy_sector.interface.py would change to
import pycopancore.master_data_model as MDM
class Cell (object):
     fossil_reserve = MDM.Cell.fossil_reserve
  1. To maintain harmonized variable definitions and avoid coincidental name clashes, the method Model.configure() must make sure that if two of the components used in the model at hand define the same variable name, it must point to the same Variable object (as in the examples above). It may even make sure that if a component uses a variable name that exists in the MDM, it must point to the Variable object defined in the MDM.

  2. Still, components should probably be allowed to use another component's (or the master data model's) variables under a locally different name, as in:

import pycopancore.components.fossil_extraction.interface as FE
class Cell (object):
     geological_carbon_stock = FE.Cell.fossil_reserve

ENH: Decide on time integration logic and integrator

How does time integration work in the model? What integrator to use? (Frank has an alpha version of a solver of algebro-differential equations)

Basic problem / challenge of combining continuous and irregularly discrete dynamics.

Modul or Model guided Folder structure?

Either

  • copancore
    • anthroposphere
      • abstract_anthoposphere.py
      • concrete_athroposphere_1.py
      • concrete_athroposphere_2.py
      • ...
    • ecosphere
      • abstract_ecosphere.py
      • concrete_ecosphere_1.py
      • concrete_ecosphere_2.py
      • ...

or

  • copancore
    • abstract_anthoposphere.py
    • abstract_ecosphere.py
    • concrete_model_1
      • concrete_anthroposphere_1.py
      • concrete_ecosphere_1.py
    • concrete_model_2
      • ....
    • ...

World Attribute in Abstract_Entity_Mixin

Jede Entity hat ein Attribut, zu welcher World es gehört. Da das ja bei jeder Entity ausser bei World selber nötig ist, ist das nun im Branch https://github.com/pik-copan/pycopancore/tree/world_entity_type (world_entity_type) in der Abstract_Entity_Mixin Klasse implementiert. Jetzt gibt es nur den Schönheitsfehler, dass man beim Initialisieren von world selber auch etwas angeben muss um dieses Attribut zu füllen, derzeit ist das mit None gemacht. Das ist aber nicht schön. Wie kann man das schöner machen?

ENH: Define recommended way to handle networks

What is a recommended way to handle networks in CORE components: use a performant, but simple library for this: igraph, graphtool, boostgraph ? Check what is recommended and define criteria for selection.

improve _template model component

  • rename to _template so that it is not confused with actual model components
  • add __deactivate and __reactivate method templates to all entity types
  • remove as much clutter as possible
  • rewrite docstrings so that they are templates for the later docstrings rather than explain what needs to be done
  • add comments beginning "TODO:" that explain what needs to be done to make a component on the basis of the _template. the model component developer would later remove these comments
  • merge some of the minor improvements Jobst did in the prototype branch

Enhance Templates

Enhance the templates and their documentation to make it easier for newbies to work with the framework. Maybe this is to be done when developing a new component, so nothing is forgotten to be included

Variable naming and metadata standards to use

Reducing code complexity

Regarding the McCabe complexity checks, we have to reduce complexity as much as possible and find new complexity thresholds.

PEPs included in py.test

PEP257 is giving out a lot of errors, since it requires a very strict formatting of docstrings. Do we want this? One of the complaints is this:
<<First word of the docstring should not be This [pep257]>>
This might be very annoying during further coding...

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.