New pull request with whitelist words and switching to American English #238
Conversation
|
preview available: https://docs.tds.cscs.ch/238 |
|
|
||
| The corresponding srun command should be modified as follows.: | ||
|
|
||
| srun gssr profile -wrap="python abc.py" |
There was a problem hiding this comment.
above it it test.py, here it is abc.py. Should be consistent.
There was a problem hiding this comment.
Another thing that caught my eye: What if my script is named with whitespace.py. How would I express this in the --wrap option?
There was a problem hiding this comment.
Thanks Andreas, good point about test.py and abc.py. Updated.
First of all, I will tell the user that people don't do whitespaces in file names on Linux. Jokes aside, I think the usual Linux applies. It should become --wrap="python with\ whitespace.py". That is my assumption. Not tested though.
This comment has been minimized.
This comment has been minimized.
|
preview available: https://docs.tds.cscs.ch/238 |
@check-spelling-bot Report🔴 Please reviewSee the 📂 files view, the 📜action log, or 📝 job summary for details.Unrecognized words (1)Pypi To accept these unrecognized words as correct and remove the previously acknowledged and now absent words, you could run the following commands... in a clone of the [email protected]:cerlane/cscs-docs.git repository curl -s -S -L 'https://raw.githubusercontent.com/check-spelling/check-spelling/2d5f9dd9d2d43584d36e4ae03a3508eff411eda9/apply.pl' |
perl - 'https://github.com/eth-cscs/cscs-docs/actions/runs/17150123790/attempts/1' &&
git commit -m 'Update check-spelling metadata' |
| [](){#ref-gssr-containers} | ||
| # gssr - Containers Guide | ||
|
|
||
| CSCS highly recommends that all users leverage on container solutions on our Alps platforms so as to flexibly configure any required user environments of their choice within the containers. Users thus have maximum flexibility as they are not tied to any specific operating systems and/or software stacks. |
There was a problem hiding this comment.
This paragraph is out of place: guidance on whether to use containers or not should go elsewhere.
Furthermore there are two recommended approache: containers and uenv.
Instead remove this paragraph, and start with the sentence below The following guide will explain how to install and use gssr within a container.
There was a problem hiding this comment.
Out of curiosity, do we even have such a guidance page? Fair statement about uenv and container though. I am mainly focus with ML users and they were told to do containers so I forget about uenv. I can remove that.
|
|
||
| ### Base Container from Nvidia | ||
|
|
||
| The most commonly used Nvidia container used on Alps is the [Nvidia's PyTorch container](https://catalog.ngc.nvidia.com/orgs/nvidia/containers/pytorch). Typically the latest version is preferred for the most up-to-date functionalities of PyTorch. |
There was a problem hiding this comment.
Please see the style guide recommendation of keeping one sentence per line
https://docs.cscs.ch/contributing/#text-formatting
There was a problem hiding this comment.
What is the problem? The two highlighted sentences are one line each. If you mean stuff in the code blocks, I can try to shorten some of them but some commands are meant to be of certain length.
However, I am very concerned now. Are you telling me that cscs-docs is restricting how one writes their documentations, illustrate their examples. This is too restrictive. I can't understand the logic behind it.
There was a problem hiding this comment.
Please read the link I provided: it explains very clearly why this style choice is preferred.
There are restrictions to how docs are written, because we want to have consistent documentation across the whole docs site, that can be maintained. This requires a little bit of discipline to ensure consistency (the restrictions are not very heavy)
|
|
||
| This tool will produce time-series and heatmaps of the profiled metric values. Here is an example of one set of plots generated by the tool from the application Megatron-LLM from EPFL. | ||
|
|
||
|  |
There was a problem hiding this comment.
As a rule, we only add images if they help explain something.
These are presented as is, so they don't need to be included (we can add images later when it is time to explain what they represent in detail).
This way we avoid adding MB to the history of the git repository, and we also reduce the deployment and build times for the site.
There was a problem hiding this comment.
Documentations are also advertising. The first page of a tool is to attract people to use the tool. The 2 images are ~100k combined. This is too much for cscs-docs?
-rw-r--r--@ 1 leongs staff 70937 Aug 22 10:14 heatmap_eg.png
-rw-r--r--@ 1 leongs staff 29784 Aug 22 10:14 timeseries_eg.png
I would like to know who decide on all these rules? Were they discussed, understood and agreed upon?
3 participants
No description provided.