sanpen / gridcal Goto Github PK

Hi Santiago,

The last few builds on readthedocs failed because it looks like it can't install the latest version of matplotlib (3.1.0), see here: https://readthedocs.org/projects/gridcal/builds/9306186/

Did you need this particular version or could you stay with 3.0.3 for the time being? https://pypi.org/project/matplotlib/#history

I made a branch with version 3.0.3 and the doc builds (see https://readthedocs.org/projects/gridcal-wip/builds/9307871/). If you're fine with version 3.0.3, you can create a PR from here: https://github.com/miek770/GridCal/tree/matplotlib_3_0_3

P.S.: Do you receive email warnings when a RTD build fails? If not, you can enable it from your portal.

Bye,

Michel

Hi Santiago,

I did some research on pulp because of the decrepation error it throws when pytest is called (see here) and found that it's no longer maintained: pulp issues 183.

thomasnield suggested moving to pyomo. He also provided a link to a comparison between pyomo and pulp: https://pyomocontrib-simplemodel.readthedocs.io/en/latest/knapsack.html.

Should we start looking into migrating from pulp to pyomo? Based on your experience, would that be very complicated or relatively straightforward?

Hi Santiago,

So the new documentation is pretty much ready to go, I'd like to have your input before doing the PR. Could you please check it out here: https://gridcal-wip.readthedocs.io/?

Please note that I've adapter the README.md accordingly, see here: https://github.com/miek770/GridCal/blob/doc/README.md. I've also added a basic contribution guide here: https://gridcal-wip.readthedocs.io/development.html#contributing, following #60.

Next steps:

• Remove the GitHub wiki, and integrate its information to Read the Docs (RTD);
• Expand autodoc's coverage to additional modules/classes (reformat docstrings accordingly);
• Integrate the HVDC manual;
• Remove GridCal's PDF manual from the repo;
• Activate PDF generation on RTD;
• Document the different types of analysis and their respective options.

Let me know what you think!

Michel

2019-02-07: Added item; crossed item.

This is a reminder to change the adjust_tap_changer() method to skip to the final tap instead of cycling one tap at a time. This would significantly reduce the number of iterations for simulations using voltage regulators.

Dear San,

are there currently any plans to add support for CIM?

Thank you

Hi,
I have recently been testing out GridCal. So far most things have been running very smoothly, except HELM.

I have tested with several different grids I have saved in the PSSE raw format as well as the five bus example provided in the GridCal documentation. In the case of the five bus example I merely changed the SolverType to HELM. In all cases I get the error below. Any idea what I could be doing wrong or if this is a known issue? In case I should provide more information please tell me.

GridCal\Engine\Simulations\PowerFlow\helm_power_flow.py in get_rhs(n, V, W, Q, Vbus, Vst, Sbus, Pbus, nsys, nbus2, pv, pq, pvpos)
    147
    148     # compute the formulas
--> 149     f2 = Pbus[pv] * W[np.ix_(n-1, pv)] + QW_convolution
    150
    151     epsilon = -0.5 * VV_convolution

\numpy\lib\index_tricks.py in ix_(*args)
     97         new = asarray(new)
     98         if new.ndim != 1:
---> 99             raise ValueError("Cross index must be 1 dimensional")
    100         if new.size == 0:
    101             # Explicitly type empty arrays to avoid float default

ValueError: Cross index must be 1 dimensional

Hi,

This is something I wanted to discuss before I submit a pull request. In fact there are 3 reasons why:

1. I used f-strings, because they're awesome, but it requires Python 3.6 (and I think you use 3.5);
2. I used pytest, which I believe is not currently part of your project;
3. I have done some testing (see below), but not extensive testing.

I was wondering how a transformer's voltage regulator should be implemented in GridCal, and came up with this : miek770@e8d8a99. There are a few relativement minor modifications to the Devices.Branch class, as well as a new test file.

Basically, I'm running the full load flow on the grid, and then I check if voltage regulators take action, and if so I run it again.

It appears to work well, but it annoys me a little that this logic is outside of the MultipleCircuit class. I think it's how we currently have to do it because of how the project is structured. It could also be included in a new wrapper function, for ex.: run_pf_with_regulation(grid, options) which would return grid and power_flow.results.

Any thoughts?

Edit: BTW, the console output from running this test with -s is here: https://pastebin.com/raw/LEyQwB0A

When there are buses with the same name in a GridCal xlsx file.

The repeated nodes become orphan and the branches connect to the bus with the same name that appeared first.

ie:
2 buses with the name "THIS_BUS"
All the branches will refer to the first bus and neglect the second.

Solution:
Either forbid same name buses, or use a fictitious numbering in the files

Hi,

I'm having trouble getting the PV mode (voltage control) to work. I'm working on a unit test (with pytest) for a simple scenario with voltage control, but it seems like q_min and q_max are set to 0 for non-slack generators, even though this returns the correct limits:

for g in grid.get_controlled_generators():
    print(f"Generator {g}: q_min={g.Qmin}, q_max={g.Qmax}")

...results in:

Generator Utility: q_min=-9999.0, q_max=9999.0
Generator M32: q_min=-2.0, q_max=2.0

I have uploaded my test grid as well as its simulation results.

Excel input: https://www.dropbox.com/s/yyzwpbj2cnu04b8/test_gridcal_pv.xlsx?dl=0
Excel output (results): https://www.dropbox.com/s/oqiu2pdazyes5wi/results_test_gridcal_pv.xlsx?dl=0

I had a look at the PowerFlowMP.switch_logic() code and it seems to have been rather well developped, so I'm guessing that either:

1. I have made a mistake somewhere in my modeling; or
2. It used to work but some change at some point created a small bug with this feature.

Here's the output from GridCal's logger (from pytest's failed test):

---------------------------- Captured stdout call -----------------------------
Padmount transformer updtaed!
Substation transformer updtaed!



Compiling...Trying SolverType.LM
Trying SolverType.IWAMOTO
Control logic
Bus 3  switched to PQ: Q -0.09290827037827094  Qmin: 0.0
Control logic
Bus 3  switched to PQ: Q 2.333504875873943e-10  Qmax: 0.0
Control logic
Bus 3  switched to PQ: Q 2.333504875873943e-10  Qmax: 0.0
Control logic
Bus 3  switched to PQ: Q 2.333504875873943e-10  Qmax: 0.0
Control logic
Bus 3  switched to PQ: Q 2.333504875873943e-10  Qmax: 0.0
Control logic
Bus 3  switched to PQ: Q 2.333504875873943e-10  Qmax: 0.0
Control logic
Bus 3  switched to PQ: Q 2.333504875873943e-10  Qmax: 0.0
Control logic
Bus 3  switched to PQ: Q 2.333504875873943e-10  Qmax: 0.0
Control logic
Bus 3  switched to PQ: Q 2.333504875873943e-10  Qmax: 0.0
Control logic
Bus 3  switched to PQ: Q 2.333504875873943e-10  Qmax: 0.0

Thank you, and let me know if you need additional information.

Your GPLv3 license file at UnderDevelopment/LICENSE.txt is not detected by GitHub and was missed by me until a colleague sent me the URL. Perhaps you can put a symlink in the root directory or provide some other kind of fix? With best wishes, Robbie

Dear Santiago,
my name is Jakov Krstulovic Opara, and I am one of the contributors to pandapower.
we have been implementing zip loads to pandapower pf, so I had a look at your code and I came into a doubt when looking at consideration of constant current loads in the dSbus_dV function (specifically here):
so for sparse Ybus version there is: Ibus = Ybus * V - I, while for non-sparse (here) there is: Ibus = Ybus * asmatrix(V).T + I
according to what it seems to me and according to sing of I for a load, I would say it should be + ?

Thank you and sorry for bothering you with this...also sorry if I misunderstood something...

also I need to say my great congratulation for GridCal - it is really a great tool which was missing in open-source of power system analysis...it is fascinating you did all by yourself! great work!

Hi Santiago,

When running a PF in the GUI with "Automatic precision" checked, I get the following error:

Traceback (most recent call last):
  File "C:\Users\michel\gits\windfarm\GridCal\src\GridCal\Gui\Main\GridCalMain.py", line 1830, in run_power_flow
    lg = np.log10(abs(self.circuit.numerical_circuit.Sbus.real))
AttributeError: 'NoneType' object has no attribute 'Sbus'

...which I assume happens because MultiCircuit hasn't been compiled yet. If I run a PF without this option first, and then run it again with this option, I get:

Traceback (most recent call last):
  File "C:\Users\michel\gits\windfarm\GridCal\src\GridCal\Gui\Main\GridCalMain.py", line 1830, in run_power_flow
    lg = np.log10(abs(self.circuit.numerical_circuit.Sbus.real))
AttributeError: 'NumericalCircuit' object has no attribute 'Sbus'

I can see that NumericalCircuit doesn't have an Sbus attribute, but I'm not sure what the value we want to use is exactly.

Regards,

Michel

Hi! I need to simulate a grid with a battery charging and discharging over the day.
Is there any grid example with a battery and its profile?
How should we specify a charging/discharging value in the a battery profile?

I have added a sheet named "battery_Pprof", with different values (in MW) for every battery and hour. The batteries are already defined in "battery" sheet. It seems to be something wrong in battery profile data because when I want to display it in GridCal "Time events" tab it comes down.

About simulation, in branch power plot I don't know why appears a lot of reactive power on battery branches, when I have only resistive load profiles.

Also if I want to save the document appears this error: 'NoneType' object has no attribute 'values'.

Thank you!

Hi Santiago,

There are a few rendering issues with this section: https://gridcal.readthedocs.io/en/latest/models/from_objects_to_matrices.html.

For the right-justified formulas, you have to break them into individual :math: sections to get them all to be centered.

For the figures, I haven't looked into it but you could compare with another section that has some to find the difference.

Good evening,

Michel

Hello, I'm currently using the GUI of GridCal for power systems analysis. After reading the documentation, running a power flow & CPF on a 5 bus system, I wanted to know the difference between the NOSE and the FULL CURVE setting for voltage stability.

Ideally, I expect to get a half curve until the bifurcation point if I choose NOSE (similar to something blow)

& I expect to the entire curve if I choose FULL CURVE (similar to something below)

However, irrespective of choosing NOSE or FULL CURVE I only get half the curve similar to the first figure when I plot it using the GUI. Is my understanding correct regarding the settings?

Hi, Santiago

I'm a student in China and now using GridCal for my learning of Grid, thanks for your great tool!

As the title, here are some errors in my computer system, Windows 10, Python 3.6.1.

When I run the python code like:

from GridCal.ExecuteGridCal import run
run()

It will report that:

Warning (from warnings module):
File "D:\Program Files\Python36\lib\site-packages\matplotlib_init_.py", line 1405
warnings.warn(_use_error_msg)
UserWarning:
This call to matplotlib.use() has no effect because the backend has already
been chosen; matplotlib.use() must be called before pylab, matplotlib.pyplot,
or matplotlib.backends is imported for the first time.

Warning (from warnings module):
File "D:\Program Files\Python36\lib\site-packages\matplotlib\cbook.py", line 136
warnings.warn(message, mplDeprecation, stacklevel=1)
MatplotlibDeprecationWarning: The axisbg attribute was deprecated in version 2.0. Use facecolor instead.

Warning (from warnings module):
File "D:\Program Files\Python36\lib\site-packages\GridCal\grid\CalculationEngine.py", line 2099
warn('The file does not exist.')
UserWarning: The file does not exist.

I just updated the GridCal, don't know whether the Mac or Ubuntu will report like that too.

The other problem is when I run with the user interface. After I dragged some buses and set some value, I clicked the Save Button and clicked the Save in the explorer window appeared, it will prompt stop running and had no error report.

I'm not quite sure how this happened, but when I opened your sample xlsx file, it would not seem to have the same mistake.

Hello,

I have successfully installed GridCal by installing anaconda, however, I'm unable to run it using this command: python -c "from GridCal.ExecuteGridCal import run; run()" on my windows 10. Whenever I run it I get the following error:

KLU failed
Pardiso failed
UmfPack failed
Falling back to Blas/Lapack
Using Blas/Lapack
Traceback (most recent call last):
File "", line 1, in
File "C:\Users\Anmol\Anaconda3\lib\site-packages\GridCal\ExecuteGridCal.py", line 23, in
from GridCal.Gui.Main.GridCalMain import run
File "C:\Users\Anmol\Anaconda3\lib\site-packages\GridCal\Gui\Main\GridCalMain.py", line 20, in
from GridCal.Gui.GridEditorWidget import *
File "C:\Users\Anmol\Anaconda3\lib\site-packages\GridCal\Gui\GridEditorWidget_init_.py", line 15, in
from GridCal.Gui.GridEditorWidget.editor import *
File "C:\Users\Anmol\Anaconda3\lib\site-packages\GridCal\Gui\GridEditorWidget\editor.py", line 23, in
from GridCal.Engine.Core.multi_circuit import MultiCircuit
File "C:\Users\Anmol\Anaconda3\lib\site-packages\GridCal\Engine_init_.py", line 19, in
from GridCal.Engine.grid_analysis import *
File "C:\Users\Anmol\Anaconda3\lib\site-packages\GridCal\Engine\grid_analysis.py", line 18, in
from GridCal.Engine.Simulations.PowerFlow.time_series_driver import TimeSeriesResults
File "C:\Users\Anmol\Anaconda3\lib\site-packages\GridCal\Engine\Simulations_init_.py", line 18, in
from GridCal.Engine.Simulations.Stochastic import *
File "C:\Users\Anmol\Anaconda3\lib\site-packages\GridCal\Engine\Simulations\Stochastic_init_.py", line 16, in
from GridCal.Engine.Simulations.Stochastic.lhs_driver import *
File "C:\Users\Anmol\Anaconda3\lib\site-packages\GridCal\Engine\Simulations\Stochastic\lhs_driver.py", line 21, in
from GridCal.Engine.Simulations.PowerFlow.power_flow_results import PowerFlowResults
File "C:\Users\Anmol\Anaconda3\lib\site-packages\GridCal\Engine\Simulations\PowerFlow_init_.py", line 2, in
from GridCal.Engine.Simulations.PowerFlow.power_flow_worker import *
File "C:\Users\Anmol\Anaconda3\lib\site-packages\GridCal\Engine\Simulations\PowerFlow\power_flow_worker.py", line 22, in
from GridCal.Engine.Simulations.PowerFlow.jacobian_based_power_flow import IwamotoNR
File "C:\Users\Anmol\Anaconda3\lib\site-packages\GridCal\Engine\Simulations\PowerFlow\jacobian_based_power_flow.py", line 27, in
from GridCal.Engine.Simulations.PowerFlow.numba_functions import calc_power_csr_numba, diag
File "C:\Users\Anmol\Anaconda3\lib\site-packages\GridCal\Engine\Simulations\PowerFlow\numba_functions.py", line 23, in
def calc_power_csr_numba(n, Yp, Yj, Yx, V, I, n_par=500):
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\decorators.py", line 200, in wrapper
disp.compile(sig)
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\compiler_lock.py", line 32, in _acquire_compile_lock
return func(*args, **kwargs)
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\dispatcher.py", line 768, in compile
cres = self._compiler.compile(args, return_type)
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\dispatcher.py", line 77, in compile
status, retval = self._compile_cached(args, return_type)
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\dispatcher.py", line 91, in _compile_cached
retval = self._compile_core(args, return_type)
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\dispatcher.py", line 109, in _compile_core
pipeline_class=self.pipeline_class)
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\compiler.py", line 551, in compile_extra
return pipeline.compile_extra(func)
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\compiler.py", line 331, in compile_extra
return self._compile_bytecode()
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\compiler.py", line 393, in _compile_bytecode
return self._compile_core()
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\compiler.py", line 373, in _compile_core
raise e
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\compiler.py", line 364, in _compile_core
pm.run(self.state)
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\compiler_machinery.py", line 347, in run
raise patched_exception
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\compiler_machinery.py", line 338, in run
self._runPass(idx, pass_inst, state)
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\compiler_lock.py", line 32, in _acquire_compile_lock
return func(*args, **kwargs)
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\compiler_machinery.py", line 302, in _runPass
mutated |= check(pss.run_pass, internal_state)
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\compiler_machinery.py", line 275, in check
mangled = func(compiler_state)
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\typed_passes.py", line 407, in run_pass
NativeLowering().run_pass(state)
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\typed_passes.py", line 349, in run_pass
lower.lower()
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\lowering.py", line 195, in lower
self.lower_normal_function(self.fndesc)
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\lowering.py", line 248, in lower_normal_function
entry_block_tail = self.lower_function_body()
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\lowering.py", line 273, in lower_function_body
self.lower_block(block)
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\lowering.py", line 288, in lower_block
self.lower_inst(inst)
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\lowering.py", line 476, in lower_inst
func(self, inst)
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\npyufunc\parfor.py", line 52, in _lower_parfor_parallel
ensure_parallel_support()
File "C:\Users\Anmol\Anaconda3\lib\site-packages\numba\parfor.py", line 4156, in ensure_parallel_support
raise errors.UnsupportedParforsError(msg)
numba.errors.UnsupportedParforsError: Failed in nopython mode pipeline (step: nopython mode backend)
�[1m�[1mThe 'parallel' target is not currently supported on Windows operating systems when using Python 2.7, or on 32 bit hardware.�[0m
�[0m�[1m[1] During: lowering "id=0[LoopNest(index_variable = parfor_index.15, range = (0, n, 1))]{277: <ir.Block at C:\Users\Anmol\Anaconda3\lib\site-packages\GridCal\Engine\Simulations\PowerFlow\numba_functions.py (38)>}Var(parfor_index.15, numba_functions.py:38)" at C:\Users\Anmol\Anaconda3\lib\site-packages\GridCal\Engine\Simulations\PowerFlow\numba_functions.py (38)�[0m

Could you please help me here? I'm not sure what I'm doing wrong.

Start point: CalculationEngine.py

    def delete_bus(self, obj: Bus):
        """
        Remove bus
        @param obj: Bus object
        """

        # remove associated branches in reverse order
        for i in range(len(self.branches) - 1, -1, -1):
            if self.branches[i].bus_from == obj or self.branches[i].bus_to == obj:
                self.branches.pop(i)

        # remove the bus itself
        self.buses.remove(obj)

I suspect this is because of QT threading...

In order to upgrade GridCal reliably, one needs to be able to tell which version is greater by the version number. GridCal has used semantic version numbers for this purpose for almost a year (3.0.1 - Sep 27, 2018) now. However, GridCal 3.5 breaks this feature by dropping the patch level from the version number. Now it is unclear whether version 3.5 is larger or smaller than version (non-existent) 0.3.6. I would suggest adding the patch level back in again, maybe in a version 3.5.1.

@miek770 , it'll be great is you could document the heuristic algorithms made for tap adjustment and reactive power control.

No rush, but just to keep track.

BTW, I'm thinking about using some project management tool to make a roadmap and have tasks like Zenkit

Created empty Anaconda environment, installed GridCal via "pip install GridCal", activated the environment, then I run file with a code

pip install GridCal

and got this:

KLU failed
Pardiso failed
UmfPack failed
Falling back to Blas/Lapack
Using Blas/Lapack
Traceback (most recent call last):
File "F:\Visual Studio 2017\gridcal\gridcal_test\gridcal_test.py", line 1, in
from GridCal.ExecuteGridCal import run
File "C:\ProgramData\Anaconda3\envs\gridcal\lib\site-packages\GridCal\ExecuteGridCal.py", line 23, in
from GridCal.Gui.Main.GridCalMain import run
File "C:\ProgramData\Anaconda3\envs\gridcal\lib\site-packages\GridCal\Gui\Main\GridCalMain.py", line 20, in
from GridCal.Gui.GridEditorWidget import *
File "C:\ProgramData\Anaconda3\envs\gridcal\lib\site-packages\GridCal\Gui\GridEditorWidget_init_.py", line 15, in
from GridCal.Gui.GridEditorWidget.editor import *
File "C:\ProgramData\Anaconda3\envs\gridcal\lib\site-packages\GridCal\Gui\GridEditorWidget\editor.py", line 23, in
from GridCal.Engine.Core.multi_circuit import MultiCircuit
File "C:\ProgramData\Anaconda3\envs\gridcal\lib\site-packages\GridCal\Engine_init_.py", line 23, in
from GridCal.Engine.IO import *
File "C:\ProgramData\Anaconda3\envs\gridcal\lib\site-packages\GridCal\Engine\IO_init_.py", line 13, in
from GridCal.Engine.IO.excel_interface import *
File "C:\ProgramData\Anaconda3\envs\gridcal\lib\site-packages\GridCal\Engine\IO\excel_interface.py", line 37, in
def get_objects_dictionary(circuit=MultiCircuit()):
File "C:\ProgramData\Anaconda3\envs\gridcal\lib\site-packages\GridCal\Engine\Core\multi_circuit.py", line 86, in init
self.user_name = get_system_user()
File "C:\ProgramData\Anaconda3\envs\gridcal\lib\site-packages\GridCal\Engine\Core\multi_circuit.py", line 38, in get_system_user
user = getUser()
File "C:\ProgramData\Anaconda3\envs\gridcal\lib\site-packages\GridCal\Engine\Core\multi_circuit.py", line 36, in
getUser = lambda: os.environ["USERNAME"] if "C:" in os.getcwd() else os.environ["USER"]
File "C:\ProgramData\Anaconda3\envs\gridcal\lib\os.py", line 679, in getitem
raise KeyError(key) from None
KeyError: 'USER'

What do I do wrong?

Hi Sean,

I am trying to install GridCal in Win 10, but I keep facing the error, see screen shot, I have tried all the remedies with regards to it on the internet but nothing seems to work. Need your help...

Remove:

self.pool = multiprocessing.Pool()

from all the constructors

Hi Santiago,

I tried to use pyinstaller with ExecuteGridCal.py to output the .exe file for Windows, and it built successfully.

But when I tried to run the ExecuteGridCal.exe, it shows the error below:

E:\PythonProject\GridCal\UnderDevelopment\GridCal\dist\ExecuteGridCal>ExecuteGridCal.exe
Numba was detected, enjoy :D
Traceback (most recent call last):
File "GridCal\ExecuteGridCal.py", line 21, in
File "", line 971, in _find_and_load
File "", line 955, in _find_and_load_unlocked
File "", line 665, in _load_unlocked
File "D:\Anaconda3\lib\site-packages\PyInstaller\loader\pyimod03_importers.py", line 631, in exec_module
exec(bytecode, module.dict)
File "GridCal\gui\main\GridCalMain.py", line 16, in
File "", line 971, in _find_and_load
File "", line 955, in _find_and_load_unlocked
File "", line 665, in _load_unlocked
File "D:\Anaconda3\lib\site-packages\PyInstaller\loader\pyimod03_importers.py", line 631, in exec_module
exec(bytecode, module.dict)
File "GridCal\grid\CalculationEngine.py", line 18, in
File "", line 971, in _find_and_load
File "", line 955, in _find_and_load_unlocked
File "", line 665, in _load_unlocked
File "D:\Anaconda3\lib\site-packages\PyInstaller\loader\pyimod03_importers.py", line 631, in exec_module
exec(bytecode, module.dict)
File "GridCal\grid\JacobianBased.py", line 176, in
File "site-packages\numba\decorators.py", line 192, in wrapper
File "site-packages\numba\dispatcher.py", line 490, in enable_caching
File "site-packages\numba\caching.py", line 594, in init
File "site-packages\numba\caching.py", line 330, in init
RuntimeError: cannot cache function 'create_J': no locator available for file 'GridCal\grid\JacobianBased.py'
[3512] Failed to execute script ExecuteGridCal

It seems some errors with numba and I have no idea what happened with it. But it wasn't a serious problem and hope you could give suggestion when you are free.

Thank you for your jobs. GridCal is really a nice software!

When importing a DGS file, I hit this warning:

However, there are more than zero (3) transformer types, as requested here:

Does this else block need to be indented a level less?

(Note that these embedded code snippets do not reflect the intentation levels in the actual file.)

Hi Santiago,

Is there an issue with OpfDriver? I noticed it was commented out from GridCalMain.py, leading to the following error when invoked from the GUI:

Traceback (most recent call last):
  File "C:\Users\michel\gits\windfarm\GridCal\UnderDevelopment\GridCal\Gui\Main\GridCalMain.py", line 2498, in run_opf
    self.optimal_power_flow = OptimalPowerFlow(self.circuit, options)
NameError: name 'OptimalPowerFlow' is not defined

I tried removing the comment and running it on the IEEE 30 Bus with storage.xlsx grid and it seems to be working fine, although I didn't really analyze the results.

Michel

Edit: It was commented out in this commit, but it doesn't really say why.

Hi Michel ( @miek770 ),

I see that in the branch device there is another style of documentation.
Why did you choose that format?

Before I was using the style that is automatically generated by pycharm. I agree that the style was not consistent because for some reason the default pycharm format varies. At least for me it is important that an IDE can generate the docstring automatically from a function definition.

BR,
Santiago

Hi,

installed the software with pip install GridCal.
Didn't start, two dependencies were missing: pulp and geopy
Please add them to your setup.py

There is now a proper test suite which can be used to test the code for regressions. With minor modifications, these tests can be run in a continuous integration environment. This enables them to be executed on every push, thus catching regressions before publication of new docs and package versions. Catching errors after pushing and before releasing can prevent some errors to affect users. To demonstrate the feasibility, I set a pipeline up over on GitLab.com, because that is what I know my way around best:

https://gitlab.com/gridcal/gridcal/pipelines/67806167

Hi Santiago,

I couldn't create a webhook on read the docs for this repo because it's on your account. The webhook is used to automatically update the doc each time there's a commit in the followed branches (master in this case).

The documentation to setup a webhook on GitHub are here: https://docs.readthedocs.io/en/latest/webhooks.html.

Otherwise I (or you if you create a RTD account) have to do it manually each time. I just updated then for yesterday's merged PR.

Sorry, I would have liked to set it up completely but I'm stuck.

Michel

The resistance of a line or cable varies with its temperature, and it would be a good idea to include this feature to the branch class. Typically, the highest temperature (ex.: 90°C) is used for load flow simulations, and a lower temperature (ex.: 20°C) is used for short circuit simulations.

If the branch model had a base temperature attribute, we could easily add a method to adjust the resistance based on the simulation temperature using the following formulas:

R’  = R ( 234.5 + Tc )/( 234.5 + Tb )  Copper Conductors
R’ = R ( 228.1 + Tc )/( 228.1 + Tb )  Aluminum Conductors

where:
    R = Resistance at base temperature Tb
    R’ = Resistance at operating temperature Tc
    Tb = Conductor base temperature in °C
    Tc = Conductor temperature limit in °C

This factor may seem neglectable for high voltage transmission networks, but it can be rather significant for certain applications (ex.: for calculating and demonstrating electrical losses vs contractual requirements).

Hi,

I would like to suggest adding basic CLI examples for working with gridcal without the GUI, for example in a Python script. I tried to find some in the manual and the wiki but didn't.

Also, a mailing list it a forum would be nice, and a probably better place to ask questions than a GitHub issue.

Thanks.

Hi @SanPen,

I'm currently using GridCal with pyswarms to research automated optimal grid design. The first step implies running millions of power flow simulations (ACLPF), several of which having no slack node. I need to shut the warnings off. I thought about simply calling the power flow this way from my code:

with warnings.catch_warnings():
    power_flow.run()

...but that doesn't work; warnings still show in the terminal. warnings.catch_warnings() is described as being not thread-safe, so that might be why it fails to hide warnings in this context.

So, I'd like to add a quiet flag to PowerFlowOptions, with either a temporary filter, or a bunch of checks in the code:

if not quiet:
    warn("Warning message")

I can prepare a pull request but I'd like to know your preference. Ideally, the same behavior would be implemented in the other modules as well.

Thanks!

Hi Santiago,

I believe Qmin and Qmax for the ControlledGenerator class should be changed from attributes to methods. By default the methods could return the related attributes:

def q_min(self):
    return self.Qmin

def q_max(self):
    return self.Qmax

...but doing it this way (through methods) allows users to subclass ControlledGenerator and change this behavior without having to rewrite the whole __init__() method.

The reason why this is interesting is that the VAr limits are actually variable, and that the Qmin / Qmax we currently use are points on curves (Qmax is point B in this reference). For synchronous generators Qmin/max mostly depend on the active power, but for other types of generators it might be different. For example, the last wind turbine I worked with had its VAr limits vary as a function of both voltage and active power.

Would you be ok with that?

Thank you. - Michel

Hi Santiago,

I need your help for an issue I'm trying to debug. In my simulations, there are several controlled generators misbehaving. Basically, some generators don't seem to be pushing in the right direction, or not pushing at all. They all have the same 1.0pu voltage setpoint and the same Q limits, but some of them stay at 0pu (Q) and 0.98pu (V) even though their limit is +/-0.02pu (Q).

I did some troubleshooting in this branch (not for merging), and it seems like PowerFlowMP.solve() doesn't care about vset for PV buses. The switch logic is fine for switching back-and-forth from PV to PQ, and preventing over/under excitation. But if the bus remains in PV mode, it won't raise or lower its Q in PowerFlowMP.solve().

I really don't know much about power flow algorithms. I might have messed something up in the above branch, but started the investigation because the problem was pre-existing. I could share my Excel grid by email but it'd have to be private, it's for an existing project.

Brainstorming

If I understand correctly: the solver tries to solve the matrices to reach the voltage_solution (or V0). If it can, great (it converged). Otherwise, it returns a new voltage solution and tries to converge again based on this new V0.

The initial V0/voltage_solution in GridCal, for PV buses, are the buses' vset (more specifically their controlled generators' vset). So the first time it runs, it uses the correct setpoint. But in subsequent iterations it uses the previous result (voltage solution) as its new setpoint, instead of vset.

So should we replace the PV buses' voltage_solution be their vset after each iteration, if it hasn't reached its Q limit (basically when it remains a PV bus in the switch_logic())?

Thanks.

After having problems trying to install with Python 3.6, I've created an environment using Python 3.5..
After entering "pip install GridCal", Python crashed (a GPF indeed), and then came this error:

(pyconda35) C:\Anaconda\envs>pip install GridCal
Collecting GridCal
Downloading GridCal-1.39.tar.gz (297kB)
100% |################################| 307kB 468kB/s
Complete output from command python setup.py egg_info:

----------------------------------------

Command "python setup.py egg_info" failed with error code 3221225477 in C:\Users\Quites\AppData\Local\Temp\pip-build-_d7i4w0f\GridCal\

Hi,

I installed GridCal by following the instructions in the web and typing in the console "pip install GridCal". When trying to run GridCal in the Anaconda Prompt with the following command: python -c "from GridCal.ExecuteGridCal import run; run()", I get the following error:

_ qt.qpa.plugin: Could not load the Qt platform plugin "windows" in "" even though it was found. This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: direct2d, minimal, offscreen, windows.

I read that this can be due to the qt.conf file which is inside of the Anaconda installation folder (I have Anaconda Navigator 1.9.7.). When deleting this file, I can run GridCal successfully, but I cannot open Spyder anymore and the following message appears when trying to do so:

So it seems that Spyder cannot be run without that qt.conf file. I am not sure whether this is related to the same problem, but when typing anything in the GridCal console, such as importing any packages, the "ERROR: execution aborted" message appears.

I would appreciate if someone could give me a hint of what is happening here since I need to work simultaneously in Spyder and GridCal, but I cannot have both open for the reasons mentioned above.

Thank you very much in advance!

Best regards,

Cristina

It would be nice if we could input tolerances for certain values, for example transformers impedance. For example, a power transformer's impedance at the design phase generally varies by +/- 7.5%. For load flow simulations, the higher impedance should be used (i.e. +7.5%). For short circuit simulations, the lower impedance should be used (i.e. -7.5%).

Other typical tolerances in commercial software apply to:

• Reactor impedance;
• Line and cable length.

I'll open another issue to discuss the effect of temperature on cable and line resistance.

Thanks for the great work. I just wonder is it possible to perform customized control algorithm in this framework. Something like

circuit = build_circuit()
while controlstep < maximum_steps:
    observation = circuit.sample_values()
    circuit.do_customized_control(observation)
    controlstep += 1

For example, I would like to control capacitor bank such that the voltage at a certain node of the circuit is maintained within a bound.

I'm wondering what steps must be taken to fully consider the transformer type when running a non-linear load flow.

For example, in my network I have several transformers, all linked to one of two transformer types. With these lines, following the power flow calculation, I can confirm that the transformers were effectively linked to their respective type:

logging.debug("Transformers:")
    for branch in grid.branches:
        if branch.branch_type == BranchType.Transformer:
            logging.debug(f" - {branch}: {branch.type_obj.LV_nominal_voltage}/{branch.type_obj.HV_nominal_voltage}, {branch.type_obj.Nominal_power} MVA")

However, looking at the calculation results, it is clear that the HV and LV nominal voltages aren't really considered. It looks like the transformer's ratio is always considered equal to the ratio between its HV and LV buses voltages, and maybe its tap module (haven't tested this yet).

Is this feature simply not fully implemented yet? Or do I need to take some other step to ensure that the transformer type's attributes are taken into account, once they are linked to each transformer?

In the calculation engine's MultiCircuit.compile(), should we change the circuit.tap_mod[i] to consider the transformer's nominal ratio instead of simply considering the tap_module? For example:

tap_mod = tap_module * (xfo_hv / xfo_lv) / (bus_hv / bus_lv)

For example, a 245-34.5 kV transformer at its +2.5% primary tap would end up with a tap_mod of 1.046.

Thank you.

May I suggest adding a LICENSE file to the root of this project. This would make it clear the terms under which the code may be used.

I would recommend using the same license used by MATPOWER, PYPOWER and PYPOWER-Dynamics etc. so that they may all be used together.

https://github.com/rwl/PYPOWER/blob/master/LICENSE

Hi Santiago,

The new dependency to mpi4py might be a bit problematic in some cases; it requires additional installation steps which are very platform dependant, and it's preventing Read the Docs from running autodoc (see #58 and this failed RTD build).

Could we make this dependency optional? As it stands, I believe it breaks the simple installation procedures shown in the README.

Thanks,

Michel

Edit: More specifically, it breaks the Tower device type from being generated by autodoc, see here. The TransformerType appears to be fine.

Hi Santiago,

I created a new test (see here) to demonstrate a bug I noticed about the tap modules. In this test, transformer X_C3's module is set to 0.975, as shown in the test_xfo_static_tap_3.py file and the generated test_xfo_static_tap_3_grid.xlsx.

In the test results, however, the tap module is reported as being 1.0, as shown in the generated test_xfo_static_tap_3_results.xlsx.

I did several other tests on my side to try and solve this, and noticed that you only update the computed numerical circuit's tap modules for those which are tied to a voltage regulator (in PowerFlowDriver, there other are np.ones()'ed). I tried to correct it in this branch, but it doesn't work yet and I'm not sure that's how you'd want it to be done.

So do you think it's a good idea to copy static tap modules to the PowerFlowResults, so that they can be reported accurately?

If not, I would rather leave those tap_modules empty in the report (in single_power_flow) if they are static, instead of setting them to 1, to avoid any confusion. For a complete report, the user needs to consult both outputs of grid.save_excel() and grid.export_pf() anyways.

Whatever the solution, we need to be able to know the final tap (and/or module) of the transformers with a voltage regulator after a simulation, so the PowerFlowResults must at least include this information.

Thank you,

Michel

Hi Santiago,

Simple reminder to correct a few terms in section 3.2 "The universal branch model" and 3.3 "The transformer definition from the short circuit test values" in the manual. Zseries is the leakage impedance, and Zshunt is the magnetizing impedance, but both sections present the opposite (i.e. Zseries is said to be the magnetizing impedance, Yshunt/Zshunt the leakage impedance).

Section 3.3.1 "Inverse definition of short-circuit values from the pi model" has an error in equation (3.2):

Zsc = sqrt(R² + 1/X²)

...should be:

Zsc = sqrt(R² + X²)

I would also suggest identifying the pi model as a two-port network pi model (edit: I'm actually not so sure about this, need further reading). AESO has published a nice reference. Appendix C discusses the two-port network theory and both the T and pi models.

Lastly, regarding the shunt resistance (rfe) / no load losses equivalent conductance (g), the formula presented in Table 2-1 of AESO's doc uses the no-load test MVA, not the nominal MVA. Table 1-1 shows an example where these values greatly differ (25 vs 42 MVA). I will look for other sources, but would you still have yours?

Thanks.

Hi Santiago,

I'm working on this branch to make the iterative Q control method's steepness factor k adjustable through a PowerFlowOptions, but I'm getting errors about missing icons when regenerating the UI:

michel@DESKTOP-ERT4IKV MINGW64 ~/gits/windfarm/GridCal/src/GridCal/Gui/Main (q_control_adjustable_k)
$ python update_gui_file.py
Cannot find file: icons/check_all.svg
Cannot find file: icons/uncheck_all.svg
Cannot find file: icons/copy2down.svg
Cannot find file: icons/next.svg
Cannot find file: icons/prev.svg
Cannot find file: icons/color_grid.svg

Were they removed purposefully?

Otherwise it seems fine; the options works both in the GUI and the CLI.

See doc here: https://gridcal-wip.readthedocs.io/en/q_control_adjustable_k/api/drivers/pf_driver.html#pf-options

Thanks,

Michel

Hi Santiago,

This commit: 8f6e4dc

...introduced some bugs in the documentation, see here: https://gridcal.readthedocs.io/en/latest/power_flow/newton_raphson.html

Michel

Hi @SanPen,

There are a few warnings when running pytest which all originate from test_load_all_the_grids.py, here's the output: https://pastebin.com/raw/j4cqJjXj

I didn't investigate further, but it looks like the grids haven't been adapted to the latest changes in the TransformerType class.

Michel

Add Power delta as a configurable parameter to the PTDF time series

Hi Santiago,

I want to point you towards this HELM implementation I just found:

https://github.com/HELMpy/HELMpy

I thought it would be nice to link these two projects from each others README file, to increase each other's visibility.

The API of that implementation seems very cumbersome. It reads matlab and excel files and writes results to a txt file or something. So I guess integrating it into GridCal is not an option at the moment. Does the implementation look interesting to you maybe?

Regards,
Bengt