This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
Not in that regard, depending upon what you mean by "recently". The
only changes I am aware of wrt nodes consisted of some changes to the
order in which we use the nodes when specified by hostfile or -host,
and a little #if protectionism needed by Brian for the Cray port.
Are you seeing this for every node? Reason I ask: I can't offhand
think of anything in the code base that would replace a host name with
the FQDN because we don't get that info for remote nodes. The only
exception is the head node (where mpirun sits) - in that lone case, we
default to the name returned to us by gethostname(). We do that
because the head node is frequently accessible on a more global basis
than the compute nodes - thus, the FQDN is required to ensure that
there is no address confusion on the network.
If the user refers to compute nodes in a hostfile or -host (or in an
allocation from a resource manager) by non-FQDN, we just assume they
know what they are doing and the name will correctly resolve to a
On Sep 10, 2008, at 9:45 AM, Greg Watson wrote:
> Has there been a change in the behavior of the -display-map option
> has changed recently in the 1.3 branch. We're now seeing the host
> name as a fully resolved DN rather than the entry that was specified
> in the hostfile. Is there any particular reason for this? If so,
> would it be possible to add the hostfile entry to the output since
> we need to be able to match the two?
> devel mailing list