[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] Fwd: common_component and eval_bm_acton_base
From: |
gserdyuk |
Subject: |
Re: [Gnucap-devel] Fwd: common_component and eval_bm_acton_base |
Date: |
Sun, 7 Nov 2010 22:05:26 +0200 |
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