Comments (9)
SimpleNamespace
I don't know what this is, I trust your decision here :-)
It's basically the same as the AiiDA AttributeDict
, except without recursively modifying mappings: see the docs.
What about naming? Should the default be at top-level qe_tools.CONSTANTS? Or qe_tools.constants.DEFAULT?
Maybe let's go with
qe_tools.CONSTANTS
as a pointer toqe_tools.constants.DEFAULT
?
Hm, I think it would make sense to keep the qe_tools.constants.DEFAULT
private (e.g., make it qe_tools._constants
) for now - so it's fine even if we never need to introduce the versioning.
from qe-tools.
Should we address this before 2.0? As far as I can see, this comment by @giovannipizzi is the latest suggestion.
Questions on this:
- Is
ry_to_ev
andry_si
the only inconsistency, or are there others? Probably we should just check all the constants are consistent? Or should we just do whatever QE does, even if it's inconsistent there? - Do the constants tend to change between QE versions? We could use the QE-versioning code we have now to distinguish these.
I don't think there's much of a point in tracking also the CODATA values - they are defined in scipy.constants.
from qe-tools.
I am not sure - I guess we need to check inconsistencies, and double check with QE.
Considering the scope of this library, I would indeed track them with the QE version - we'll probably need to do some git blaming in GitLab to see if/when constants were changed in QE...
from qe-tools.
Fun!
For the release candidate, at the very least I think we should nail down the interface. How about we have a get_constants(qe_version: Optional[str]) -> Dict[str, float]
function for the general case, and then simply
DEFAULT = get_constants()
for the latest ones?
from qe-tools.
seems reasonable!
from qe-tools.
Anyway, maybe we should just create a default interface, but in the end it might not be needed to create multiple versions?
Here is the blame: https://gitlab.com/QEF/q-e/-/blame/qe-6.5/Modules/constants.f90
and the history: https://gitlab.com/QEF/q-e/-/commits/qe-6.5/Modules/constants.f90
No "real" change (apart for additions of new constants, often derivatives with just a 10^X factor, or, minor irrelevant code changes to that file) happened in the past 12 years, where some constant precision was increased: https://gitlab.com/QEF/q-e/-/commit/a82ffc4c2948ac82c7978898e1ac4b7e99abdf2e
So maybe I wouldn't worry too much about this issue.
The only action I'd take are:
- make sure the constants we use are identical to the ones internal to QE; write this in a comment, saying that we checked it and when, and they haven't changed in the past 12 years
- if not complex, make it easy to have multiple versions in the future. But if it makes everything more complex, let it go...
Then, ensure in aiida-qe we use constants from here for consistency
from qe-tools.
So.. we just pack the constants into a SimpleNamespace
to make sure we can make multiple instances if needed?
What about naming? Should the default be at top-level qe_tools.CONSTANTS
? Or qe_tools.constants.DEFAULT
? The latter makes more sense if there are different versions, but since there probably won't be I'm not sure which option is better.
from qe-tools.
SimpleNamespace
I don't know what this is, I trust your decision here :-)
What about naming? Should the default be at top-level qe_tools.CONSTANTS? Or qe_tools.constants.DEFAULT?
Maybe let's go with qe_tools.CONSTANTS
as a pointer to qe_tools.constants.DEFAULT
?
from qe-tools.
Related Issues (20)
- Exponentially-slow regex HOT 2
- Problem when encountering comments HOT 1
- dictionary problem with k_points
- Wrong alat used if ibrav != 0 HOT 1
- Missing 'valid_ibrav' values in get_cell_from_parameters HOT 4
- Drop py2 support? HOT 10
- ibrav -13 is incorrect HOT 3
- Clearly define public vs. private interface HOT 8
- Structure of Qe/Pw/CpInputFile HOT 5
- Add (minimal) documentation build
- Check and update docstrings
- Add README as long_description in setup.py
- When set qetools as the parser for qeinputgenerator, the generated input file for pwscf always use this setting: calculation = 'scf'. HOT 5
- Update or pin pytest-cases
- Parsing PW input file HOT 4
- Empty line after ATOMIC_SPECIES makes the parser fail HOT 1
- Move CI from Travis to GHA
- Drop Python 3.5 compatibility, add Python 3.9 to test matrix
- Constructing cell from parameters
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from qe-tools.