Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Better C-API #102

Merged
merged 3 commits into from
Feb 9, 2020
Merged

Better C-API #102

merged 3 commits into from
Feb 9, 2020

Conversation

awvwgk
Copy link
Member

@awvwgk awvwgk commented Jan 16, 2020 •
edited
Loading

fixes #98 (3. point)

The current C-API implementation, as a proof-of-concept, has shown several weaknesses which should be addressed before launching version 6.3.
Since the C-API is already used in production, this PR should keep API compatibility at all cost.

The initial design goal of the C-API was to be stable and robust, we want to keep those traits, but also focus on speed and efficiency.

  • allow (pre)loading the shared library with data.
    Note: xtb uses a lot of global variables, which makes the current C-API not thread-safe. (changing this is out-of-scope for this PR)
    • loading parameters to the global storage
    • locking the current parametrisation
    • omp mutex
  • xtb datastructures should be available in C
    • small data structures have an equivalent struct that can be manipulated directly
    • non-C compatible classes have an opaque void* reference that can be manipulated with API functions
    • wavefunction can be queried for charges, bond orders, orbital energies ...
    • verify molecular structure input (prevent cold-fusion, unknown elements)
    • recheck wavefunction and basisset against parametrisation
  • calculation can be performed in an unsafe way, requiring to load parameters and construct xtb objects on the C-site
    • the C-API can validate the state of the shared library and reject calculations
  • The current API wraps loading, locking, acquiring of datatypes and excuting the calculation
  • Improve error handling in scf_module and peeq_module (should fix C-API Error handling #104, requires error handling mechanism using local variables #105)

@awvwgk awvwgk added the C-API Concerns the ISO-C layer label Jan 16, 2020
@awvwgk awvwgk added this to the v6.3.0 milestone Jan 16, 2020
@awvwgk awvwgk self-assigned this Jan 16, 2020
This was referenced Jan 21, 2020
Closed
Merged
Closed
@awvwgk
new C-API implementation
5a19db9 
- make xtb datatypes available as opaque void pointers to C
  - tb_molecule can be created, deleted and updated by API
  - tb_basisset can be created and deleted by API
  - tb_wavefunction can be created and deleted by API
  - global lock can be set by loading a parametrisation via the API
  - lock can be checked, compared and released by API
- unsafe xTB_calculation API call
- Allow query of wavefunction object from API
- make other API calls use the new infrastructure internally
@awvwgk awvwgk merged commit 26dda26 into grimme-lab:master Feb 9, 2020
@awvwgk awvwgk deleted the c-api branch February 9, 2020 21:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@awvwgk awvwgk

Labels
C-API Concerns the ISO-C layer
Projects
None yet
Milestone
v6.3.0
Development

Successfully merging this pull request may close these issues.

C-API Error handling C/C++ Interface Oddities
1 participant
@awvwgk