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.

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

Improve Usability #62

Open
kimt33 opened this issue Apr 5, 2018 · 10 comments
Open

Improve Usability #62

kimt33 opened this issue Apr 5, 2018 · 10 comments

Comments

@kimt33
Copy link
Collaborator

kimt33 commented Apr 5, 2018

Following changes are proposed for improving usability and ease of development

  • a script for running "main" calculations
  • a script for generating the code for running a calculation
  • remove dtype attribute in BaseWavefunction
  • split off cache functions (_olp and _olp_deriv) within load_cache of wavefunction classes to outside (for ease of testing) and wrap these functions within load_cache to remove self from parameters.
  • store parameter shape/size as an attribute rather than relying on template_params? add param shape and size as properties that depend on template_params (and overwrite if desired)?
  • wrap OneRefApprox around geminal instances rather than using multiple inheritances
  • rename wavefunction class names and organize structures
@kimt33
Copy link
Collaborator Author

kimt33 commented Apr 7, 2018

  • move memory handling to later part of code (schrodinger equation or solver)

@kimt33
Copy link
Collaborator Author

kimt33 commented Apr 12, 2018

  • more intuitive/conventional Slater determinant convention
  • docstring/documentation

@kimt33
Copy link
Collaborator Author

kimt33 commented May 13, 2018

@kimt33
Copy link
Collaborator Author

kimt33 commented May 13, 2018

@kimt33
Copy link
Collaborator Author

kimt33 commented May 13, 2018

@kimt33
Copy link
Collaborator Author

kimt33 commented May 13, 2018

@kimt33
Copy link
Collaborator Author

kimt33 commented May 13, 2018

@kimt33
Copy link
Collaborator Author

kimt33 commented May 13, 2018

@kimt33
Copy link
Collaborator Author

kimt33 commented May 13, 2018

@kimt33
Copy link
Collaborator Author

kimt33 commented May 13, 2018

kimt33 added a commit that referenced this issue Jun 22, 2018
1. Parameters are assumed to be given as a flattened array where the
   first matrix has the shape (4, 1, ndim), last matrix has the shape
   (4, ndim, 1) and the rest have the shape (4, ndim, ndim), where ndim
   is the selected dimension.
2. Methods, `get_occupation_indices`, `get_matrix_shape`, `get_matrix_indices`,
   `get_matrix`, and `decompose_index`, have been added to navigate
   the different tensors from the flattened parameter. Should a
   different parameter structure be used, only these methods should be
   changed.
3. `_olp` and `_olp_deriv` have been separated out of the `load_cache` in
   anticipation of usability improvements (Issue #62)

Issues
1. `assign_params` and `load_cache` can be moved to the parent class
kimt33 added a commit that referenced this issue Jul 1, 2018
What:
 1. Move out _olp and _olp_deriv as a method of BaseWavefunction
    (rather than functions hiding inside method _load_cache)
 2. Remove creation of _cache_fns upon initialization
 3. Remove creation of _cache_fns in load_cache
 4. Prevent clearing cache when _cache_fns does not exist
 5. Improve coverage of BaseWavefunction
 6. Modify docstrings for clarity
Why:
 1. Easier to document and to read. Unit testing will be easier. Can
    remove repeated code.
 2. Because not all wavefunctions will need to cache overlaps
 3. Because consistency
 4. Causes errors (especially since _cache_fns does not always exist)
kimt33 added a commit that referenced this issue Jul 1, 2018
What:
1. Turn params_shape into an abstract property
2. Use params_shape instead of template_params to compute nparams in
   BaseWavefunction
3. Use nparams in BaseWavefunction.load_cache instead of params.size
4. Move around tests
Why:
1. Every time param_shape is called, template_params needs to be
   constructed. For most wavefunctions, this is not a big problem, but
   some wavefunctions actually need to do a fair bit to obtain a
   template (e.g. APr2G). The consistency between params_shape and
   template_params will be checked implicitly through assign_params,
   which checks that the given parameters has the same shape as the
   params_shape.

Fix up BaseWavefunction.nparams
kimt33 added a commit that referenced this issue Jul 2, 2018
Can be used to generate arbitrary examples (within the scope of the
script).

What:
 1. Add script for generating code that would run calculations.
Why:
 1. Useful for making examples. Can be treated as an "input" to the
    calculations.
kimt33 added a commit that referenced this issue Jul 2, 2018
What:
 Add script for running calculations.
Why:
 Since `wfns_make_script.py` already produces a script for running the
 calculations, the script is produced as a string then executed to run
 calculations.
 We could've hacked into the stdout to get the script as a string or saved
 to a temporary file, but it was easier to add an extra functionality to
 `wfns_make_script` to return a string which then gets executed.
kimt33 added a commit that referenced this issue Aug 8, 2019
1. Parameters are assumed to be given as a flattened array of matrices
   of shape(nelec, nspin)
2. Denominators are differentiated from numerators by with attribute
   `numerator_mask`
3. Methods, `get_columns`, `get_matrix`, and `decompose_index`, have been added
   to navigate the different matrices from the flattened parametered.
   Should a different parameter structure be used (e.g. each matrix
   having different shape from (nelec, nspin)), then only these methods
   need to be changed.
4. `_olp` and `_olp_deriv` have been separated out of the load_cache in
   anticipation of usability improvements (Issue #62)

Issues:
1. `load_cache` will need to move to the base parent class
2. `assign_params` is redundant (and can move to the parent class)
3. `np.logical_not` was used instead of the unary operator `~` or `-`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant