A Working Implementation of ac CirSys

agent on 2005-04-24T10:50:54

=from 2005.4.21.8:05.AM =to ...4.21.9:20.AM

It was really crazy yesterday. I did a lot of coding with madness and got a lot of things done. Now we have a working ac implementation for CirSys 0.08, with hundreds of unit tests, 60 integration tests ported directly from the dc system, and one "pure" ac integration test borrowed from the textbook "Engineering Circuit Analysis".

As the complexity of CirSys was increasing steadily, I finally decided to give up supports for MATLAB. There are too many limitations with MATLAB's Maple kernel, which leads to unacceptable cost of maintenance and limited flexibility. Once we get rid of this, we can exploit the advantage of Maple 9 features to the full without worrying compatibility issues.

For example, CirSys will by *default* generate the following Maple command,

interface(imaginaryunit=j);

in order to follow the standard notations used by engineers where we use "i" and "I" to denote time-varying currents and constant currents respectively, and prefer "j" to indicate the imaginary unit, say, sqrt(-1).

It will also be very handy if we implement some back-ends for the grepsol tool, which can perform transformations among rectangular form, polar form, and even exponential form of complex numbers. For instance, consider the following output of grepsol:

i = 4+3*j --- i_2 = 5 i_3 = 4*j

If we have a back-end named rec2pol that converts complex numbers from their rectangular form to polar form, it will generate the following Maple code accordingly:

i = map(normal.evalc, polar(4+3*j)); # --- i_2 = map(normal.evalc, polar(5)); i_3 = map(normal.evalc, polar(4*j));

Oh, it's really a trivial thing to implement this back-end for us perl programmers!

I've noticed if we invoke cmaple.exe or cmaple9.exe too frequently, Maple server (mserver) will fail to start, which often cause my CirSys tester to crash. In that case, I have not choice but to terminate the mserver process by hand Windows Task Manager. Boring. It is desirable to wrap the OpenMaple interface as a full-fledged COM Server which will stick to only one instance in the OS environment regardless of the number of client processes. I'm guessing the ATL technology can be very helpful.