[ibis-macro] Re: questions about Init input parameter string
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 13 Jul 2010 11:45:22 -0700
Using other documents as resource, or for ideas is
not bad in itself, but considering the controversy
the introduction of Opal resulted in at the Summit
(for other than for technical reasons), is why this
feels inappropriate to me. We need to straighten
out the issues which caused the controversy before
we make use of it as a resource.
Arpad
====================================================
________________________________
From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx]
Sent: Tuesday, July 13, 2010 1:12 PM
To: Muranyi, Arpad
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Re: questions about Init input parameter
string
Arpad-
Opal was presented as a resource for this group. What is it about Opal
that makes you believe that it's appropriate to purposely and officially
reject this resource?
Mike S.
On 07/13/2010 12:41 PM, Muranyi, Arpad wrote:
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:
