zhubonan / aiida-castep Goto Github PK

Should make a too for quickly investigate relaxations, concatenate the history and present a single trajectory for the entire run.

At the moment each group can only contain one type of PP, despite that the CastepCalculation can handle a mixture of pseudopotentials types. The limitation can be lifted by creating a unified pseudopotential upload interface at the Data object level. A new type string may be created for this kind of mixed pseudopotential families.

The tutorials for deploying calculations using CastepBaseWorkChain and CastepRelaxWorkChain are missing. They should be added to the online documentation.

AiiDA core has a reference implementation of the BaseRestartWorkChain:

https://github.com/aiidateam/aiida-core/blob/develop/aiida/engine/processes/workchains/restart.py

The CastepBaseWorkChain implemented here in the plugin was based on an eariler version of this, but the exact implementation has now diverged to some extended. It allows handling some common errors such ionic relaxation convergence, out of walltimes and electronic convergence issues.

It would be useful to refector and make CastepBaseWorkChain inherit from BaseRestartWorkChain. Similar work has been done for the aiida-vasp plugin previously.

The advantage of the BaseRestartWorkChain is that it provides a framework for handling restarts as well as allowing customising the "handlers" at individual run level.

aiida-pseudos provides an interface for downloading and managing pseudopotentials.

CASTEP supports UPF format, and the UpfFamily should be supported already. This allows the pseudo-dojo potentials (NCP) to be used by CASTEP, in theory.

Should investigate the status of this, wether it is indeed supported and properly document it.

related to: #8

Migrate the repository from https://gitlab.com/bz1/aiida-castep/. The following steps are needed:

• Migrate the CI/CD
• Check all issues are copied over
• Change project url in the metadata and setup.json
• Archive the old project
• Propagate change in the next release

Allow multiple repository pass to be passed in the environmental variable.

For example:

export MOCK_CODE_BASE=<path>:$MOCK_CODE_BASE

Also, since aiida-castep might not be the only plugin that uses this funtionality (e.g. having aiida-castep and aiida-vasp both installed), the environmental variable should be probably be renamed as CASTEP_MOCK_CODE_BASE.

Scanning repository of codes does not make any sense.

Should check with aiida-vasp and aiida-quantumespresso and others how to test WorkChains

This should not be too hard - check the latest AiiDA team toolkit and update the ci specification.

metadata.options contains the information regarding the operation of the CastepCalculation. Two approaches may be used:

1. Expose the input port from CastepCalculation. This enables automatic checking and tab completion, but renders get_builder_restart difficult to use for CastepBaseWorkChain.
2. Wrap everything in the Dict. This is the way VaspWorkChain handles it. It allows get_builder_restart to be used. However, any problem with the options supports.

The plan was to migrate from 1 to 2, but 2 is not really good as it does not use the mechanism in aiida-core - so more like a workaround. The key problem is the metadata.options is a non-db input, e.g. plain python dictionary, but it is needed for creating a workchian level restart builder.

The alternative is to implement custom methods for performing the restart. However, it is not possible to, in general, recover the metadata.options from the called calculations, but cause what was stored may be the results from modifications.
To support 1., CastepBaseWorkChain can implement a method to store the metadata.options inside the extras of the underlying WorkChainNode. This way, the original inputs may be recovered for manual restart.

The plugin detects the err files in the calculation folder and consider the calculation to be failed if they exist.
However, an err file may still be there is CASTEP detected an error but recovered it itself.
In this case, the calculation should not be treated as failed.

Example content of the file:

Warning, Castep has detected a problem with your maths libraries (LAPACK).
Attempting to work around the problem...
(Information for developers: zheevr diagonalisation error  0.727E-02; zheev error -0.247E-13; Hermitian error:  0.684E-15)
Work-around was successful, continuing with calculation.

When I run (locally) the tests for the aiida-common-workflows, I get this:

_______________________________________ ERROR collecting tests/workflows/relax/test_castep.py ________________________________________
ImportError while importing test module '/Users/pizzi/git/aiida-common-workflows/tests/workflows/relax/test_castep.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/local/opt/[email protected]/Frameworks/Python.framework/Versions/3.8/lib/python3.8/importlib/__init__.py:127: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
tests/workflows/relax/test_castep.py:11: in <module>
    from aiida_castep.data.otfg import OTFGGroup
../../.virtualenvs/aiida-dev/lib/python3.8/site-packages/aiida_castep/data/__init__.py:8: in <module>
    from .otfg import OTFGData
../../.virtualenvs/aiida-dev/lib/python3.8/site-packages/aiida_castep/data/otfg.py:11: in <module>
    from .usp import UspData
../../.virtualenvs/aiida-dev/lib/python3.8/site-packages/aiida_castep/data/usp.py:9: in <module>
    from aiida.orm import GroupTypeString
E   ImportError: cannot import name 'GroupTypeString' from 'aiida.orm' (/Users/pizzi/git/aiida-core/aiida/orm/__init__.py)

that seems to come from your code.
Can you please fix it (if not done already)?

(AiiDA version 1.6.2, aiida-castep==1.2.0a5)

Need to update the return codes to comply with the latest AiiDA specification:

• 0 - 99: Reserved for internal use by aiida-core
• 100 - 199: Reserved for errors parsed from scheduler output of calculation jobs (note: this is not yet implemented)
• 200 - 299: Suggested to be used for process input validation errors
• 300 - 399: Suggested for critical process errors

Consider updating all processes.

The parser may break when iprint is > 1 causing the calculation in PARSINGFAILED state.
More robust methods should be implemented to separate SCF cycles and parse lines containing total energy and forces.

In particular, phonon calculations does not print much of the progress/force constants so the user may want to run with iprint=2 by default.

Test status with iprint = 2:

• singlepoint
• geometrt optimistaion
• phonon
• spectral
• bandstructure
• magres

The current parser should still work with iprint > 1, but it is not tested. It can get confused because more stuff are printed out.

CASTEP reports multipe eferemi for spin polarised systems. This should be handled properly.

CASTEP will displace the atoms as [SPECIES]:[LABEL] in both the castep file and geom file. These names should be parsed into element and kind names by the parser.

At the moment, calculation with tags (e.g kindname != symbol) will fail when trying to parse geometry optimisation results.

At the moment this is used as the internal options, and in fact not passed to the actual calculation's metadata.options.
Should consider using this port for passing the metadata.options to the calculation for consistent restart behaviour.

Perhaps any field for metadata.options can be looked up and updated it is defined here.