[Ktechlab-devel] My ktechlab modifications

[Alan Grimes]

thomas at tgohome.com wrote:
> Hi,
> 
> I'm back again.
> 
> After a bit of getting used to patch/diff - it's the first time I've
> really got used to it - I made a patch file. See here:
>   http://files.getdropbox.com/u/1134084/ktechlab-over-rate-additions-plus-more-by-Tom-Oldbury.patch
> 
> Hopefully I did it right - please can someone try it out on a copy of
> current SVN.

I found the problem with my build, I had a "--prefix=" statement in my
kdevelop configuration. =\

Those SVN diffs had several problems, for one thing it includes
differences involving the makefiles, which are specific to your machine
and the version of automake you used. For some reason you have a number
of Makefile.in's, one from automake 1.9.6 and the other from 1.10.1

Second, I've been on a jihad against class Component. Previously, all
the code in DSubCon, DIPComponent, and SimpleComponent were all mixed
together in the same class, with hundreds of children. The new layout
makes it a bit saner. A great deal of refactoring is still required to
confine as much information as possible as tightly as possible.

If this were Java, which deals with interfaces quite nicely, this
wouldn't be too bad, but in C++ ....

You are currently the most enthuseastic programmer on ktechlab, and I
must say you are far more capable than even I am! =P I've been wrestling
with this code for years and had not gotten close to adding new features
 of the scope you have. (on the other hand, your rapid progress is
probably in part due to my constantly tweaking the code).

I'm not sure Item should know anything about "ratings", it's just
something that you can put on a canvas... But then this is probably an
interface issue.

I REALLY don't like class member variables because they are a great
place for glitches if not actual bugs to hang out, bloat the memory
footprint, bloat the symbol tables in the binaries, etc etc...
m_hoverTipText should definitely be replaced by a lazy evaluator which
will generate a string ONLY when the tip is actually in the neighborhood.

I didn't compute V_CE in BJT because it was an extra variable and it was
trivially available from V_BE and V_BC. I felt it was important to
remove that variable because it made: (V_CE != V_BE - V_CE) possible so
therefore I removed that variable and thereby removed the potential bug.

OH CRAP, I MIGHT HAVE BEEN COMPLETELY WRONG!!! I didn't realize, at that
time, that I had to diode-clamp those other two variables, hence needing
to pre-compute V_CE... ARGH!!!! =0 Maybe I am also completely wrong
about how and where I need to diode clamp... (mosfet is currently
putting INF's into the matrix! =(((

The pathetic attempt at computing the transistor current are these lines
here:
######
	m_ns.I[0] = (-I_eq_B - I_eq_C) * m_pol;
	m_ns.I[1] = ( I_eq_C - I_eq_E) * m_pol;
	m_ns.I[2] = ( I_eq_B + I_eq_E) * m_pol;
######

Those being the device's three Cnodes, or was it cbranches... since
we're setting current, I think they're cnodes...

You are completely wrong by confusing STATE with SETTINGS. Never use
SETINGS for STATE!!!!!!

Furthermore, state is only visible when queried, therefore if it is not
inherently part of the state, then it should be computed WHEN IT's
QUERIED. Once again, this makes it impossible for the state to become
inconsistient. In database terms, I'm trying to normalize the classes to
make inconsistiencies impossible.

Capacitance is an abstract ideal circuit element. (look up "elemental
analysis" or something like that).

It would be great to have specific capacitor types such as electrolytic
capacitor, with the correct symbol... (there are five or six different
symbols for different types of capacitors...)

I don't know why you have getJoules, it seems trivial to compute from
Columbs in higher level code.

The functions for obtaining voltage and stuff seem to be fine additions...

In general, the stuff in Simulation is there for exactly one task, to
set up the linear algebra engine. The components shouldn't do much
except try to figure out what's happening by looking at the state of its
pins. (pin currents are problematic and moderately broken..) Components
are free to be as realistic as desired. There you get things such as the
capacitor's ESR, etc, all modeled in terms of abstract circuit elements.

Goddamnit, I just spent the entire night using Kompare to view your
changes when I should have been catching up on my badly needed sleep. =(


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