Hi Muhammad,
Thanks for your feedback, and for your work on matpower-pip.
Regarding backward compatibility, the plan for MATPOWER 8 is to retain complete
backward compatibility in multiple ways.
First, all of the legacy code is still included and can be used by disabling
the new object-oriented core architecture (OOP core).
Second, the new OOP core can be used internally by the legacy runpf(), runcpf()
and runopf() functions. This should be fully compatible, and will enable a few
new options.
To fully exploit the new architecture for customization and building out new
capabilities, one would use the new functions run_pf(), run_cpf() and run_opf()
(note the underscores in the function names).
As far as supporting aliasing on import, I don’t see anything like that for
MATLAB, and even worse, Octave does not yet support import at all, which is one
reason I’m leaning pretty hard toward C. For that reason, I’m also not planning
to put the top-level run_*pf() functions inside the package.
Thanks, again,
Ray
On Nov 1, 2022, at 10:42 PM, Muhammad Yasirroni
<muhammadyasirr...@gmail.com<mailto:muhammadyasirr...@gmail.com>> wrote:
matpower-pip maintainer here.
Current development is using Octave 5.2.0-w64. But, as mentioned earlier, the
latest Ubuntu comes with Octave 6.2. Thus, I might end up using Octave 6.2.
Since I also use Python, using package naming might be nicer from my point of
view.
So I also vote A, but does this version retain backward compatibility? At least
for basic usage snippets.
_
For package naming, I prefer to use C, but if Octave supports aliasing like
what Python does (import matpower as mp), I prefer D.
On Tue, Nov 1, 2022 at 4:39 PM Richard Lincoln
<r.w.linc...@gmail.com<mailto:r.w.linc...@gmail.com>> wrote:
Until recently I was stuck with GNU Octave 4.4 when compiling to WebAssembly
for https://matpower.app<https://matpower.app/>. However, I can now compile
Octave 7.2 with the latest version of Emscripten (3.1.24). I typically use
Ubuntu 20.04 LTS (focal) for development and Docker base images. It comes with
Octave 5.2. However, the latest LTS release is 22.04 (jammy) and it comes with
Octave 6.4:
https://packages.ubuntu.com/search?keywords=octave&searchon=names&suite=all§ion=all
I my experience, Octave is very stable and there are many options available
(snaps, flatpak, PPAs) for installing the latest version. I vote A, requiring
Octave 6.2 or later.
The MATLAB language has a particularly terse syntax. Other than perhaps Perl, I
can't think of a popular language that allows so much to be expressed with so
few characters. For this reason I think mp should be the package name and vote
C. The only naming conflicts that come to mind might be something related to
OpenMP or message passing or multiple precision arithmetic.
Richard
On Mon, 31 Oct 2022 at 23:59, Ray Daniel Zimmerman
<r...@cornell.edu<mailto:r...@cornell.edu>> wrote:
Hi MATPOWER Developers,
I need your feedback on a quick question.
I’m working on finalizing things for a beta release of what amounts to a nearly
complete re-write of MATPOWER for version 8.0. More on that soon.
Since this new version defines tons of new classes, I thought it would be nice
to put them all inside a package, probably named mp or matpower, to avoid
namespace pollution. For those who don’t know, a package is simply a folder
whose name begins with a ‘+’, like ‘+mp’. If that folder is in your path, any
class inside it, such as myclass.m can be accessed as mp.myclass.
The issue is that, for Octave users, putting the new MATPOWER classes inside a
package will require Octave 6.2.0 (released Feb 2021) or later, otherwise we
could support Octave 5.2.0 (released Jan 2020) or later.
So the question for you MATPOWER/Octave users is …
What is your preference?
A. Require Octave 6.2.0 or later and put the new classes in its own package. OR
B. Support Octave 5.2.0 and leave all of the new classes in the main namespace.
And a secondary question, for anyone who has an opinion, is …
Which is the better name for the package, should we choose to go that route?
C. mp - short and convenient to use OR
D. matpower - longer, but better at avoiding name collisions
This is a major update with massive changes and my goal is to introduce a
framework that will provide a solid foundation for MATPOWER development for
years/decades to come.
Any feedback or comments are appreciated. Oh, and I’ll probably post this to
the MATPOWER-L discussion group too, just to get a response from a larger
audience if possible. So sorry for the duplicates for those on both lists.
Thanks,
Ray
--
Best Regards,
Muhammad Yasirroni, S.T.
Research Assistant in Electrical Engineering (Electrical Power System)
Department of Electrical Engineering and Information Technology,
Engineering Faculty, Universitas Gadjah Mada, D.I.Yogyakarta, Indonesia
