[Ktechlab-devel] More on Document / Simulator interface

[Alan Grimes]

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.


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!!! =|

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.


-- 
DO NOT USE OBAMACARE.
DO NOT BUY OBAMACARE.
Powers are not rights.