[Ktechlab-devel] More on Document / Simulator interface

[P Zoltan]

On Sun, 03 Jan 2010 06:08:43 +0100, Alan Grimes <agrimes at speakeasy.net>  
wrote:

> P Zoltan wrote:
>>   Here is some code, describing the interfaces between the simulator and
>> document:
>
>>   http://sourceforge.net/userapps/trac/zoltan_padrah/wiki/KtechlabDocumentProposed
>
>>   We should discuss about it. There are some fixme-s and todo-s, too.
>
> I don't understand what that source code is for. It looks somewhat dated
> in its design pattern, a number of things I've straightened up already
> in SVN.
>
> Furthermore, I'm becoming increasingly distressed by the move away from
> the Document family and tree of classes.
>
> One of the things that makes ktechlab work so great is that everything
> is unified into a single class heirarchy. All documents, both text and
> graphical are instances of class Document. All graphical documents are
> instances of class ItemDocument, all documents that feature connectors
> between components are of class ICNdocument, etc...
>
> The apparent rush to implement the functionality of the child classes
> without respect for the over-arching architecture of the application is
> bound to be a disaster!!! =(((
>
> It's great to extend this with project management and other good
> features, but the unifying class hierarchy is indispensible! =(
>
> I don't mind if we use someone else's Document class, but you'll need a
> VERY good argument that the alternative is better.


  Julian explained rather well what's the point, so I'll just make another  
approach:

  These classes should describe how the simulator and the simulated  
components should be seen from _outside_. They have nothing to with the  
_inside_ workings of the objects. The ISimulator should be seen from the  
document; while ISimulatedDocument, IElectronicModel, IWire, IPin are the  
elements seen by the simulator from the document and simulated components.  
None of these have anything to do with the implementation.
  This way the big pile of code of ktechlab can be splitted in 2 smaller  
piles of code, connected by these abstract interfaced. Smaller piles of  
code are generally easier to understand, maintain, debug.

>
>
> Another thing that needs to be understood is exactly what the simulator
> is, and what it does. In the not too distant past, I have done some
> massive overhauls to that class so there is no good excuse not to
> understand it!!! =|

  Okay, I'll look at it. Here is an example of what my problem is with the  
current code:

- the simulator manipulates lists of Components

- inside the Component's definition:

[...]
/**
  * Angle of orientation
  */
int angleDegrees() const { return m_angleDegrees; }

[...]
/**
     * After calculating nodal voltages, each component will be
     * called to tell its nodes what the current flowing *into*
     * the component is.
     */
void setNodalCurrents();

First, there is a method that has to do with the display of the Component,  
then there is a method that is specifi to simulation. Why should we mix  
the roles of simulated component and drawn item in the same class? This is  
messy. And also makes the code a lot harder to debug.

>
> So here's how simulator works. The first thing to notice is that there's
> only one real method, everything else is just setup, teardown, and
> plumbing.
>
> [I'm a bit tired, so I'll rush through this and let you figure it out.]
>
> What the simulator's real responsibility is, is maintaining time. Our
> simulator is relatively primitive, it can't run things in parallel, and
> it can't be distributed across a network. It is given what, ideally at
> least, are generic objects that can be simulated. It doesn't care if
> it's a gear, a circuit, a flowcode instruction, or anything you can
> think of. The one critical thing is that the object exists within a
> universe with time. That is why the simulator's most-used function is
> the one which returns the current simulation time.
>
> The simulator is optimized in that it tries not to waste time simulating
> things that are static, or haven't changed. When things are changing, it
> makes sure that everything in that domain of simulation is given the CPU
> time it needs to advance itself one state. The code is still cumbersome
> because it's going down a list of different things to simulate rather
> than a generic bag of things to simulate. (see TODO item on line 77 of
> simulator.cpp)
>
> Currently some classes of things need to be handled a bit differently
> than other classes. Most notably, logic elements are processed basically
> in the abstract so that they can be processed extremely fast!! Extremely
> as in the current simulator can push through *MILLIONS* of state changes
> on badly aging hardware in a matter of a few seconds, I have a nice demo
> circuit to prove it, while other electronic components are processed at
> a corser time-granularity but a much higher electrical accuracy. This is
> why the simulator maintains two separate time resolutions.
>
> But the short story of it is that the simulator's only real job is to
> create a concept of time for all the other classes which exist within
> the simuation.
>
>
> Also: I think I finally have a handle on why the super-critical
> nonlinear and Diode classes aren't working. While I wait for my contract
> to be renewed I might have a little (hopefully not too much!) time to
> attempt to implement my newfound solutions.
>
>