Skip to content
This repository has been archived by the owner on Jul 5, 2020. It is now read-only.

Refactor PB-AM to be more usable as a library #7

Open
erikjensen opened this issue Aug 28, 2015 · 0 comments
Open

Refactor PB-AM to be more usable as a library #7

erikjensen opened this issue Aug 28, 2015 · 0 comments

Comments

@erikjensen
Copy link
Collaborator

Right now, the code assumes that it only ever runs once. There is a very large amount of global state, including dynamically allocated arrays that are never freed. This means that when using the code as a library, only one calculation at a time can be performed at the same time. Additionally, performing more than one calculation over the course of the process results in leaked memory (as memory is allocated for each calculation and never freed.

Furthermore, the API still has the same basic interface as the command-line tool. This means that you have to give it a input PQR file name and an output file name. It would be convenient if it were more flexible as to how to input an output data. (E.g., if you already have protein data in memory, it would be nice to pass that data directly without needing to write it to a file, first.)

Steps for improving the API:

  • Refactor all global state. Some may be convertible to non-static data on it's respective class, but a lot of state needs to be shared between all instances of multiple classes within a run. This will need to be pulled into one or more new run-state classes, which will be constructed for each run and shared by all of the objects within the run.
  • Ensure that all dynamically allocated memory is properly freed.
  • Separate file reading, parsing, and calculation so the caller can pass already loaded or already parsed protein data.
  • Similarly for output: provide a way to pass the results back to the caller instead of only having the option of writing them to a file.
  • Audit standard output. Any useful information should be returned to the caller, and any diagnostic/progress information should be optional.
  • Allow calculation to be performed in stages, as useful. There are eight different calculations that can be performed, with various parameters, and they probably have stages in common. It would be nice to be able to perform the common steps only once if performing multiple calculations on the same data.
@sobolevnrm sobolevnrm added this to the APBS 2.0 integration milestone Aug 30, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants