Hi Bjorn,

the elements in the set are based on the order that they are read in. However, if you have some hardcoded references to elements within your model (e.g. in a constraint or variable or parameters you use something like if d = ‘7’), then these elements will come first in your sets when reading them because AIMMS already ‘knows’ about these elements.

Also, you read in the two sets before in your code, are the elements there in the order you expect them to be in the excel file?

Hi!

Thanks! That is completely true, I hardcoded the d=7 in another parameter. That explains, thanks.

This is indeed a rather unexpected ‘feature’ in AIMMS. Fixed quoted elements in the model text can have an effect on the ordering of elements in a set. Like in a statement elemParam := ‘elem1’;  or param(‘elem2’) := 3;

If you really want a certain order in your set then use the order by attribute of the set. If you set this to ‘User’ then the assignments to the set will determine the set order (independent of any element being referenced somewhere else in the model text).

In your example, I think that you can also make the set a subset of Integers. The problem with the ordering will then not be there.

Perhaps good to know: at the moment we are working on this part of the compiler in AIMMS and we hope that this strange effect of fixed elements on the order of a set will be gone in the very near future. The ordering of the root sets (not a subset) in AIMMS will then by default behave like the ‘order by user’.

Happy to hear this :)

One other solution I often used is the StringToElement function instead of the order by attribute

Yes indeed, many of the more experienced AIMMS users work-around this problem by not using the fixed elements but instead use the StringToElement function. This moves the element-name-look-up from compile time to execution time, and that is what we also try to achieve in the current change that we make.