Re: [Qucs-devel] Status update / request for feedback / questions

[Richard C. <r.c...@ed...>]

On 27/08/2013 11:43, Soeren D. Schulze wrote:
> Am 27.08.2013 11:34, schrieb Richard Crozier:
>> On 26/08/2013 19:29, Soeren D. Schulze wrote:
>>> Hi again,
>>>
>>> * e_trsolver was temporarily disabled.  What exactly does it do?
>>
>> e_trsolver is the nascent external interface (external trsolver) I am
>> creating to the qucs transient solvers. It provides a means to interact
>> with the solver between each time step, or even completely control the
>> stepping from another program when qucs is compiled as a library (which
>> has to be done manually at the moment).
>>
>> The external interface currently works in two ways, synchonous or
>> asynchronous. In the asynchonous version it is intended that two time
>> steps will be provided and the qucs solvers solve between these as they
>> normally do, choosing their own minor time steps and simply reporting
>> the values of the solution at the end. In the synchronous version
>> however it is intended that all step control is performed by the
>> external program, using the previous solution values reported by qucs. I
>> have a prototype of this working using the Matlab/Octave solvers, which
>> determine the local gradient by fitting a 3-point spline to the previous
>> solution values. This is crude but seems to work ok for testing.
>
> Ah, I see.
>
> My main problem was the great code redundancy between e_trsolver.cpp and
> trsolver.cpp.  Is it possible to refactor this?
>
> The e_trsolver class is a subclass of trsolver, but it removes
> functionality rather than adding to it.  So shouldn't the hierarchy be
> the other way around then?
>
>
> Sören
>

Well, the intention of subclassing trsolver was that e_trsolver then had 
everything trsolver had. I wanted to reuse as much as possible of the 
trsolver code originally, just adding in a few more things, and 
overriding some of trsolvers methods. I also didn't want to modify 
trsolver heavily while I worked on this and figured out the best way to 
do it, and I also just wanted to see if it could work really. The 
architecture of this is still in a state of flux.

I'm very busy right now, but soon I will have a bit more time to work on 
Qucs again, and will get this looking a bit nicer. In the meantime I'm 
open to suggestions/improvements. I'm not sure about trsolver inheriting 
from e_trsolver though, I'd rather modify trsolver where possible, as it 
seems more natural to me that trsolver is the parent.

Richard



-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.