You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Those who are currently using qrsim have expressed the need to configure simulations programatically. Currently, the simulation setup is defined in a set of static m-files. In order to change the noises, etc. one needs to create a new m-file. For simulations that test many combinations of configuration parameters, this can lead to many m-files. It has been suggested that the simulator be adapted to provide configuration function calls to allow programmatic reconfiguration.
The simulator was originally developed as a standalone Matlab tool. In practice it seems that researchers prefer to embed the simulation within a custom solver framework. Matlab, C++ and Python are being used, and so flexibility is clearly an important requirement. Currently, the TCP/IP interface to the simulator exposes only a subset of the function calls. These will need to be expanded along with the new design.
One potential idea is to move from a task / platform representation to an environment / platform representation. In the new representation the client code would initialise a qrsim object with an environment and dynamically add platforms with states. Optional get(.) and set(.) methods will be exposed on all entities to allow calling code to configure the environments and platforms programatically.
The text was updated successfully, but these errors were encountered:
Those who are currently using qrsim have expressed the need to configure simulations programatically. Currently, the simulation setup is defined in a set of static m-files. In order to change the noises, etc. one needs to create a new m-file. For simulations that test many combinations of configuration parameters, this can lead to many m-files. It has been suggested that the simulator be adapted to provide configuration function calls to allow programmatic reconfiguration.
The simulator was originally developed as a standalone Matlab tool. In practice it seems that researchers prefer to embed the simulation within a custom solver framework. Matlab, C++ and Python are being used, and so flexibility is clearly an important requirement. Currently, the TCP/IP interface to the simulator exposes only a subset of the function calls. These will need to be expanded along with the new design.
One potential idea is to move from a task / platform representation to an environment / platform representation. In the new representation the client code would initialise a qrsim object with an environment and dynamically add platforms with states. Optional get(.) and set(.) methods will be exposed on all entities to allow calling code to configure the environments and platforms programatically.
The text was updated successfully, but these errors were encountered: