Closed pitsteinbach closed 6 months ago
Attention: Patch coverage is 68.26923%
with 33 lines
in your changes are missing coverage. Please review.
Project coverage is 71.92%. Comparing base (
9bbe561
) to head (0f25632
). Report is 5 commits behind head on main.
Files | Patch % | Lines |
---|---|---|
src/tblite/double_dictionary.f90 | 68.26% | 3 Missing and 30 partials :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
I am not sure what is already implemented by TOML-Fortran.
I added this since I wanted to dump the double dictionary let's say from an xtbml calculation to a toml file, if xtbml is requested from CLI. I tought that using toml has the advantage of already having the functionality of dumping arrays and is very compatible with python for further use in ML scripts or so.
A toml_table
does implement most of the functionality of the double dictionary already, without the type constraint.
I see your point. The double dictionary can store arrays with more dimensions easily and its OOP structure is in my opinion more convenient. Also combining instances of dictionaries easily is a plus for me.
We should just decide how to move on from here, we can dissect the dictionary out again, which involves reworking the post processing PR mainly, and then further implementations I have planned.
Added toml read and write capability to double dictionary class.
This can be used to dump post processing results for example to toml files which are use commonly now in python applications. The toml functionality previously used in the project is thereby further expanded to the double dictionary type.
Directly using a toml table pointer to retrieve entries in python for example could be imagined.