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" <[email protected]>
ad> To: al davis <[email protected]>
ad> CC: Cliff Wiener <[email protected]>
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:[email protected]
_______________________________________________
Gnucap-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnucap-devel
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.