Let's shift this to the devel mailing list and add it to the Tues telecon.
Thanks for clarifying. Sounds to me like the suggestions made below are right -
we shouldn't be distributing binary in the main tarball for export reasons.
Seems like we have four options:
1. A separate Windows-tool tarb
Hi,
In the User's list, Jeff mentioned generating the windows flex code
during make dist time, I didn't think about it before, it should work if
flex is newer than 2.5.4 (the latest version is 2.5.35).
In the created tarball, the flex generated c source won't compile under
Windows, that's be
Ok, moving this back to devel (sorry, I replied to an earlier mail -- before
Ralph moved it to devel).
Let's figure out how to generate the relevant code that you need at "make dist"
time and not include flex.exe in the tarball -- it can still be in svn if you
want/need it. You might want to n
Actually, I take that back -- the .c files *are* in the tarball already.
Are you saying (per your other mail) that the .c files are simply generated by
a flex that is too old, and we need to update the flex that is used to generate
the .c files in the tarball? If so, that's a relatively simple
Are you saying (per your other mail) that the .c files are simply generated by a flex
that is too old, and we need to update the flex that is used to generate the .c files in
the tarball? If so, that's a relatively simple change to make in the "make a
tarball" scripts at IU.
Yes, exactl
Hi,
I'm wondering whether the HOSTNAME environment variable shouldn't be
handled as a "special case" when the orted daemons launch the remote
jobs. This particularly applies to batch schedulers where the caller's
environment is copied to the remote job: we are inheriting a $HOSTNAME
which is the n
On Jan 22 2010, Nadia Derbey wrote:
I'm wondering whether the HOSTNAME environment variable shouldn't be
handled as a "special case" when the orted daemons launch the remote
jobs. This particularly applies to batch schedulers where the caller's
environment is copied to the remote job: we are inh
Hi Nadia
That sounds like a bug in your SLURM config file - SLURM certainly doesn't
propagate "hostname" by default as that would definitely mess things up for
more than OMPI.
Are you sure that SLURM is propagating the environment (something I have never
seen before)? Or is OMPI mistakenly pic
For SLURM, there is a config file where you can specify what gets propagated.
It is clearly an error to include hostname as it messes many things up, not
just OMPI. Frankly, I've never seen someone do that on SLURM.
I believe in this case OMPI is likely incorrectly picking up the environment
an
A quick and easy way to answer my question of slurm vs ompi:
Just do "srun script-that-echos-hostname-and-gethostname". If you get the right
hostnames, then OMPI is to blame, not slurm.
On Jan 22, 2010, at 8:07 AM, Ralph Castain wrote:
> Hi Nadia
>
> That sounds like a bug in your SLURM config
On Fri, 2010-01-22 at 08:12 -0700, Ralph Castain wrote:
> For SLURM, there is a config file where you can specify what gets propagated.
> It is clearly an error to include hostname as it messes many things up, not
> just OMPI. Frankly, I've never seen someone do that on SLURM.
>
I'm going to che
On Jan 22 2010, Ralph Castain wrote:
For SLURM, there is a config file where you can specify what gets
propagated. It is clearly an error to include hostname as it messes many
things up, not just OMPI. Frankly, I've never seen someone do that on
SLURM.
Well, it's USUALLY an error That'
Shiqing and I took this offlist and have a solution which looks like it works.
End results:
- no more flex.exe in tarballs
- updated the flex to 2.5.35 on the IU machine that is used to generate 1.4 and
1.5 tarballs; hence, the generated _lex.c files in the tarball are
Windows-friendly
- chang
On Fri, 2010-01-22 at 08:22 -0700, Ralph Castain wrote:
> A quick and easy way to answer my question of slurm vs ompi:
>
> Just do "srun script-that-echos-hostname-and-gethostname". If you get the
> right hostnames, then OMPI is to blame, not slurm.
>
No, I'm not...
Will check the configuration
Hi,
When I try to select different alltoall algorithms using command line:
$> mpirun -mca coll_tuned_use_dynamic_rules 1 -mca
coll_tuned_alltoall_algorithm 2 IMB-MPI alltoall
it just crashes.
I suppose that "coll_tuned_use_dynamic_rules" and
"coll_tuned_alltoall_algorithm" should be used tog
Hi,
I tracked this down a bit, and my impression is that this piece of code in
coll_tuned_component.c
if (ompi_coll_tuned_use_dynamic_rules) {
mca_base_param_reg_string(&mca_coll_tuned_component.super.collm_version,
"dynamic_rules_filename",
16 matches
Mail list logo
