P Zoltan | 2 Aug 23:52 2009
Picon

Converting to Eigen -- update equation matrix size?


   Hi,

  I've tried to convert the existing code to use Eigen, but at this moment  
it's totally broken, due to the fact that if a new element/component is  
added to the circuit, the corresponding matrix's size doesn't change, so  
some nodes won't get voltage values. Does anybody know how adding new  
elements it's supposed to work?

  Later edit: it seems to me that after each added component, the  
CircuitDocument is divided in Circuits and ElementSets and each Circuit  
gets an init() call, where the matrix is recreated. Some more debugging is  
needed... And also a decent logging method, because debugging complex data  
structures/classes tends to suck.

  When I get something more or less functional, I'll send a patch.

   Zoltan

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Alan Grimes | 3 Aug 03:00 2009
Picon

Re: Converting to Eigen -- update equation matrix size?

P Zoltan wrote:
>   I've tried to convert the existing code to use Eigen, but at this moment  
> it's totally broken, due to the fact that if a new element/component is  
> added to the circuit, the corresponding matrix's size doesn't change, so  
> some nodes won't get voltage values. Does anybody know how adding new  
> elements it's supposed to work?

Circuit or Circuit document totally destroys the existing elementSet and
builds a new one, that's how it works.

>   Later edit: it seems to me that after each added component, the  
> CircuitDocument is divided in Circuits and ElementSets and each Circuit  
> gets an init() call, where the matrix is recreated. Some more debugging is  
> needed... And also a decent logging method, because debugging complex data  
> structures/classes tends to suck.

Yep.

--

-- 
New president: Here we go again...
Chemistry.com: A total rip-off.
Powers are not rights.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
P Zoltan | 6 Aug 00:28 2009
Picon

Re: Converting to Eigen -- update equation matrix size?


  Finally... it's working. The big problem was not the porting to Eigen but  
figuring out how the A,b changed flags should be set/unset. Momentanly  
they are completely ignored. The strategy of setting/unsetting of these  
flags would be useful to document. Ideas are welcome.

  There are some gliches with currents, as Kirchoff's current law is not  
respected in quite numerous cases. I guess the nodes/branches are not  
properly updated.

  It's surprizing how many classes are in the program -- for example CNode,  
just stores the voltage and current of a node and the value of the  
currents. All these classes should be properly documented. My suggestions  
are doxygen in the source, and maybe some wiki documents. The question is  
where to upload the latter ones...

  When some decent looking code is ready (the current state is a mess),  
I'll send a patch to the list for review.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Alan Grimes | 6 Aug 02:00 2009
Picon

Re: Converting to Eigen -- update equation matrix size?

P Zoltan wrote:
>   There are some gliches with currents, as Kirchoff's current law is not  
> respected in quite numerous cases. I guess the nodes/branches are not  
> properly updated.

No, that's a UI issue. =\

Or rather the engine is working but doesn't provide directly useful
information for updating the UI so the UI *TRIES* to figure out where
the current is coming from and where it is going.

It might be possible to expand the matrix a little bit and get more
information about currents.

>   When some decent looking code is ready (the current state is a mess),  
> I'll send a patch to the list for review.

Sounds good. =)

It really doesn't make sense for us to maintain our own math library
internally to ktechlab.

--

-- 
New president: Here we go again...
Chemistry.com: A total rip-off.
Powers are not rights.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
(Continue reading)

P Zoltan | 7 Aug 19:40 2009
Picon

Re: Converting to Eigen -- update equation matrix size?

On Thu, 06 Aug 2009 02:00:15 +0200, Alan Grimes <agrimes@...>  
wrote:

> P Zoltan wrote:
>>   There are some gliches with currents, as Kirchoff's current law is not
>> respected in quite numerous cases. I guess the nodes/branches are not
>> properly updated.
>
> No, that's a UI issue. =\
>
> Or rather the engine is working but doesn't provide directly useful
> information for updating the UI so the UI *TRIES* to figure out where
> the current is coming from and where it is going.
>

  Hmm... the UI trying to do something on its own sounds like a bug/design  
problem for me, not a feature. Obviously more investigation is needed. My  
sugess is that some currents are not properly updated in some cases.  
Dumping the object structures would be really useful in the investigation.

> It might be possible to expand the matrix a little bit and get more
> information about currents.
>

  We should clearly define the algorithm for computation and UI update...

  Tests that fail, due to bogous currents:

- creating a voltage divider, with:
   ( 2 resistors in parallel ) in series with a another resistor
(Continue reading)

P Zoltan | 9 Aug 14:00 2009
Picon

Converting to Eigen - patch for revision, ver.1


   Hi,

  here is a patch that makes ktechlab to use Eigen for calculations, so the  
internal matrix implementation can be removed.

  Steps to use:
  1. patch the source. If it fails, tell me, because I haven't tested the  
patch :D
  2. download and extract eigen somewhere. I've used version 2.0.3. (Note:  
see a comment in the patch about an eigen bug -- we should use a newer  
version when we import eigen in ktechlab )
  3. in kdevelop, in the automake manager, add the path of the extraced  
eigen sources to the includes. This should be done for all subfolders...
  4. compile
  5. run

  Known problems:
  - the caching and changed/unchanged flags probabily don't work as they  
should
  - when inserting a reactive element in the circuit, the cpu usage will  
