OMEGAlpes issueshttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues2022-04-29T09:51:58+02:00https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/78Import incident when using mybinder2022-04-29T09:51:58+02:00Sacha HodencqImport incident when using mybinderWhen launching mybinder for an OMEGAlpes notebook, an import error often occurs. For instance, when importing LpDictVariable on the [BS2019 PV self-consumption notebook](https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes_ex...When launching mybinder for an OMEGAlpes notebook, an import error often occurs. For instance, when importing LpDictVariable on the [BS2019 PV self-consumption notebook](https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes_examples/-/blob/master/notebooks/article_2019_BS_PV_self_consumption.ipynb)Sacha HodencqSacha Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/67Question pour ajouter nodes2021-10-26T09:57:46+02:00EXT HaichengLINGQuestion pour ajouter nodesBonjour,
J'ai utilisé OMEGalpes pour créer model d'autoconsomation collective(image ci-dessous). J'ai utilisé un boucle for pour créer des nodes et des utité connecté. Mais quand je veux ajouter des nodes, ça ne marche pas d'ajouter les...Bonjour,
J'ai utilisé OMEGalpes pour créer model d'autoconsomation collective(image ci-dessous). J'ai utilisé un boucle for pour créer des nodes et des utité connecté. Mais quand je veux ajouter des nodes, ça ne marche pas d'ajouter les nodes 1 par 1 dans boucle 'for', il faut que j'ajoute tous les nodes en même temps.
Ce que je veux faire est de générer automatiquement le model pour tous les autoconsommation collectif, donc je cherche un moyenne de regrouper les nodes qui est créé dans le boucle 'for'(pour différent opération, le nombre de node est varié) et les ajoute avec add_nodes.
Est-ce que vous saver comment le faire
Merci en avance,
Cordialement
![image](/uploads/7216afd41fb2fab3e6a01c4c0975afda/image.png)Mathieu BrugeronMathieu Brugeronhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/66e_max & e_min and time step consideration2021-02-26T12:06:03+01:00Sacha Hodencqe_max & e_min and time step considerationThe time step is considered twice in e_max and e_min calculation:
- in the e_tot calculation, that is consistent to get an energy value for e_tot from a power values sum : `{0}_e_tot == time.DT * lpSum({0}_p[t] for t in time.I)`
- ...The time step is considered twice in e_max and e_min calculation:
- in the e_tot calculation, that is consistent to get an energy value for e_tot from a power values sum : `{0}_e_tot == time.DT * lpSum({0}_p[t] for t in time.I)`
- in the e_max and e_min : `'time.DT*{0}_e_tot >= {1}'.format(self.name, e_min),`Sacha HodencqSacha Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/65lpfics - print problem2021-02-03T15:48:31+01:00Mathieu Brugeronlpfics - print problem### Summary
lpfics infesible search function having an error message during the run
!!! pulp version 2.0 !!!
### Steps to reproduce
download the lpfics package and then use the find_infeasible_constraint_set on a infeasible model
as ...### Summary
lpfics infesible search function having an error message during the run
!!! pulp version 2.0 !!!
### Steps to reproduce
download the lpfics package and then use the find_infeasible_constraint_set on a infeasible model
as follows
from lpfics.lpfics import find_infeasible_constraint_set
find_infeasible_constraint_set(optim_model)
### Example Project
Any example project where you create a infeasible data set entry
### What is the current *bug* behavior?
the method isn't working because the LpConstraint object doesn't have any cst attribute
### What is the expected *correct* behavior?
a set of constraint which contains the infeasible constraints should be printed on the pycharm terminal
### Relevant logs and/or screenshots, python output
![image](/uploads/ff96b96e0825bc7312a4200f7f1d466e/image.png)
### Possible fixes
I would say that it's due to a change from the lp creation from pulp, which have modified the attributes od the LpConstraint which doesn't contain the type of Constraint the same way. I'm looking forward a way of solving thisMathieu BrugeronMathieu Brugeronhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/60No attribute _external_constraint_list in EnergyNode2020-10-22T14:35:00+02:00Sacha HodencqNo attribute _external_constraint_list in EnergyNode<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Bug" label, following this link :
- https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/issues?label_name%...<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Bug" label, following this link :
- https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/issues?label_name%5B%5D=bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
When running a simple use case (LNCMI notebook), the following error occurs :
```
AttributeError Traceback (most recent call last)
D:\00 - Eco-SESA\02 - Outils\OMEGAlpes\omegalpes_examples\notebooks\python_scripts\NB_LNCMI.py in updateData(click)
292 lncmi_case(elec2heat_ratio=ELEC_TO_HEAT_RATIO, capacity=CAPA_STORAGE,
293 cop_hp=COP,pmax_elec_hp=P_MAX_HP,
--> 294 storage_soc_0=SOC_0_STORAGE, pmin_recovery=PMIN_RECOVERY)
295
296 display(runPlotButton)
D:\00 - Eco-SESA\02 - Outils\OMEGAlpes\omegalpes_examples\notebooks\python_scripts\NB_LNCMI.py in lncmi_case(elec2heat_ratio, capacity, cop_hp, pmax_elec_hp, storage_soc_0, pmin_recovery)
172 heat_node_lncmi.export_min = \
173 ExtDynConstraint(name='pmin_recovery', exp_t=pmin_rec_cst_exp,
--> 174 t_range='for t in time.I', parent=heat_node_lncmi)
175 # OBJECTIVE CREATION
176 # Minimizing the part of the heat load covered by the heat production plant
d:\00 - eco-sesa\02 - outils\omegalpes\dev_omegalpes\omegalpes\general\optimisation\elements.py in __init__(self, exp_t, t_range, name, active, description, parent)
646 ExternalConstraint.__init__(self, exp='', name=name,
647 description=description,
--> 648 active=active, parent=parent)
649 DynamicConstraint.__init__(self, exp_t=exp_t, t_range=t_range,
650 name=name,
d:\00 - eco-sesa\02 - outils\omegalpes\dev_omegalpes\omegalpes\general\optimisation\elements.py in __init__(self, exp, name, description, active, parent)
600 warnings.warn(deprecated_msg, DeprecationWarning)
601
--> 602 self._add_ext_cst_list()
603
604 def _add_ext_cst_list(self):
d:\00 - eco-sesa\02 - outils\omegalpes\dev_omegalpes\omegalpes\general\optimisation\elements.py in _add_ext_cst_list(self)
604 def _add_ext_cst_list(self):
605 if self.parent:
--> 606 if self not in self.parent._external_constraints_list:
607 self.parent._external_constraints_list.append(self)
608 else:
AttributeError: 'EnergyNode' object has no attribute '_external_constraints_list'
```
### Steps to reproduce
Run the Notebook LNCMI in examples/notebooks
### How to fix it?
Inspect the last commits in elements to check the previous version of OMEGAlpes with which it was working properly to understand the bug.
### Note : we will only investigate if the tests are passinghttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/56PuLP version changed2020-05-05T10:37:17+02:00Sacha HodencqPuLP version changedPuLP version recently changed and caused the notebooks to get the following error:
`/srv/conda/envs/notebook/lib/python3.7/site-packages/omegalpes/general/optimisation/model.py in <module>`
`27 import time as pytime`
`28`...PuLP version recently changed and caused the notebooks to get the following error:
`/srv/conda/envs/notebook/lib/python3.7/site-packages/omegalpes/general/optimisation/model.py in <module>`
`27 import time as pytime`
`28`
`---> 29 from pulp import LpProblem, LpStatus, LpVariable, lpSum, LpVariableDict`
`30 from pulp.solvers import LpSolver`
`31`
`ImportError: cannot import name 'LpVariableDict' from 'pulp' (/srv/conda/envs/notebook/lib/python3.7/site-packages/pulp/__init__.py)`
The examples requirements for PuLP have been changed to the version == 1.6.10 instead of >=1.6.10 (see commit in OMEGAlpes_examples). The following steps should be followed:
1. Check if LpVariableDict is used in the OMEGAlpes source code. If not, remove it.
2. Update PuLP to its last version in OMEGAlpes and check if everything works properly (tests, examples, ...).
3. Go back to puLP version >=1.6.10 in OMEGAlpes examples.Sacha HodencqSacha Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/55Graphical representation of AssemblyUnits2020-03-18T15:56:14+01:00Sacha HodencqGraphical representation of AssemblyUnitsThe graphical representations of assembly units, i.e. conversion units and reversible units have been discussed on the 31st of January 2020 with the following conclusions (see the attached picture):
1. The historical representation of ...The graphical representations of assembly units, i.e. conversion units and reversible units have been discussed on the 31st of January 2020 with the following conclusions (see the attached picture):
1. The historical representation of conversion units should be kept
2. The production and consumption units in reversible units will not appear as in conversion units but will be represented as single units, like storage units BUT double arrows will indicate the power flows in reversible units.
3. Storage units will eventually inherit from AssemblyUnit. At the moment, there is a single power flow that can go both ways, represented by a single arrow with two heads. Eventually, it will consists in double arrows, just like other assembly units.
4. ReversibleConversionUnits will abide by these rules.
![GraphReprAssembly](/uploads/8d9c533801db61f2447a0603e00750bb/GraphReprAssembly.JPG)
Other ideas for graphical representation were rejected (see the attached picture):
5. Reversible units with detailed production and consumption, which seemed useless to detail and that would make reversible conversion unit to hard to represent.
6. Conversion units with less detailed units, which seem to make things less understandable.
![GraphReprAssemblyRejected](/uploads/1f580ec3e58a0b77254bebfdfe4a11dc/GraphReprAssemblyRejected.JPG)Sacha HodencqSacha Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/48Getting data more easily - list and dataframe2020-03-13T14:10:11+01:00Lou MorrietGetting data more easily - list and dataframeIt is quite difficult to know how to get easily the data as it is different if it is an int, a float, a list or a dict.
Solution:
**We created the method: get_value()**
see commit ad2a27efc6edef8288e58d43fa6fe8fd95b90739
return the v...It is quite difficult to know how to get easily the data as it is different if it is an int, a float, a list or a dict.
Solution:
**We created the method: get_value()**
see commit ad2a27efc6edef8288e58d43fa6fe8fd95b90739
return the value of the quantity according the type of the value in order to be able to use it easily in print and plot methods:
int -> int
float -> float
list -> list
dict -> list
**and the method: get_value_with_date() -> to be able to associate data to dates (with framadates)**
return the values of the quantity associated to a date in a dataframe if the values are a list or a dict (only).Lou MorrietLou Morriethttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/53pmin & pmax instead of p_min & p_max for VariableEnergyUnits parameters2020-03-13T14:09:43+01:00Lou Morrietpmin & pmax instead of p_min & p_max for VariableEnergyUnits parameterspmin & pmax instead of p_min & p_max for EnergyUnits parameters
- SeveralEnergyUnit
- VariableConsumptionUnit
- SeveralConsumptionUnit
- VariableProductionUnit
- SeveralProductionUnit
Changing it into p_min & p_maxpmin & pmax instead of p_min & p_max for EnergyUnits parameters
- SeveralEnergyUnit
- VariableConsumptionUnit
- SeveralConsumptionUnit
- VariableProductionUnit
- SeveralProductionUnit
Changing it into p_min & p_maxLou MorrietLou Morriethttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/52Cycle error in the storage2020-02-28T12:06:56+01:00Lou MorrietCycle error in the storage### Summary
There is a problem when a storage is create with a number of cycle.
Following error:
TypeError: slice indices must be integers or None or have an __index__ method
I think linked with the creation of the following constraint
...### Summary
There is a problem when a storage is create with a number of cycle.
Following error:
TypeError: slice indices must be integers or None or have an __index__ method
I think linked with the creation of the following constraint
Adding constraint : storage_set_cycles , exp = storage_e[t] == storage_e[t+1.0] for t in time.I[:-1.0]
### Steps to reproduce
```
from omegalpes.energy.units.consumption_units import *
from omegalpes.energy.units.production_units import *
from omegalpes.energy.energy_nodes import *
from omegalpes.general.time import *
from omegalpes.general.optimisation.model import *
from omegalpes.general.utils.plots import *
from omegalpes.general.utils.output_data import save_energy_flows
from pulp import LpStatus
def main():
time = TimeUnit(periods=24, dt=1)
storage = StorageUnit(time, name='storage', energy_type='Electrical',
cycles=1)
variable_production = VariableProductionUnit(time, name='variable_production', energy_type='Electrical')
node = EnergyNode(time, name='node', energy_type='Electrical')
node.connect_units(variable_production, storage)
model = OptimisationModel(time, name='optimization_model')
model.add_nodes(node)
model.solve_and_update()
return model, time, storage, variable_production, node
if __name__ == '__main__':
MODEL, TIME, STORAGE, VARIABLE_PRODUCTION, NODE = main()
```
### What is the current *bug* behavior?
Raise an error
TypeError: slice indices must be integers or None or have an __index__ method
But the cycle indicated is an int.
The problem is in the calculation of the cycle
### What is the expected *correct* behavior?
No errorhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/49HourlyDynamicConstraint for dt<12020-02-27T16:28:59+01:00Sacha HodencqHourlyDynamicConstraint for dt<1HourlyDynamicConstraint can now only be used for dt=1, i.e. for initial and final time defined as hours. It is for instance used in add_availability. Moreover, HourlyDynamicConstraint are actually Daily Dynamic Constraints: the constrain...HourlyDynamicConstraint can now only be used for dt=1, i.e. for initial and final time defined as hours. It is for instance used in add_availability. Moreover, HourlyDynamicConstraint are actually Daily Dynamic Constraints: the constraint is renewed everyday between the init and final hour.Sacha HodencqSacha Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/40Considering Series for p for FixedEnergyUnits2020-02-12T13:56:01+01:00Lou MorrietConsidering Series for p for FixedEnergyUnits### Summary
OMEGAlpes only considers int / float / list / dict in order to create new quantity.
(see omegalpes.general.optimisation.elements.quantity class)
It does not consider array (dataframe) and so raises a TypeError if an Serie i...### Summary
OMEGAlpes only considers int / float / list / dict in order to create new quantity.
(see omegalpes.general.optimisation.elements.quantity class)
It does not consider array (dataframe) and so raises a TypeError if an Serie is used to create a FixedEnergyUnit : `raise TypeError('Unknown type for argument \'value\'')`
If a serie is considered, the time should be compared to the TimeUnit of the project if possible.
For the moment on can use `df = df['value'].values.tolist()` to convert the dataframe into a list of the values.https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/47Wrong calculation for power dictionnary in FixedEnergyUnit2020-02-12T13:56:00+01:00Lou MorrietWrong calculation for power dictionnary in FixedEnergyUnit### Summary
OMEGAlpes recognizes if the data power are a list or a dictionnary.
However, the calculations are inaccurate for dictionnaries for e_tot, p_max and p_min.
**Bug1:**
The dictionnaries are not well updated once the optimisatio...### Summary
OMEGAlpes recognizes if the data power are a list or a dictionnary.
However, the calculations are inaccurate for dictionnaries for e_tot, p_max and p_min.
**Bug1:**
The dictionnaries are not well updated once the optimisation is done
**Bug2:**
if p is a dictionnay, sum(p) takes into account the keys and not the values.
### Example Project
```
def main(work_path):
# Creating the unit dedicated to time management
time = TimeUnit(periods=4, dt=1 )
# Creating an empty model
model = OptimisationModel(time=time, name='elec_prod_simple_example')
# Creating the production units - the production profile are unknown
grid_production_a = VariableProductionUnit(time=time,
name='grid_production_A',
energy_type='Electrical)
dwelling_consumption = FixedConsumptionUnit(time, 'dwelling_consumption',
energy_type='Electrical',
p={0: 162.0, 1: 138.0,
2: 91.0, 3: 100})
# Creating the energy nodes and connecting units
elec_node = EnergyNode(time, 'elec_node', energy_type='Electrical')
elec_node.connect_units(dwelling_consumption, grid_production_a)
# Adding the energy node to the model
model.add_nodes(elec_node)
# Optimisation process
model.writeLP(work_path + r'\optim_models\elec_prod_simple_example.lp')
model.solve_and_update() # Run optimization and update values
return model, time, dwelling_consumption, grid_production_a
def print_results():
if LpStatus[MODEL.status] == 'Optimal':
print("\n - - - - - OPTIMIZATION RESULTS - - - - - ")
print('Dwelling consumption = {0} kWh.'.format(
DWELLING_CONSUMPTION.e_tot))
print('Dwelling consumption = {0} kWh.'.format(
DWELLING_CONSUMPTION.p))
print('grid_production A production = {0} kWh'.format(
GRID_PRODUCTION_A.e_tot))
print('grid_production A production = {0} kWh'.format(
GRID_PRODUCTION_A.p))
elif LpStatus[MODEL.status] == 'Infeasible':
print("Sorry, the optimisation problem has no feasible solution !")
elif LpStatus[MODEL.status] == 'Unbounded':
print("The cost function of the optimisation problem is unbounded !")
elif LpStatus[MODEL.status] == 'Undefined':
print("Sorry, a feasible solution has not been found (but may exist). "
"PuLP does not manage to interpret the solver's output, "
"the infeasibility of the MILP problem may have been "
"detected during presolve")
if __name__ == "__main__":
WORK_PATH = os.getcwd()
# *** RUN MAIN ***
MODEL, TIME, DWELLING_CONSUMPTION, GRID_PRODUCTION_A, \
= main(work_path=WORK_PATH)
# *** SHOW RESULTS ***
print_results()
```
### What is the current *bug* behavior?
**Bug1:**
Dwelling consumption = 6.0 kWh.
Dwelling consumption = {0: 3.0, 1: 3.0, 2: 0.0, 3: 0.0} kWh.
**Bug2:**
Infeasible because of the following constraint:
dwelling_consumption_calc_e_tot: dwelling_consumption_e_tot = 491.0
### What is the expected *correct* behavior?
Dwelling consumption = 491.0 kWh.
Dwelling consumption = {0: 162.0, 1: 138.0, 2: 91.0, 3: 100} kWh.
### Possible fixes
**Solving Bug1:**
In model.py, updating dictionnary should be fixed as follow:
```
# If the values are stored in a dictionary
if isinstance(q_val, dict):
if any(i for i in q_opt.values()):
globals()[q_name] = LpVariable.dict(name=q_name,
indexs=q_val.keys(),
lowBound=q_lb, upBound=q_ub,
cat=q_type)
else:
globals()[q_name] = q_val
```
In elements.py, correct
```
elif isinstance(value, dict):
# The value is a dict
** if any(isinstance(n, (int, float)) for n in list(
value.values())):**
# At least one value of the dict is specified
self.opt = {}
# The opt parameter is a dict of False
self.opt.update({i: False for i in list(value.keys())})
```
**Solving Bug2**
in EnergyUnits.py class FixedEnergyUnit
```
if isinstance(p, list):
e_tot = sum(p) * time.DT
p_min = min(p)
p_max = max(p)
elif isinstance(p, dict):
# Checking the length of the dictionary corresponds to the length
# of the time unit
if len(time.DATES) == len(p):
e_tot = sum(p.values()) * time.DT
p_min = min(p.values())
p_max = max(p.values())
```Lou MorrietLou Morriethttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/44Conversion & production units are not "reversible" at the moment2020-02-11T17:36:29+01:00Sacha HodencqConversion & production units are not "reversible" at the moment### Summary
In the conversion unit, the energy can only flow in a unique way since the conversion unit is made of one or several consumption and production units, while in some cases it needs to flow in both ways. **Moreover, there is n...### Summary
In the conversion unit, the energy can only flow in a unique way since the conversion unit is made of one or several consumption and production units, while in some cases it needs to flow in both ways. **Moreover, there is no such thing as a reversible production unit at the moment** (unit that can either produce or consume energy, such as an electrical motor).
### Possible fixes
Creating new conversion units doubling units in the sense that any consumption unit will have its associated production unit and vice versa. This way, the conversion unit will be reversible.
*Example :* for a HV/LV electrical transformer, HV production AND consumption units are created and LV production AND consumption unit are created. The HV and LV units are respectively linked to HV and LV node, and the units are linked through typical transformer equations (efficiency for instance).
### Work at the moment
This issue will be investigated in the ONIRI example available on dev_example_sh branch of OMEGAlpes examples.Sacha HodencqSacha Hodencqhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/3check pep82019-12-09T14:23:16+01:00Lou Morrietcheck pep8afin de s’assurer d’avoir une qualité de code correcte sont :
— black: formate automatiquement le code source (non configurable)
— flake8: mesure le respect de la PEP-8
— pylint: mesure la qualité du code (PEP-8 et analyse statique)
Le ...afin de s’assurer d’avoir une qualité de code correcte sont :
— black: formate automatiquement le code source (non configurable)
— flake8: mesure le respect de la PEP-8
— pylint: mesure la qualité du code (PEP-8 et analyse statique)
Le formatage par défaut de black respecte en grande partie la PEP-8, tout en faisant l’impasse sur
certaines règles. Par défaut, black s’assure que les lignes ne dépassent pas 88 caractères (contre 80 selon
la PEP-8) et ajoute des espaces, virgules et parenthèses afin de simplifier la lecture et l’ajout de lignes au
code. Ce comportement déclenche des alertes lors des analyses par les outils flake8 et pylint, qui devront
être configurés en conséquence.Camille PajotCamille Pajothttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/4typing2019-12-09T14:23:07+01:00Lou Morriettyping— mypy: analyse statique du code (typage)
L’ajout du typage, validé par mypy et utilisé par PyCharm, permettra de faciliter le développement. La
documentation sur le typage de Python est associée au module typing.
https://docs.python.or...— mypy: analyse statique du code (typage)
L’ajout du typage, validé par mypy et utilisé par PyCharm, permettra de faciliter le développement. La
documentation sur le typage de Python est associée au module typing.
https://docs.python.org/3/library/typing.htmlhttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/34Double print of unit creation2019-11-26T16:18:24+01:00EXT HodencqDouble print of unit creation<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Bug" label, following this link :
- https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/issues?label_name%...<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "Bug" label, following this link :
- https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/issues?label_name%5B%5D=bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
The created units have several messages showing they have been created instead of one
### Steps to reproduce
Can be checked in any example
### Possible fixes
The bug may be caused by the multi-inheritances of units
### Note : we will only investigate if the tests are passingCamille PajotCamille Pajothttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/2add version and docformat2019-07-17T19:55:20+02:00Lou Morrietadd version and docformatAdd in each module:
__version_info__ Version sous forme de tuple d’entiers :(1, 0, 0)
__version__ Version en chaîne de caractères : “1.0.0”, ou encore
[str(x) for x in __version_info__]
__docformat__ Format de documentation (“restructur...Add in each module:
__version_info__ Version sous forme de tuple d’entiers :(1, 0, 0)
__version__ Version en chaîne de caractères : “1.0.0”, ou encore
[str(x) for x in __version_info__]
__docformat__ Format de documentation (“restructuredtext en”Camille PajotCamille Pajothttps://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/11setup.py2019-07-17T19:53:42+02:00Lou Morrietsetup.pyDo the setup.py
Une fois que la structure de projet standard aura été respectée, il sera possible d’ajouter le fichier setup.py 3 . Ce fichier définit la description du paquet qui sera transmis au Python Package Index 4 e...Do the setup.py
Une fois que la structure de projet standard aura été respectée, il sera possible d’ajouter le fichier setup.py 3 . Ce fichier définit la description du paquet qui sera transmis au Python Package Index 4 et devra être appelé directement pour généré les binaires diffusables.https://gricad-gitlab.univ-grenoble-alpes.fr/omegalpes/omegalpes/-/issues/5docstring2019-07-17T19:53:24+02:00EXT HodencqdocstringFilling in the doscstrings for the different modules and classes.Filling in the doscstrings for the different modules and classes.