Plugin to show hardware info

[amartyads]

I was planning to write a plugin that shows hardware info. At minimum, it would show which rank is on which node. Creating this issue for brainstorming and for input from others.

My ideas so far:

1. Accept a filename in xml. If there is filename, print the info in a CSV/TSV/whatever out current standard is. Otherwise, pretty-print to stdout.
2. The info should be (at the very least)
   1. The rank (output of MPI_Comm_rank)
   2. The processor_name (output of MPI_Get_processor_name)
3. Additional info we can have:
   1. The lower and upper bound of the subdomain in this rank (stepping on the DecompWriter's toes a bit here)
4. The info is only printed/written at beginning of simulation. To deal with load balancing, we can either add a print frequency in the xml, or we can trigger a write whenever a load balance occurs. For this, I would add a bool called balancedInLastTImestep somewhere (probably in DomainDecompBase) that is set once a rebalance is done, and reset at the beginning of the next timestep. (NB: I would like to have this bool anyway in the future for mamico reasons, but it's not necessary in this specific issue).

Any other input/ideas?

[FG-TUM]

Why duplicate the functionality of the DecompWriter?

[amartyads]

I could just merge this idea into DecompWriter, make it also write MPI_Get_processor_name somewhere. Would that be better than writing a separate plugin?

[FG-TUM]

I think if you just want to show the rank to hardware mapping this should be a standalone plugin. You could also include each ranks thread to core mapping.

[rubenhorn]

I agree with @FG-TUM that the plugins should probably stick to their main responsibility… I'm not a big fan of merging this with the decomp plugin.
Also, maybe we should output to a different format than simple tabular/text file.
JSON/YAML/XML allows for hierarchical structure, which is A) easier to parse in post-processing IMHO and B) accommodates additional hardware info on different systems (future-proof).

[cniethammer]

I agree with @FG-TUM and @rubenhorn that we should have a look at existing plugins and functionalities fist.
What are you trying to achieve exactly with these "hardware" information.
MPI process to hardware resource mapping information can easily be output by, e.g., mpirun --report-bindings in Open MPI - and in a much better way, e.g., including binding information.

[amartyads]

What I wanted to achieve was a way to persist the exact hardware information after a run is over, for checking later, like how in current ls1 output, we see the thread pinning from OpenMP for the master rank.
mpirun --report-bindings does do the exact thing I want, agreed. I could put that in a jobscript right before I run a simulation. But my idea was that having it in a plugin allows others to use that feature too.
For me personally, I wanted this for my mixed-architecture runs, so that when I run a job both on AMD and ARM (for example) I can see whether my hostfile worked, where the root node is etc.
If you think that this is too niche and not generally useful, we can shelve this idea.

[FG-TUM]

Does it?

1. OpenMPI also knows an unbound state, then the flag reports nothing.
2. If you want to also see OpenMP binding you need such a plugin afaik.

And getting all of this information in a nicely formatted csv (I don't care about the exact separator :P @rubenhorn) I see as beneficial. If you want to be fancy you could even include which NUMA domain a rank is in.