[Top][All Lists]

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

[Gnucap-devel] Fwd: common_component and eval_bm_acton_base

From: al davis
Subject: [Gnucap-devel] Fwd: common_component and eval_bm_acton_base
Date: Sat, 6 Nov 2010 02:52:59 -0400
User-agent: KMail/1.13.5 (Linux/2.6.32-trunk-amd64; KDE/4.4.5; x86_64; ; )

(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

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

    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?

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


reply via email to

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