Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add new memory runLog info to memoryProfiler.py #1970

Merged
merged 9 commits into from
Oct 25, 2024
Merged

Conversation

albeanth
Copy link
Member

@albeanth albeanth commented Oct 24, 2024

What is the change?

Adds some potentially useful runLog statements to the memory profiler interface on how much memory is is use , how much is available, and the total available for a simulation. The first two are dynamic (i.e., change with (cycle, node)) while the third is static.

Why is the change being made?

Some memory intensive downstream analysis found this useful, so we thought we'd push it up to ARMI.


Checklist

  • The release notes have been updated if necessary.
  • The documentation is still up-to-date in the doc folder.
  • The dependencies are still up-to-date in pyproject.toml.

@albeanth albeanth added the enhancement New feature or request label Oct 24, 2024
@@ -101,11 +129,30 @@ def interactEveryNode(self, cycle, node):
mpiAction.broadcast().invoke(self.o, self.r, self.cs)

def interactEOL(self):
r"""End of life hook. Good place to wrap up or print out summary outputs."""
"""End of life hook. Good place to wrap up or print out summary outputs."""
if self.cs["debugMem"]:
Copy link
Member

Choose a reason for hiding this comment

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

I'm just wondering... should this same settings check be done at interactBOL and interactEveryNode?

I could be totally off-base here, I just can't tell why this is only done at the one time node.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not following. Can you elaborate?

Copy link
Member

Choose a reason for hiding this comment

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

Well, this memory profiler does nothing in interactEOL unless the setting debugMem is set to True.

So.... I would EXPECT that setting would control all the time points, not just the one.

If that's not the case cool, I'm just wondering what the difference is.

Copy link
Member Author

Choose a reason for hiding this comment

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

That setting does get used in interactBOL and interactEveryNode. These two just also do other stuff too.

Granted I don't know the original intent. The git blame for the vast majority of this module go well beyond my time with TerraPower.

Copy link
Member

@john-science john-science left a comment

Choose a reason for hiding this comment

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

Approved! I have a couple of minor thoughts for you, but no hills I'm prepared to die on.

Co-authored-by: John Stilley <[email protected]>
Copy link
Member

@opotowsky opotowsky left a comment

Choose a reason for hiding this comment

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

I'm a fan!

Note that we realize this code probably shouldn't be in ARMI but to push towards a deadline we have a separate cleanup ticket to bring parts of the memory profiler into internal tooling, where it belongs.

@opotowsky opotowsky merged commit 597f78a into main Oct 25, 2024
19 checks passed
@opotowsky opotowsky deleted the newMemoryInfo branch October 25, 2024 19:40
drewj-tp added a commit that referenced this pull request Oct 29, 2024
* main:
  Fixing HexBlock docstrings (#1981)
  Removing a duplicate hex rotation impl tag (#1979)
  Avoiding closing plots that are meant to be interactive (#1978)
  Ensuring HexBlock.rotate updates child spatial locators (#1943)
  Add new memory runLog info to memoryProfiler.py  (#1970)
  Fixing various doc build issues (#1974)
  Hiding sphinx-needs warnings during doc build (#1973)
  Fixing warnings in CLI startup (#1972)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants