Use of Parameters with names "S" and "E"

[Mike Bartholomew]

I have used simple parameter names in my library object PotBearingNonGuided to match the variables shown on a design drawing. Two of the parameters are "S" and "E". They work fine in the library object. However, when I reference the library object from a project file, it appears that these two parameters are somehow being used in a Repeat object. You can see the issue in the following model:

https://openbrim.org/objidy6ewrbqmnrp8eok7kf7gp55wpc.project

The parameters can be renamed, and the problem goes away. Are there restrictions on the names that can be used for parameters or objects?

[Ali Koc]

There are couple of rules, but most of these were introduced after the development of number of objects.

For example, for a library object, only those parameters whose Role is Input can be set from a project. Unfortunately, we are not enforcing this because there are number of objects who do not make use of Role="Input".

Also, parameters should be defined directly inside the root node of the library objects (parameters can be categorized using Category attribute on the input parameters). There are many objects, where their input parameters are deep in the object hierarchy of its definition.

That is why when a project wants to overwrite a parameter of a library object, we currently overwrite all parameters of that name. If you have a parameter named S, E, I --- these will affect the Repeat objects.

We can certainly make exceptions on this, but I would strongly recommend that you keep object input parameters unique. Otherwise, inside the library object, when you use the parameter S, there will be a confusion -- is it the S of the Repeat object or S input parameter of the library object. ParamML engine normally picks the closest one to give the most expected behavior.

As the system is maturing, we will start enforcing these rules more rigidly which should resolve most the ambiguity.