Change to turbomole coordinate format output

General Discussion
1

Hi,

I don’t know if I would call this a bug, but the default turbomole coordinate file output has changed - it’s now using angs rather than the (turbomole) default Bohr. Is there any way to change this? I don’t see any settings at the point of saving the file.

I use avogadro to write coord files for crenso / crest_combi and these only conveniently read turbomole coord files in Bohr, they don’t like the angs option. They are hardcoded to read a file “coord”, so using another input file format (like xyz, which crest reads happily) is more awkward than it might be.

Any thoughts?

Thanks

Pete

2

I don’t know what versions of Avogadro you’re comparing. I added support for writing turbomole coordinate files 4 years ago with "$coord angs\n";

We can change it to default to Bohr, but the xtb docs literally indicate $coord angs is okay and I know I’ve used it:

Everything I’ve seen about Turbomole documentation includes $coord angs as a possibility.

Anyway - I don’t have a problem changing it, but I guess I’m confused by your comment that it’s “changed” and I guess I’m surprised that crest or xtb have a problem with coord files that use angs

3

Thanks for the quick response!

In 1.99.0 (so Feb 2024 release), at least , if I do build→ insert→molecule→acetaldehyde, then export to coord.tmol, the file looks like:

$coord
2.39316806195313 -0.01819995230981 1.28694128564313 h
1.16172614287493 0.07298500239950 -0.36612687781301 c
1.54007387953828 1.78523182918594 -1.43079479718215 h
1.60841204539642 -1.58415363112988 -1.51158625820400 h
-1.53789313559003 -0.04341645772173 0.45535785570908 c
-2.04906783185305 -1.75681034826604 1.56177360463158 h
-3.11644183903318 1.54438245510326 0.00441440022799 o
$end

If I do the same in 1.103 I get:

$coord angs
1.2664120000 -0.0096310000 0.6810200000 h
0.6147590000 0.0386220000 -0.1937460000 c
0.8149720000 0.9447040000 -0.7571440000 h
0.8511350000 -0.8382980000 -0.7998970000 h
-0.8138180000 -0.0229750000 0.2409650000 c
-1.0843160000 -0.9296640000 0.8264550000 h
-1.6491550000 0.8172520000 0.0023360000 o
$end

the issue with crenso/crest_combi is probably due to these being old - crenso only works with old crest/censo versions. It’s possible to use crest_combi with new crest and then censo separately, which is my current workflow, so files in angs should work there (the machine I do that on is down at the moment). I was just curious because my old workflow stopped working and saw this change. I don’t think it’s necessary to switch back to Bohr if the general view is that angs makes more sense.

thanks

Pete

4

I remember struggling with similar issues before, e.g. here I describe how xtb always returns a turbomole file that uses bohr. I posted [an issue]((Allow .tmol or .coord in angstrom · Issue #915 · grimme-lab/xtb · GitHub) for that on the Grimme GH and it was later fixed, but it shows how the tendency is to default to bohr.

The fact that angs is explicitly required to indicate angstrom, but the unit is assumed to be bohr if nothing is specified, further indicates that bohr is the default from the point of view of turbomole.

I haven’t tested CREST myself, but I can well believe it’s hard-coded to accept only coordinates in bohr given that its documentation states that turbomole coord format means bohr (straight-up ignoring the angstrom option).

Might be a good time as well to note that Avogadro confusingly offers two very similar options in the file save/open dialog for turbomole files: “TurboMole Coordinate format” and “Turbomole”. To make that even more confusing, both seem to output the same? I wonder if maybe one was meant to just be a $coord block and the other should include other things too? I don’t know though – frequencies at least don’t seem to be written in either case.

5

It’s because one is the internal format and one is through Open Babel. I can see if I can omit the Open Babel version.

1 Like
6

OK, so I can clarify things a bit better now:

in 1.99, installed with apt in ubuntu, if I set the file type to

“TurboMole Coordinate format”

and click save, it says: The file extension is missing, so the format cannot be determined. Do you want to add it. (and fails to write the file)

If I set the file type to:

“Turbomole”

It writes out the file, with no extension, and in angs (so I assume this is the internal writer rather than openbabel)

Regardless of if I set the file type from the list, if I provide file extension, eg set filename to “something.tmol”, it writes the file in Bohr. (this was always my workflow, to avoid scrolling down the long list).

In 1.103, if I don’t add an extension, I get the error whichever file type I choose; and if I do provide the extension, eg set the filename to “something.tmol” or “something.coord”, then it writes in angs.

So I guess the change in Avogadro is that it’s defaulting to the internal rather than openbabel writer?

If I give crest 3.0.2 (current version) a coord file with angs, it segfaults, and the crest_input_copy.xyz it generates is clearly scaled by the Angstrom/Bohr ratio.

So for me the workaround here is to make crest_combi use an xyz file as input - this is just a question of two instances where the input filename appears. This seems to be fine, and from my perspective the issue of the turbomole files is no longer a problem; still there may be issues with other software not reading files in angs so the option to force writing in Bohr could be useful.

Thanks for your help!

Pete

7

That seems like a definite bug. I’ll talk to Philipp Pracht about that, but also patch the Avogadro export. (Should get to it today.)

Thanks for the report, we’ll get it sorted – glad you have a workaround in the meantime.