Fwd: common_component and eval_bm_acton_base

al davis <[email protected]>
Newsgroups gmane.comp.gnu.gnucap.devel
Message-ID <[email protected]>
(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" <[email protected]>
To: al davis <[email protected]>
CC: Cliff Wiener <[email protected]>

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:[email protected]



-----------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.