Sanitize unit test and increase # significant digits PC gradients

[pultar]

Thanks for the fix for #683!

I agree with you (#718 (comment)) that a third system would be overkill for the unit tests. I adjusted my PR accordingly:

• increase the number of significant digits of PC gradients in the output file to 12 to be consistent with output for gradients and energy
• the unit test for embedding / C API uses the same system as the Fortran unit test and the documentation (water tetramer) for easier comparison
• I also check in the unit test for C API for energy, and gradients with the same threshold as elsewhere

I also noted that in the test I had included earlier and that is now replaced: charges were not balanced, potentially leading to numerically less stable calculations, which is not desirable in unit tests. This PR fixes this issue.

Signed-off-by: Felix Pultar felix.pultar@phys.chem.ethz.ch

[MtoLStoN]

I agree that having consistent test accuracy is a good practice. Maybe it would be good if we also find some way to test the read_pcme subroutine, as the error that was fixed in #720 was introduced there and not caught by any of our tests.

xtb/src/embedding.f90

Lines 88 to 91 in cb55e0e

	conv = 1.0_wp ! input is usually in *Bohr*
	if (set%pcem_orca) then
	conv = aatoau ! except when we try to read ORCA's pc-files
	endif

[pultar]

Sounds like a great idea! Would you like to add some code? You should be able to edit my PR.