Skip to content

Conversation

@azrael417
Copy link
Contributor

PhysicsNeMo Pull Request

Description

This fixes a wire error with new torch, because the wrong member variable is referenced in init process group, so the except branch is always triggered.

Checklist

  • I am familiar with the Contributing Guidelines.
  • New or existing tests cover these changes.
  • The documentation is up to date with these changes.
  • [] The CHANGELOG.md is up to date with these changes.
  • An issue is linked to this pull request.

Dependencies

@coreyjadams
Copy link
Collaborator

/blossom-ci

Copy link
Collaborator

@coreyjadams coreyjadams left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Casting local_rank to int before checking it's not-None seems like a good idea. What error were you encountering where it needed this?

Changing the access of rank/local_rank/world_size/device from the property access to private attributes seems counterintuitive. Can you elaborate on the reason for that change?

@NickGeneva
Copy link
Collaborator

/blossom-ci

world_size = int(os.environ.get("WORLD_SIZE"))
if "LOCAL_RANK" in os.environ:
local_rank = os.environ.get("LOCAL_RANK")
local_rank = int(os.environ.get("LOCAL_RANK"))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this int conversion handled in the next if block? And won't this break when LOCAL_RANK is None?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can that happen? if LOCAL_RANK is set, can it still be None: like with

export LOCAL_RANK=

?


manager._device = torch.device(
f"cuda:{manager.local_rank}" if torch.cuda.is_available() else "cpu"
f"cuda:{manager._local_rank}" if torch.cuda.is_available() else "cpu"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any specific reason to switch to using private attributes here instead of the public property versions of these as was used before?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the external ones alias those internal ones, that is OK, but isn't it cleaner to use the internal ones for internal tasks?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants