How to ask for help

For help fixing an error or bug, send a message in the Unity User Community #help-desk Slack channel, or email hpc@umass.edu. Always submit questions to Slack or our help email, and not directly to a team member.

Before seeking help from our facilitation team, try searching your error online and in the #help-desk chat history. There’s a good chance that the issue you are running into has been encountered and solved by someone else.

Create a new message or email for each new help request. Avoid replying to past message threads with a new and unrelated problem, as we may not see it right away (or at all)!

You can also attend weekly office hours with a Unity facilitator on Tuesdays from 2:30-4:00 PM EST. See the Contact page for the link and more details.

Please include the following information in your help desk submission:

1. Provide a brief summary of the issue you are experiencing:

  • Avoid only saying “X didn’t work”. The better you describe the problem, the fewer follow up questions we need to ask and the quicker it will take to solve your problem.

2. Describe your platform/environment:

  • Where are you experiencing the error? (e.g., OOD, shell, interactive/batch, etc.) Did you or someone else compile the code? Which modules were loaded? Providing these details about your environment will help save time wasted from debugging in a different environment.

3. Provide a small, quick, and reproducible example of the error:

  • Include a code snippet, script, or command that consistently and quickly reproduces the issue.
  • We can copy, paste, and run an example that reproduces the problem ourselves in order to see the problem you are encountering. If we have to write input files and run scripts solely based on a potentially incomplete description of the problem you are encountering, it will take much longer for us to help you
  • Screenshots, although better than nothing, make it more difficult for us to copy your commands
  • Make the example as small and quick as possible
    • Example: If you are running a calculation that crashed after running for one whole week, try to reduce the example before submitting it to us. The crash can likely be reproduced with a much smaller example, such as a smaller system size, grid, or basis set.

4. Provide a small, quick, and reproducible example of the error:

  • Copy and paste the exact error message you received into your help desk submission.

5. List the specific job number(s) that exhibited the error:

  • Note: Oftentimes, the issue is with the request and not the program.

6: Include your troubleshooting attempts and results:

  • To focus on the problem and avoid going back and forth, tell us the steps you have already taken to try to fix the issue. What were the results of that attempt?
  • It is useful to know what did not work, but it is just as helpful to know what did work. For example, if a user says “I can’t get X to run on two nodes,” then we might ask whether X worked on one node, on one core, or not at all.

7. Bonus tip: Avoid the XY problem

Quoting from https://xyproblem.info/:

  • User wants to do X.
  • User does not know how to do X, but thinks they can fumble their way to a solution if they can just manage to do Y.
  • User does not know how to do Y either.
  • User asks for help with Y.
  • Others try to help user with Y, but are confused because Y seems like a strange problem to want to solve.
  • After much interaction and wasted time, it finally becomes clear that the user really wants help with X, and that Y was not even a suitable solution for X.

Please try to avoid the XY problem. If you are having issues with Y but are actually trying to do X, please let us know about X. Try and tell us exactly what you are trying to do. Oftentimes, solving Y can take a long time while solving X is much simpler.