Re: [Gnucap-devel] Fwd: common_component and eval_bm_acton_base

[gserdyuk]

Hello Al,

After a few attempts - seems the best way to fix issue is to add constructor
for teh following hierarchy:

EVAL_BM_SEMI_RESISTOR      EVAL_BM_SEMI_CAPACITOR,
     |________________________|
     |
EVAL_BM_SEMI_BASE          EVAL_BM_TABLE
     | _______________________|
     |
EVAL_BM_ACTION_BASE

:

EVAL_BM_SEMI_RESISTOR (EVAL_BM_ACTION_BASE *)
EVAL_BM_SEMI_CAPACITOR(EVAL_BM_ACTION_BASE *)
EVAL_BM_SEMI_BASE   (EVAL_BM_ACTION_BASE *)
EVAL_BM_TABLE       (EVAL_BM_ACTION_BASE *)
EVAL_BM_ACTION_BASE (EVAL_BM_ACTION_BASE *)

THis allows to pass EVAL_BM_MODEL as a pointer to the object in
new_common into constructor and then initialize
common part of the class.

Pls see attachement for the proposed code.

Regards
Gena



Saturday, November 6, 2010, 8:52:59 AM, you wrote:

ad> (forwarded to the list with permission)

ad> ----------  Forwarded Message  ----------

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

ad> Hello Al,

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

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

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

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

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

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

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

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



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


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

ad> may be some other approaches possible.

ad> Could you comment this, please?


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




-- 
Best regards,
 Gserdyuk                            mailto:address@hidden