[visit-developers] Generalize site-specific launch code [was LSF/bsub parameters]

Sean Ahern ahern at ornl.gov
Fri May 29 17:01:26 EDT 2009

Among the ideas I've had for VisIt 2.0 has been a generalized execution 
mechanism for host profiles, augmented with data that is discovered from 
the environment and also from the user when defining how to launch a 
remote job.  I have yet to write up these ideas, but I still have hopes 
to completely redo how we do host profiles and remote execution in VisIt 
2.0.  It would definitely remove ALL host-specific coding from 


Sean Ahern
Oak Ridge National Laboratory
AIM: ornlsean

Mark Miller wrote:
> Hi All,
> I'd bet someone on the team has already thought about this but I wonder
> if there is something 'simple' we could add to launch scripts to allow
> them to 'execute some arbitrary code in some specified file' in addition
> to or instead of 'normal' launch code? This would allow users to tailor
> site-specific changes to launch behavior without having to constantly
> edit (and us maintain) site and machine-specific code in the repo? If
> that would be possible, it would make a lot of the code in
> internallauncher having to do with specific batch systems etc. 'go away'
> I think. I certainly do not know much about any of these systems but
> have got to believe we can adjust our launch scripts in a way that makes
> it possible to do any arbitrary thing at a site WITHOUT having to change
> trunk/src/bin/internallauncher.
> Mark
> ------------------------------------------------------------------------
> Subject:
> Re: [visit-users] LSF/bsub parameters
> From:
> Sean Ahern <ahern at ornl.gov>
> Date:
> Fri, 29 May 2009 16:11:29 -0400
> To:
> VisIt software users community <visit-users at email.ornl.gov>
> To:
> VisIt software users community <visit-users at email.ornl.gov>
> Rick Angelini wrote:
>> So, this actually works:
>>        push @parcmd, "mpirun.lsf --gm-copy-env @visitcmd";
>>        open(MYFILE, ">output.txt") or die "Can't open output.txt: $!";
>>        print MYFILE "@parcmd\n";
>>        close MYFILE;
>>        @parcmd = "/bin/sh output.txt";
>> I'm sure there's a more elegant way to do this, but for testing 
>> purposes, this is a good start.  So, if this is the final solution, 
>> can I hack the GUI to add a script name/path that the startup command 
>> gets dumped to?
> I can't imagine this is a good final solution.  But if you must go down 
> this route, I’d think that hardcoding some ARL path and a 
> tmpnam-generated filename would be a better solution than having to 
> expose this to the user in the GUI.
> Since this works and execing @parcmd directly does not, it sounds like 
> something about the "exec @parcmd" in perl is messing things up. 
> Something from the man page makes me wonder:
>> If there is only one scalar argument or an array with one element in
>> it, the argument is checked for shell metacharacters, and if there
>> are any, the entire argument is passed to the system's command shell
>> for parsing (this is "/bin/sh -c" on Unix platforms, but varies on
>> other platforms). If there are no shell metacharacters in the
>> argument, it is split into words and passed directly to "execvp",
>> which is more efficient.
> How many elements are in the @parcmd array?  Could the command shell be 
> doing something strange to your commands?
> -Sean
> __
> Sean Ahern
> Oak Ridge National Laboratory
> 865-241-3748
> AIM: ornlsean
> -- 
> List subscription information: https:// 
> email.ornl.gov/mailman/listinfo/visit-users
> Searchable list archives: https:// email.ornl.gov/pipermail/visit-users
> VisIt Users Wiki: http:// visitusers.org/
> Frequently Asked Questions for VisIt: http:// visit.llnl.gov/FAQ.html

More information about the visit-developers mailing list