Part of the role of the CMS team is to support members of CLEX with computational isues such as those arising with running models, accessing data and analysing data.
The CMS team supports a range of models (listed in the navigation bar on the left\ hand side of the page). We can provide assistance for other models, but this will be limited in scope and dependent on the availability of team resources. We also support analysis and other general computing tasks on NCI machines. We can provide general advice for activities undertaken at other sites, or on home machines, but this is necessarily limited as we have no control over, or familiarity with other systems.
There are a number of different ways to contact the CMS team to get support:
- Climate Weather Science helpdesk email@example.com
- The CLEX slack workspace arccss.slack.com
- One-on-one videocall
- In person with local CMS team member
The slack workspace is a good way to contact other CLEX members as well as the CMS team. It is best suited to shorter less complex queries in general. There are a number of channels focussing on different topics. When asking for help it may be that someone else from the Centre will have some useful feedback.
The help desk email is the preferred method for requesting help, as it allows the CMS to triage any queries to reserve time of the CMS team members for other activities. It also allows better visibility of open requests for the CMS team especially for queries that take several days to solve. We also cover for team absences.
Guidelines for help requests
When seeking assistance there are some steps that should be taken to make the most efficient use of everyone's time:
- Include all relevant information:
- what machine are you running on: your machine (what OS), Gadi at NCI, VDI at NCI, accessdev at NCI or another server (give name)
- if working at NCI was the issue in a login session or on the PBS compute nodes?
- upload any code to gist.github,com or for more complex examples create a GitHub repository. If you cannot put the code on Github because of licensing, put it on NCI and give us the path. Do not send copies of your code.
- if relevant, specify the modules that were loaded, or environment variables that were set. Tell us if you load modules in your .bashrc or .bash_profile files (unrecommended practice!)
- if a command produces an error make sure to include the exact command run, including all arguments. The simplest is copy-paste.
- if a script produces an error make sure to include the exact name of the script and the exact way you execute the script. Copy-paste is the simplest here again.
- Add any relevant reference. It is unlikely you are referring to a paper-only resource, so include the link (or at least the URL), a quote from emails and webpage (with the address to the relevant page), forward emails, link to a paper... For example, if you say: "As I've seen on the wiki", "As per the article X" etc. you need to put the reference.
- Please check to make sure any specified directories and/or files have group permissions set such that they can be accessed. Assume we can access the shared filesystems at NCI: /scratch and /g/data for your group. If we can't, we'll tell you what to do. /home directories are per default personal! You will need to change permissions for us to access!
- Where appropriate, reduce your query to a minimal reproducible example (Stack Overflow has a nice description of what this means, note that the formatting requirements are redundant)
- Please do not send code or error messages as screenshots or poorly formatted text
- Please submit new help requests for substantially new queries and not just append to existing queries. This makes sure any new query is visible to all team members, and can be triaged appropriately. We also have the satisfaction of completing a task rather than have it drag on interminably. Additionally, it provides us with a more organised database of queries and solutions.
To foster best practice software development for code housed in a GitHub repository (or similar) the following steps are preferred:
- Create an issue in the repo for the bug/problem
- Add a test for the specific bug where appropriate
- Document solution in the issue and refer to commits/pull requests: this creates a tight link between discussion of the problem and potential solutions with the code changes made to address points raised in the discussion. This could be done by the CMS team member helping you when appropriate.
- Resolve issue through a pull request mechanism. This could be done by the CMS team member helping you when appropriate.
- Close issue when fix has been committed
What can users expect
Users can expect:
- to receive a reply to a query within 2 hours during normal business hours
- have their problem solved if it is within scope, or a work-around suggested, and if not then an explanation of why their problem is currently not solvable
- where an update is required for a current ticket to wait no longer than a week during a non-holiday period
If any of the above expectations are not being met, contact the CMS team. We are only human and sometimes might inadvertently let slip some requests.
Blog post on Writing the perfect question