Getting help

1. Contact

If you need assistance, please email This will generate a new ticket and one of the members of our team will assist you as soon as possible.

In order for us to help us with your request as effectively as possible, please refer to the instructions below.

2. How to write a good support request

Writing good support requests is not only good for the support team, it is also better for you. Due to us having lots of help requests, the time to understand each problem is at a premium. The easier it is to understand yours, the faster we will get to it. Below is a list of good practices.

2.1. Do not contact team members directly

Always send requests to and team members will respond there. Creating tickets via means they will be tracked and have more visibility. Sending the request to makes sure that somebody will see your request even if one of our team members is out of the office.

2.2. Do some research before submitting tickets

Before submitting your ticket, consider doing a simple internet search for your exact error message. Other scientists may have encountered similar issues and have a solution.

2.3. Provide a descriptive subject

The subject line of your email should be descriptive. A subject line of Problem on Ganymede is too vague to be useful. This makes it difficult for us to locate your issue when trying to address it in our ticketing system.

Please remember that our entire team sees all incoming requests so it’ll help you to get your request answered quickly if it is not too generic.

2.4. Include commands and error messages

When submitting help requests, please include the commands you run as well as any error messages you receive. Please copy and paste these into the email/ticket. If you fail to do so, we will likely be annoyed and request this information.

Please refrain from submitting screenshots or pictures (JPEG, PNG, etc) of what you see on your screen. Not everyone views emails using a graphical email client and doing this slows us down while trying to research your issue. We don’t care what your ticket "looks" like. We just need the relevant text copy/pasted into the email/ticket so we can quickly and easily research your problem.

2.5. Create a new ticket for new issues

Do not respond to unrelated tickets for new issues. Every issue should receive a unique number and will contain the number in the subject line. Replying to old tickets for new issues means your email will get filed under the wrong thread and will possibly be overlooked.

2.6. The XY problem

  • User wants to do X.

  • User doesn’t know how to do X, but thinks they can fumble their way to a solution if they can just manage to do Y.

  • User doesn’t 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 wasn’t even a suitable solution for X.

Please try and 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.

2.7. Provide relevant information about what works

If you are submitting a request because your issue only manifests in certain situations, let us know. It’s helpful for us to know if your problem exists all the time or if it’s only present under specific conditions. Providing us with more information will make it easier to isolate the issue and avoid long email threads where we have to ask many questions. Let us know what steps you’ve taken to try and isolate the issue so that we can quickly provide assistance.

2.8. Include information about your environment

Are you running custom-compiled code? Which modules are loaded? Are you running your code in a custom Conda environment? If you use a non-default environment and fail to include that information, we will waste time debugging in a different environment.

2.9. Simple issues

Simply saying "X didn’t work" will not result in us solving your issue. Please provide the exact commands run, the environment, the output and error messages. Providing us with the actual error messages is extremely useful. It allows us to easily copy and paste it while researching your issue.

The better you describe the problem the less we have to guess and ask.

Oftentimes seeing the error message is enough to provide a useful answer. In almost every case, you will need to make sure the problem is reproducible and provide us with a way to reproduce.

2.10. Complex issues

For complex issues, please create an example that we can copy, paste and run which demonstrates the problem. It’s too time-consuming for our team to try and debug your issue based on incomplete information. Please also see below.

2.11. Make the example as small and fast as possible

If you are running a calculation which crashes after a week, you will need to reduce the example running time. Your goal should be to get the example as small as possible while still demonstrating the issue.

It will be easier for us to debug an issue that crashes within a few seconds than one which has a log time measured in minutes or hours. Yes, this requires some effort on your part but it will pay off with a support request that we can answer quickly and effectively.