gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] [Help-gnucap] Help adapting POLY H source


From: Felix Salfelder
Subject: Re: [Gnucap-devel] [Help-gnucap] Help adapting POLY H source
Date: Thu, 19 Mar 2015 20:14:28 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Al.

On Thu, Mar 19, 2015 at 01:36:42PM -0400, al davis wrote:
> [..] determining the device type is in 
> find_type_in_string(), which is trivial in non-spice formats, 
> but the spice format needs to deal with this.

must have missed that. so several new devices require an extra patch to
lang_spice.cc... (which is not a problem).

> The new device, in this case, needs to handle the extra partial 
> derivatives.  If you miss the partial derivatives, it may seem 
> to work in simple tests, but will have convergence and AC  
> problems.

l_poly.h (in gnucap-bm) contains a class for multivariariate polynomial
evaluation. perhaps it should be m_mvpoly.h...

> So the DEV_FPOLY_G and DEV_CPOLY_G use the arrays _values and 
> _inputs to handle the storage of the partials and inputs.  Then 
> tr_load() (and all *_load) call *_load_extended to load the 
> extra partials to the matrix.

modelgen components making use of the cpoly_g control the _values
directly, also DEV_CPOLY_G::do_tr is close to a no-op or dummy. it seems
that cpoly_g would makes sense for any other admittance with multiple
inputs and one output. would it make sense to put the current
DEV_CPOLY_G into a base class (for use in modelgen) and re-use it for
admittances controlled by something else (e.g. a polynomial)?

(if not: it should be easy to extend cpoly_g to behave like G+poly(k) in
standalone (not-modelgen) mode. but then it will be just that.)

> Proper implementation of a subset is useful, but the problem I 
> see is that it fails to compile, because it can't find admsxml, 
> and provides no help about how to get it.

similarly, gnucap does not provide help on how to get a c++ compiler.

but seriously (and a bit off-topic): the current unstable gnucap-adms
requires a (minimally) patched admsXml. i hope this will be included
upstream [1] some day (if i had more time to do this, it might already
have happened). a working patched version is here [2]. similarly i don't
have time for making this work with gnucap-upstream right now...

have fun
felix

[1] git://github.com/QUCS/adms
[2] git://reichel.em.cs.uni-frankfurt.de/git/adms, ident3 branch



reply via email to

[Prev in Thread] Current Thread [Next in Thread]