[ibis-macro] Re: questions about Init input parameter string
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 13 Jul 2010 10:41:00 -0700
This may be a sensitive subject, but I would like to
request that we should refrain from making references
to Opal in IBIS specification related discussions
until the logistics and relationship between IBIS
and Opal have been worked out.
At this point Opal has nothing to do with the IBIS
specification in an official sense. The discussion
that was started at the last IBIS Summit was left
in an unfinished state and I feel that until some
of the logistics are cleared up or decided, we should
refrain from using Opal as a guideline or reference
for specification related discussions.
Sincerely,
Arpad
=========================================================
________________________________
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Saturday, July 10, 2010 9:59 AM
To: fangyi_rao@xxxxxxxxxxx
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: questions about Init input parameter string
Fangyi-
You're quite right that the current spec is not clear on points such as
this. Your questions are well taken.
I suggest that Opal(tm) Requirement 2.5_E states a basic principle that
can help here.
R2.5_E.01 Requirement: Errors and/or unrecognized parameters in the
AMI_parameters_in input string shall not prevent the model from
completing and returning
from the AMI_Init() function.
Extending this principle a little, the answers to your questions would
be
1. If the Usage is Info, then by definition the model is not going to
use the value of the parameter. Therefore, it doesn't matter whether the
parameter is in the input parameter string or not. The model should be
written that way (or else the Usage redefined), and if the parameter is
included in the input parameter string, it should be safely ignored.
2. Similar answer to 1. above. One should also consider the following
recommendations from Opal:
R2.5_E.01 Requirement: Errors and/or unrecognized parameters in the
AMI_parameters_in input string shall not prevent the model from
completing and returning
from the AMI_Init() function.
r2.6_D.01 Recommendation: The AMI_parameters_out string for the
AMI_Init() function
should echo all of the model's parameter values, regardless whether
those parameter
values are the parameter's default value or were configured through the
AMI_parameters_in input parameter string. For each parameter, the value
reported should
be the value used to generate the model's output impulse response (if
any).
R2.5_E.01 Requirement: Errors and/or unrecognized parameters in the
AMI_parameters_in input string shall not prevent the model from
completing and returning
from the AMI_Init() function.
3. If a parameter is of Usage InOut, then by definition, the model is
stating that it will use the parameter value. Therefore, YES, the
parameter needs to be in the input parameter string.
4. It is only the leaves of a parameter tree that can have Usage defined
for them in the first place, so it's not clear what you mean by
sub-parameter.
Hope this helps.
Mike S.
On 07/09/2010 11:26 PM, fangyi_rao@xxxxxxxxxxx wrote:
Hi, AMI experts;
I have some questions about input parameter string of AMI Init.
<!--[if !supportLists]-->1. <!--[endif]-->If a parameter
is of Usage Info, shall it be included in the input parameter string to
the Init call?
<!--[if !supportLists]-->2. <!--[endif]-->If a parameter
is of Usage Out, shall it be included in the input parameter string to
the Init call?
<!--[if !supportLists]-->3. <!--[endif]-->If a parameter
is of Usage InOut, shall it be included in the input parameter string to
the Init call?
<!--[if !supportLists]-->4. <!--[endif]-->If a parameter
is of Usage Info or Out, can its sub-parameter be of Usage In?
The current spec is not clear about what parameters go into the
input string. We should clarify this in the clean-up BIRD.
Thanks in advance.
Fangyi
Other related posts:
