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

Convergence Strategies SCF Workchain #199

Open
janssenhenning opened this issue Nov 10, 2022 · 2 comments
Open

Convergence Strategies SCF Workchain #199

janssenhenning opened this issue Nov 10, 2022 · 2 comments

Comments

@janssenhenning
Copy link
Contributor

The SCF workchain is missing important features for improving the convergence. There is no way of defining strategies, that can make changes to help convergence between fleur runs

The design should be customizable, i.e. users should be able to easily create their own strategies and follow the following workflow (The strategy sees the history of distances and maybe more)

flowchart TB
    Input --> run(Fleur run)
    strat(Convergence Strategy) --> run;
    run --> conv{Converged?};
    conv -- Yes --> End[Finished]
    conv -- No --> change[Ask Strategy for changes]
    change -- Apply changes --> run
@Tseplyaev
Copy link
Collaborator

Tseplyaev commented Nov 12, 2022

I think one can use the BaseRestartWorkChain to implement this behaviour. In this case one would have a second, wrapping BaseSCF WorkChain (similarly to Relax and BaseRelax WorkChains). The BaseSCF WorkChain would inherit from BaseRestartWorkChain. It could detect that the nested SCF WorkChain did not converge charge densities and apply corresponding changes via executing an error handler.

@janssenhenning
Copy link
Contributor Author

This is of course a possibility, but I fear in this case this would not give much benefit over the alternative approach of refactoring the SCF workchain itself to allow it to make more fine-grained choices about changes to the input file. This would not only lead to the workchain code to be much more testable (Atleast with the design I had in mind) and I fear if the BaseRestartWorkChain is employed this could lead to the following situation

When a user needs to change convergence parameters after every fleur calculation, tweaking mixing parameters etc., the SCF workchain itself would become a rather useless layer in between that does nothing except check the convergence, since it performs one fleur call at a time. In addition the error handler approach is rather complicated to understand for normal aiida users so it might discourage them to tweak the convergence strategies to their own liking.

The outline I would have in mind is

  1. Two classes ConvergenceStrategy and ConvergenceHistory. The latter is a dataclass, which acts as the holder of all the distance lists previously in the scf workchain and the former uses this class to make suggestions according to it's strategy. (normal python classes should be able to be assigned to the context as long as their attributes are json serializable)
  2. The ConvergenceStrategy class can be subclassed to customize the behaviour
  3. The outline looks as follows
    spec.outline(cls.start, 
                         cls.validate_input,
                         if_(cls.fleurinpgen_needed)(cls.run_fleurinpgen),
                         while_(cls.condition)(cls.ask_strategy_for_changes,
                                                            cls.run_fleur,
                                                            cls.inspect_fleur,
                                                            cls.get_res), 
                        cls.return_results
    )

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

2 participants