increase to 100% after a time. Probable causes are that eigen uses great  
precision calculation, so the circuit will never enter in steady state. Or  
just some caching problem...

  Todos:
  - test it :D
  - we'll have to define _clearly_ the algorithms and data structures used  
in the cirucit solving process. Currently I don't know how the A, b  
changed flags should work and what is the purpose of CNode and CBranch  
(Continue reading)

Alan Grimes | 9 Aug 19:26 2009
Picon

Re: Converting to Eigen - patch for revision, ver.1


P Zoltan wrote:
>  here is a patch that makes ktechlab to use Eigen for calculations, so
> the internal matrix implementation can be removed.

=)

>  Known problems:
>  - the caching and changed/unchanged flags probabily don't work as they
> should

I think that's where your memory leak is. It tries to cache everything
and runs out of memory.

>  - when inserting a reactive element in the circuit, the cpu usage will
> increase to 100% after a time. Probable causes are that eigen uses great
> precision calculation, so the circuit will never enter in steady state.
> Or just some caching problem...

>  Todos:
>  - test it :D
>  - we'll have to define _clearly_ the algorithms and data structures
> used in the cirucit solving process. Currently I don't know how the A, b
> changed flags should work and what is the purpose of CNode and CBranch
> classes, how/when the iterations shoud be done, and so on...

When the circuit is in a steady state, it doesn't make any sense to
recompute LU. (simply solve LbU = x ) or something like that.

Note: the function call you make "mp_lu->rank() == 0" is equivalent to a
(Continue reading)

Alan Grimes | 10 Aug 21:44 2009
Picon

Part of the day! =P

"SENSEFET" =PPP

(found it in a datasheet on the MC33035...)

So why am I reading the datasheet for the MC33035??? Well, all the
Electric Vehicle motor controllers on the market suck right now since
the Zilla is out of production, so I started to work on develing my own. =P

I hope Ktechlab will be up to the task of helping me with this project! =P

--

-- 
New president: Here we go again...
Chemistry.com: A total rip-off.
Powers are not rights.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Zoltan Padrah | 12 Aug 17:57 2009
Picon

Re: Converting to Eigen - patch for revision, ver.1



2009/8/9 Alan Grimes <agrimes-zY4eFNvK5D9If6P1QZMOBw@public.gmane.org>

P Zoltan wrote:
>  here is a patch that makes ktechlab to use Eigen for calculations, so
> the internal matrix implementation can be removed.

=)

>  Known problems:
>  - the caching and changed/unchanged flags probabily don't work as they
> should

I think that's where your memory leak is. It tries to cache everything
and runs out of memory.
Memory leak? I have of that, too?
 
>  - when inserting a reactive element in the circuit, the cpu usage will
> increase to 100% after a time. Probable causes are that eigen uses great
> precision calculation, so the circuit will never enter in steady state.
> Or just some caching problem...

>  Todos:
>  - test it :D
>  - we'll have to define _clearly_ the algorithms and data structures
> used in the cirucit solving process. Currently I don't know how the A, b
> changed flags should work and what is the purpose of CNode and CBranch
> classes, how/when the iterations shoud be done, and so on...

When the circuit is in a steady state, it doesn't make any sense to
recompute LU. (simply solve LbU = x ) or something like that.

Note: the function call you make "mp_lu->rank() == 0" is equivalent to a
correct version of my "validate()" function. Ie, when rank = 0, the
matrix is singular/invalid/unsolvable. -- IIRC. Since I'm a dunce, I
hacked together the validate() function in an attempt to detect bugs in
the components as early as possible. asking "rank() == 0?" does the same
thing.
Yes, I know. Still, that rank() call should be removed, as LU::solve() method returns false if it can't solve the equation system. That case is not addressed -- the question is what to do in that case: write a "?" for voltage level, or use the last valid state for the circuit?
 


>  Here is the sketch of the algorithm (should be extended...):

> if a component is added, removed, connected, ... in the circuitdocument:
>  split the document in circuits, by connectivity
>  create elementset from the circuit
>     create the matrix corresponding to the elements

> a step in the simulator:
>   if the circuit contains nonlinear elements
>     solve the cirucit by iterations
>      in each iteration
>        call the handler of nonlinear elements
>        recreate the LU of the eqation matrix
>        update nodes (why?)

Could you point me to a class, method and line number for that so that I
can explain it?
In not that interested in a particuar class, but in the interaction of all the  classes; or just the algorithm, without any particular class/method. 
 


>        run logic (here -- why?)
-- cuz you could have triggered a state change.

>        check for convergence
>   else
>     solve as a linear system
>   run logic

>  (where are the components updated?)

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ktechlab-devel mailing list
Ktechlab-devel@...
https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
Alan Grimes | 12 Aug 18:23 2009
Picon

Re: Converting to Eigen - patch for revision, ver.1

> Yes, I know. Still, that rank() call should be removed, as LU::solve()
> method returns false if it can't solve the equation system. That case is
> not addressed -- the question is what to do in that case: write a "?"
> for voltage level, or use the last valid state for the circuit?

Yeah, you should simply skip the LU step and solve the vector with the
old LU, if the vector has changed.

You should also emit debugging information because it means that there
is probably something wrong with one of the components. Nb, there are
some pathalogical circuits that inherently produce invalid matrices. I
can send you an example.

--

-- 
New president: Here we go again...
Chemistry.com: A total rip-off.
Powers are not rights.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

Gmane