Hi, Mike;
Thanks for your clarification. Regarding your statement "It is only
the leaves of a parameter tree that can have Usage defined for them",
where is this stated in the spec? It makes sense and we should make it
clear in the standard.
Regards,
Fangyi
*From:* Mike Steinberger [mailto:msteinb@xxxxxxxxxx]
*Sent:* Saturday, July 10, 2010 7:59 AM
*To:* RAO,FANGYI (A-USA,ex1)
*Cc:* ibis-macro@xxxxxxxxxxxxx
*Subject:* Re: [ibis-macro] 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
<mailto:fangyi_rao@xxxxxxxxxxx> wrote:
Hi, AMI experts;
I have some questions about input parameter string of AMI Init.
If a parameter is of Usage Info, shall it be included in the input
parameter string to the Init call?
If a parameter is of Usage Out, shall it be included in the input
parameter string to the Init call?
If a parameter is of Usage InOut, shall it be included in the input
parameter string to the Init call?
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
