-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Starting non-MUSIC executables with MUSIC #51
Comments
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. |
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. |
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 |
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" <notifications@github.com>:
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>
.
|
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
The text was updated successfully, but these errors were encountered: