Input geometry parser bug

[aka-Marlen]

Dear OpenQP team,

when initial geometry is given inside the file in a format: "[input] system= 6 -2.483901893 0.000000000 -3.490599224 ..."

the coordinate line is interpreted as a keyword and the job fails with an error: "Traceback (most recent call last): File "/.../.local/bin/openqp", line 33, in sys.exit(load_entry_point('PyOpenQP==1.0', 'console_scripts', 'openqp')()) File "/.../.local/lib/python3.9/site-packages/oqp/pyoqp.py", line 228, in main oqp_runner = Runner(project=project_name, File "/.../.local/lib/python3.9/site-packages/oqp/pyoqp.py", line 81, in init self.mol.load_config(input_file) File "/.../.local/lib/python3.9/site-packages/oqp/molecule/molecule.py", line 259, in load_config self.config = self.get_config(input_source) File "/.../.local/lib/python3.9/site-packages/oqp/utils/mpi_utils.py", line 115, in wrapper attr = func(self, *args) File "/.../.local/lib/python3.9/site-packages/oqp/molecule/molecule.py", line 248, in get_config config = parser.validate() File "/.../.local/lib/python3.9/site-packages/oqp/utils/input_parser.py", line 55, in validate raise ValueError(f"Unknown option: {section}.{option}") ValueError: Unknown option: input.6 -2.483901893 0.000000000 -3.490599224"

The same error is returned for the format "[input] system= C -2.483901893 0.000000000 -3.490599224 ..."

When the initial geometry is submitted as a separate file (e.g., 'system=filename.xyz'), the parser works without problems, whether atoms are denoted by symbols or numbers, and both in the presence or absence of preceding spaces.

If such behaviour is intended, then probably this feature needs an explicit mention in the description of "[input]system" keyword (https://github.com/Open-Quantum-Platform/openqp/wiki/INPUT)? The necessity of the preceding spaces is not obvious from the example given in the section.

Example files are attached. geometry_parser_bug.zip

[Alireza-Lashkaripour]

Dear @aka-Marlen,

Thank you for your message,

I will point out the problems with the inputs failing one by one:

. ├── c6h6_failing_1.inp ==> You need a line space from the beginning of the line, like the working inputs (Only for the geo. inside input). ├── c6h6_failing_2.inp ==> You need a line space from the beginning of the line, like the working inputs. ├── c6h6_working_1.inp ├── c6h6_working_2.inp └── examples_external_xyz_file_all_working ├── 1_atom_numbers_failing │   ├── c6h6.inp │   └── c6h6.xyz ==> The xyz format is not correct, the number of the atoms do not match the reported on in .xyz file. ├── 2_atom_numbers_spaces_working │   ├── c6h6.inp │   └── c6h6.xyz ==> Same problem like before. ├── 3_atom_symbols_failing │   ├── c6h6.inp │   └── c6h6.xyz ==> Same └── 4_atom_symbols_spaces_working ├── c6h6.inp └── c6h6.xyz ==>

BTW, this is a correct .xyz format:

12
symmetry c1
C       -2.483901893      0.000000000     -3.490599224
C       -3.639970586     -0.354690359     -2.792435224
C       -1.327833200      0.354690359     -2.792435224
H       -4.539395693     -0.630640582     -3.335608224
H       -0.428408094      0.630640582     -3.335608224
C       -3.639970586     -0.354690359     -1.396105224
C       -1.327833200      0.354690359     -1.396105224
H       -4.539395693     -0.630640582     -0.852932224
H       -0.428408094      0.630640582     -0.852932224
C       -2.483901893      0.000000000     -0.697941224
H       -2.483901893      0.000000000      0.388405776
H       -2.483901893      0.000000000     -4.576946224

You can check our input examples: link or simply use our input generator: link.

[aka-Marlen]

Dear Alireza,

thank you very much for the quick response!

I'm sorry, I somehow gave confusing names to some of the directories. Examples with external .xyz files all work fine (though you are right, the header line is wrong, but on the stage of geometry reading it doesn't matter anyway).

My question was more about examples c6h6_failing_1.inp and c6h6_failing_2.inp and the necessity of having the line space at the beginning of the line; why those leading line spaces are necessary and if it is possible to sort it out during parsing? The overall question appeared exactly because "external" and "internal" geometries are apparently parsed in different ways: in separate .xyz files leading line spaces are not important, while for "internal" they do matter.

In any case, this is not a big issue, but probably the importance of having leading line spaces could be pointed out in the description of the "internal" format (at the page https://github.com/Open-Quantum-Platform/openqp/wiki/INPUT).

[Alireza-Lashkaripour]

Dear @aka-Marlen

Bug is resolve now.