If Dave says it's ok then it must be! :)
(Thanks for the explanation)
> On 11 Nov 2015, at 23:04 , Ralph Castain wrote:
>
> Every orted maintains knowledge of where every process in the DVM is located
> in case some local client needs information or to otherwise communicate
> out-of-band with
Every orted maintains knowledge of where every process in the DVM is located in
case some local client needs information or to otherwise communicate
out-of-band with some non-local peer. The RTE has no idea of the possible
communication pattern, so we err on the side of more info to avoid someti
> On 11 Nov 2015, at 22:43 , Ralph Castain wrote:
> You must have the “-d” option set on the orte-dvm cmd line?
Yes.
> You’ll get one of those from every daemon in the job each time you launch an
> app.
Ok, that explains the number better :)
Why is every orted aware of a job on another orted?
You must have the “-d” option set on the orte-dvm cmd line? You’ll get one of
those from every daemon in the job each time you launch an app.
> On Nov 11, 2015, at 1:03 PM, Mark Santcroos
> wrote:
>
> Hi,
>
> I'm seeing this message an awful amount of times. (I.e. orders of magnitude
> more
Hi,
I'm seeing this message an awful amount of times. (I.e. orders of magnitude
more than I launch processes)
[nid15897:18424] [[2305,0],103] orted:comm:process_commands() Processing
Command: ORTE_DAEMON_ADD_LOCAL_PROCS
How should I interpret that?
Thanks
Mark
I’m not saying it’s a bad suggestion - just pointing out that it likely wasn’t
caused by carelessness.
Setting something up on odin would be tricky, but someone could look at that
environment to see why it’s generating all these when we don’t see them
elsewhere - maybe it would be simple to set
On Nov 11, 2015, at 10:09 AM, Ralph Castain wrote:
>
> FWIW: I don’t think that’s the issue here. I don’t see these warnings on my
> CentOS7 box, for example. I think this is driven by the fact that odin has
> some very old compilers and a very different environment, and so it has
> historical
FWIW: I don’t think that’s the issue here. I don’t see these warnings on my
CentOS7 box, for example. I think this is driven by the fact that odin has some
very old compilers and a very different environment, and so it has historically
generated more warnings.
The warnings often are valid - the
Once you squash all these warnings, you could set up a little bit of Jenkins or
Travis CI logic to check for PRs that add new warnings and marks them
appropriately. Of course, with people making commits directly to master,
warnings introduced by those direct commits will be ascribed to those wh