You have to create a minimal working example. Remove all complications until you have something working (as simple as just calling VASP). From then on, you add in the complexities one at a time.
–Create the simplest possible case:–
1/ Forget about ATAT itself for a moment. As Dr. Walle suggests: do you have VASP? Can you run VASP on an example structure (pseudopotentials, k-points, etc.)? Your error suggests VASP never ran or else the output files would have been there, but ATAT complains they are not.
2/ If so, make sure the path is correct when you set it up in ATAT including the path to the pseudopotentials.
So, say you have done that correctly. Let us find the bug in your code (in the following, I am not trying to insult your intelligence, but I am writing it as I think about these kind of nothing-works situations that you will meet a lot in your research):
ATAT has been granted for free which is a great advantage, so you can look into its source code. Try printing out the progress of the program as it runs and ask yourself:
1/ what is the first ATAT program I call? (runstruct_vasp, e.g.).
what is the code in that script? Take a look at it. Sometimes it is a script in your ~/bin (or whatever bin folder you chose on installation) so open it (e.g., "vim ~/bin/runstruct_vasp"). Other times, it is a c++ executable. So you find that file in the ATAT src folder (look at the makefile if you’re in doubt about the file that goes with the executable’s name). In your case though, I am pretty sure this is all csh scripts making it a bit easier.
Point is: You can print statements to track the progress and make sure it runs as expected.
Ok, the problem was not in runstruct_vasp. Then what? We continue:
2/ What does runstruct_vasp call?
It calls "code2" (I am giving generic names here because this procedure is general). Ok, go look at code2 and make some print statements. Did ATAT understand my local folder structure or does it make assumptions about this? Are all the files in the folder that ATAT needs? Print, print, print.
3/ Go to 2/ and ask "what does ‘code2’ call?". It calls code3. look at code3. Keep going like this until something unexpected shows up (and it will, or else it would run).
I have run ATAT with VASP many times (on many different computers, most of them supercomputers) so I know it works.
The above procedure is the brute-force debugging approach that is guaranteed to work. It has the added benefit of letting you learn the code as you read through it making future runs easier as well. You will get a bunch of "aha" moments. The computer only performs the tasks it has been asked to perform. This turns out to be a benefit for debugging: you ride along the code and as it goes you know exactly what happens. There is no way this approach fails (except if there is some obscure setup on your supercomputer where modules are not what you thought etc. but that does not seem to be your issue here).
I am not claiming this is always the best approach, but if you’re stuck and have no other ideas, this will do it.