[Gnucap-devel] Fwd: common_component and eval_bm_acton_base

[al davis]

(forwarded to the list with permission)

----------  Forwarded Message  ----------

Subject: common_component and eval_bm_acton_base
Date: Thursday 04 November 2010, 06:48:48
From: "GSerdyuk/AnalogRails" <address@hidden>
To: al davis <address@hidden>
CC: Cliff Wiener <address@hidden>

Hello Al,

I have one question regarding elaboration of , for example
eval_semi_resistor - semiconductor resistor.

As I understand, when resistor is parsed - COMPONENT is created and
COMMON_COMPONENT (namely - EVAL_BM_MODEL object) is set in
COMPONENT::_common.

later on, during elaboration (namely - during expansion), COMPONENT
calls expansion for COMMON_COMPONENT,  for EVAL_BM_MODEL class
it means process like that:

   EVAL_BM_MODEL:expand()
    a) finds and calls proper constructor (hierarchy of
    COMMON_COMPONENT), depending on the model type
    of the associated .model, in this case - EVAL_SEMI_RESISTOR
    b) attaches new common_component to existing (_func)
    c) prepare for "deflation" - i.e.  substitution of
    EVAL_BM_MODEL common_componnet with "daughter" EVAL_SEMI_RESISTOR.

  d) then during deflation - new COMMON_COMPONENT substitutes old one.

Issue I have found is that before EVAL_BM_MODEL:expand() all
COMMON_COMPONENTs were passed already through precalc_first() procedure
and for many of them some parameters are set.
Like _temp_c and alike. See COMMON_COMPONENT::precalc_first().

When at stage a) new COMMON_COMPONENT is created - it does not contain
all that information, it is lost.

I suppose tis behavior is notfully correct - as un-initialized values
are passed to calculations and it may cause issue later -
so it likely has to be fixed.



There are a few ways to fix that:
1) move initialization code from precalc_first to precalc_last - so
initialization will not be lost. simplest


2) explicitly copy parameters between objects, creating methods like -
copy_params or alike
3) pass original EVAL_BM_MODEL to new_common() in "this" to call  new
constructors, which will create properly initialized objects

may be some other approaches possible.

Could you comment this, please?


NB:
I made tests - there are some numeric differences - quite significant
(more than roundoff error)  - like new 0.99991 against old 0.99999.
so, seems this change have some influences onto existing test cases.

-- 
Best regards,
 GSerdyuk/AnalogRails                          mailto:address@hidden



-----------------------------------------