That's great, glad I could help. The problem was this: When you write a file, you need a character that tells programs where a line ends, and that's a newline character. The trouble is that different operating systems use different characters to do this (you can read more about this in the wiki article I linked). Most programs like text editors know this and they can display all these varieties correctly, they may even give you the option to change from one to another. Other programs can't do this, and it seems we're both working with a few that don't. So our programs don't read the newlines quite right, and in your case that led the program to complain about the first thing on each new line (which happens to be the atom types). My export function just replaces newline characters that Windows and Apple systems use with the ones used by Linux and other Unix systems. You can still work with these files on Windows, I guess most of the tools you're using are clever enough to understand this. (Notably, Microsoft's own Editor will not display the files correctly, but I'm pretty sure all other text editors will.)

This is a complete shot in the dark, but do you by any chance use different operating systems for exporting the file and then for running the DFT codes? Because there are different conventions for linebreaks. For instance, I export files on my Windows PC and then run them on a Linux cluster, and that does not work out of the box. I use VASP, and the error message I get doesn't refer to formatting issues either. (In the case of VASP, the parser complains that a certain line doesn't have the expected number of entries, which is of course not the problem at all.) Let me know if that might be the problem and I'll post a solution.

Daniel - that's such an easy mistake to make. I feel like all the ...Form[] functions go against the spirit of the "everything is an expression" paradigm, because unlike Style, they don't actually return a particularly usable object.

That kinda sounds like a weird formatting problem... Can you try if this export function works, just so that we know whether or not it was a linebreak problem?

xyzExport[filename_, pos_, types_] :=
  Module[{content},
   content = 
    Join[{{Length[types]}, 
      StringSplit["Some name or title can go here"]}, 
     Join[{types[[#]]}, pos[[#]]/100] & /@ Range[Length[types]]];
   (*convert to UNIX linebreaks (LF):*)
   content = 
    ToCharacterCode[
     ExportString[content, "Table", "FieldSeparators" -> " "]];
   content = 
    If[MemberQ[content, 10],(*from LFCR or CRLF:*)
     DeleteCases[content, 13],(*from CR:*)content /. {13 -> 10}];
   (*export:*)
   Export[filename, content, "Binary"]
   ];

You can try something like this, or use your own molecular data instead:

xyzExport["benzene.xyz",
QuantityMagnitude[ChemicalData["Benzene", "AtomPositions"]],
ChemicalData["Benzene", "VertexTypes"]
]

Thanks all for the suggestions.

I am using SIESTA and CP2K for DFT calculations and the "Lev00&Tetr" package for pre and post processing. Each simply gives the error that the atom type is not known and calculations do not run! So far I have solved this problem by copying/pasting the coordinates to a pre-prepared file which is OK for small systems but not easy for systems of 1000 atoms!

Right you are, sorry. I should have realized this formatting would not be so easily handled.

I'll file this as a bug report and look into getting it improved.

I just did a quick test; the scientific form is indeed annoying, and I have no idea what to do about that.

The atom types look fine to me... What's wrong with them according to the programs you're using? (Also, which programs are you using?) Do your other programs perhaps require atoms to have unique types, i.e. not 4 rows of "C", but "C1", C2", C3", "C4"?

If all else fails, XYZ is an incredibly simple format; have you considered writing your own export function? (I know that's an ugly solution, sorry...)

Edit: About the number of digits... I suspect that might also be easier to remedy if you export as a plain table yourself...