[Ktechlab-devel] My ktechlab modifications

[thomas at tgohome.com]

Yeah I know circuit elements really shouldn't know much about being
overrated. I also think that items perhaps shouldn't know much about being
overrated, but I am not very experienced with C++ and this is my best shot
at it without having to rewrite the engine.

I use getJoules because it's convenient, I don't have to put maths
everywhere. Whilst there aren't specific circuit types, if you do polarize
a capacitor the icon does change appropriately.

I don't know much about transistors and states and settings... Let me know
what needs to be changed with my patch. I did compare the transistor
simulation in ktechlab to another simulator (the software at my school is
Yenka - it's OK but it's got lots of bugs) and it seems plenty accurate,
unless both simulations are wrong...

I've gotta go now, bye.

Tom

> 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.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Ktechlab-devel mailing list
> Ktechlab-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ktechlab-devel
>