Starting non-MUSIC executables with MUSIC

[jakobj]

For ease of use, and (possibly) weak guarantees for synchronization between processes, it would be great if MUSIC could also start executables which do not use MUSIC internally. This would allow for example starting of ROS directly from a MUSIC config file instead of having to launch it manually in another process. Currently MUSIC will only launch the executable without MUSIC support, while the other processes are not started. This is probably caused by some barrier not hit.
@mdjurfeldt please advise on how this could potentially be addressed
@weidel-p please comment whether you'd find this useful

[mhoff]

I agree that this feature might be very convenient. However, lets say you would want to fire up ROS/Gazebo in parallel with MUSIC (and ROS-MUSIC) nodes. Then, you need to rely on ROS/Gazebo being launched before the ROS-MUSIC nodes attempt to communicate with the ROS master.

I guess the more straight-forward way is to simply wrap the MUSIC launch itself (e.g. in a shell script), such that Gazebo/ROS and other processes are started whenever they need to be started in relation to the MUSIC process group.

[uahic]

I think launching external applications in some specific order is not really in the scope of MUSIC; You could follow the suggestion of @mhoff , that is probably the most resource-saving way to handle that :)

We are currently working on concepts for MUSIC version (3?), whereas we will hopefully make ROS unnecessary. One step towards this is to have selectable communication stacks, the other is customizable MUSIC launchers. There you could have one which first checks the environment to be "setup" but I still think that is a matter that should be addressed outside.

[jakobj]

Yes, of course you are both right. It is straightforward to write an additional script that starts all necessary processes. I just had some lightweight solution in mind that would avoid having yet another script: a flag specifies whether a particular process is using MUSIC and a global parameter sets a delay for starting all processes that have MUSIC support. The MUSIC script would then look something like the following

stoptime=1.
rtf=1.
music_startup_delay=5.
[non_music_process]
  binary=non_music_binary
  np=1
  uses_music=false
[music_process_0]
  binary=music_binary_0
  np=1
  music_timestep=1.01
[music_process_1]
  binary=music_binary_1
  np=1
  music_timestep=1.01
music_process_0.out->music_process_1.in[1]

In this case, MUSIC would start the non_music_process wait 5 seconds, then launch the other binaries.
@uahic if this would anyway be obsolute with MUSIC 3, we can of course close the issue

[mdjurfeldt]

We also have to consider whether non-music processes use MPI and whether they need to use a communicator. In addition to specifying modes through MUSIC configuration scripts (e.g. use_music), there's also the case where no output and input ports are specified for an application. Should that mean MUSIC-aware with no connections or MPI-aware or none of these? I guess the first. Since MUSIC is launched by an mpirun command, the case use_music = false (which I prefer compared to uses_music), the application still needs to be MPI-aware. Would you still be fine with that, Jakob? Den 13 jan. 2018 7:31 PM skrev "Jakob Jordan" <[email protected]>: Yes, of course you are both right. It is straightforward to write an additional script that starts all necessary processes. I had some lightweight solution in mind, in which a flag specifies whether a particular process is using MUSIC and a global parameter sets a delay for starting all processes that have MUSIC support. The script would then look something like the following stoptime=1. rtf=1. music_startup_delay=5. [non_music_process] binary=non_music_binary np=1 uses_music=false [music_process_0] binary=music_binary_0 np=1 music_timestep=1.01 [music_process_1] binary=music_binary_1 np=1 music_timestep=1.01 music_process_0.out->music_process_1.in[1] In this case, MUSIC would start the non_music_process wait 5 seconds, then launch the other binaries. @uahic <https://github.com/uahic> if this would anyway be obsolute with MUSIC 3, we can of course close the issue — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#51 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADcfCeMLD6DAmvR1rFtl5aVZXoj3zXLqks5tKPZkgaJpZM4RIq8W> .