The Altair Community is migrating to a new platform to provide a better experience for you. In preparation for the migration, the Altair Community is on read-only mode from October 28 - November 6, 2024. Technical support via cases will continue to work as is. For any urgent requests from Students/Faculty members, please submit the form linked here
Macro bug/feature request
Hi!
I don't know where to put this (in the forum or on the bug list) so I try it here.
I want to do some thing in RM5 which was without any problem possiblw in RM4. I have some setup (It is'n complete yet so I cannot post it), where I load same data, do something with the data (mainly feature selection) and store the results. I want to apply this setup to different data sets. In RM4 this was no problem: Define some macro "dataSet" and use it in the parameter for loading and for storing the results. In RM5 this is not possible using the repository. The repository load operator doesn't have an input port, thus the macro cannot be transfered to the operator --> it doesn't work.
I would say this is a bug. What do you think? Do you know any workaround?
Greetings,
Michael
I don't know where to put this (in the forum or on the bug list) so I try it here.
I want to do some thing in RM5 which was without any problem possiblw in RM4. I have some setup (It is'n complete yet so I cannot post it), where I load same data, do something with the data (mainly feature selection) and store the results. I want to apply this setup to different data sets. In RM4 this was no problem: Define some macro "dataSet" and use it in the parameter for loading and for storing the results. In RM5 this is not possible using the repository. The repository load operator doesn't have an input port, thus the macro cannot be transfered to the operator --> it doesn't work.
I would say this is a bug. What do you think? Do you know any workaround?
Greetings,
Michael
0
Answers
first of all: There's no port connection needed for transferring the macro value. It's more like a variable set during a program flow: The macro will hold the value for all subsequent operators, regardless if there's a data flow in between. Hence the only thing that matters is the execution order.
We stumbled over this problem ourself a while ago and included a feature for intuitively show and reorder the execution order. In the beta version this is possible using the good old tree. The tree always reflects the current execution order and if you reorder the operator there, so that the macro definition is executed previously, everything should work again.
Greetings,
Sebastian
of course you are right ;D
Everything works fine when i order the operators in the tree view.
Greetings,
Michi
P.S.: I hope the annoing warnings will also vanish with your new feature
at least a few days on our schedule have been assigned to these annoying warnings
Greetings,
Sebastian