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

[al davis]

On Thursday 19 March 2015, Felix Salfelder wrote:
> 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).

It really is a problem, but it is nontrivial to address.


> 
> > 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)?

Perhaps.

The intent was (and still is) to use commons to do that kind of 
extension.

> 
> (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...

Too bad ....  it's really important to get it to the point where 
everyone can use it.

To me, the highest priority in gnucap now is to finish the 
incomplete work we have.  There is lots of it!