Comments (7)
On Matt's point. I am also thinking to store the maker/function in the output database. However, it wouldn't be part of the task document itself but one level higher up. E.g., as part of this dict: https://github.com/materialsproject/jobflow/blob/073266cf8a3e9e06abf351a2728a46f159d99f32/src/jobflow/core/job.py#L579-L586
I'd be happy to accept that as a PR :)
from atomate2.
What sort of querying are you thinking about? If you add formulas you can always query using regex matching.
I'm thinking about how builders for smaller research projects typically rely on (not very robust) queries of the tasks database.
This gets compounded a little bit because as people do more dynamic workflows in automate2 they basically have to do custom job names to navigate their own workflows. And the people building the workflows might now be conscious of the query problems they can cause later and then end with a name that is difficult or even impossible to regex.
from atomate2.
It seems like task_label
has been a little overloaded: it's often used to encode the type of calculation, and also a user-readable name.
Perhaps we just need multiple fields? A label (which is just that, a human-readable label, arbitrary), but also store the maker name as a separate field?
from atomate2.
agreed, so I guess this change should happen when the document models move to emmet eh?
I linked this in the other thread.
We should tabulate a list of these things and just do the change once.
from atomate2.
I'm not sure I see the problem. This is also how its done in atomate1. The calculation type is available through task_type
and calc_type
.
This seems to indicate that if the user wants to change the name of a job (ex. adding formulas to the names) it will break subsequent querying of the resulting tasks database.
What sort of querying are you thinking about? If you add formulas you can always query using regex matching.
from atomate2.
@utf so I think the problem here is that self.name
gets modified by things like append_name
which basically indicates that you should change it as part of your workflow. But then gets used by the task document as a stand-in for calc_type
so it's serving two somewhat different functions at the same time which I think is problematic. I think if we assign calc_types
to the different IntputSetGenerator
s and grab that value that should sort everything out automatically right?
from atomate2.
On Matt's point. I am also thinking to store the maker/function in the output database. However, it wouldn't be part of the task document itself but one level higher up. E.g., as part of this dict: https://github.com/materialsproject/jobflow/blob/073266cf8a3e9e06abf351a2728a46f159d99f32/src/jobflow/core/job.py#L579-L586
I'd be happy to accept that as a PR :)
I am in need of this feature to navigate some of my workflows. I'd be happy to implement it if we still think this is what we want? @utf
I see this as a different feature to @jmmshn's comments on Feb 15.
from atomate2.
Related Issues (20)
- Advertising the atomate2 paper writing HOT 66
- Convergence check for relaxation with forcefields
- Dealing with large structures in the phonon workflow for forcefields HOT 5
- BUG: WAVECAR deletion HOT 8
- Discussion: sigma value in NSCF calculation
- BUG: custom CHGNET model in PhononFlow throws `jsanitize` error HOT 27
- BUG:ValueError: dictionary update sequence element #0 has length 1; 2 is required HOT 1
- FEATURE: GW workflow with VASP HOT 4
- BUG: pip install atomate2 does not automatically install phonopy and seekpath HOT 2
- Feature: add an additional step to the LOBSTER workflow to reduce run times
- Improve failed perturbations handling in elastic workflow HOT 1
- Feature: Easy switch between GPU/CPU for forcefields HOT 6
- BUG:Could not resolve reference HOT 3
- MLPs are not working in the test suite HOT 4
- The need for `contextlib.redirect_stdout` for MLFF MD
- Import MP input sets directly from Pymatgen HOT 1
- BUG: `RecursionError` with `VaspMaker.input_set_generator.get_input_set`
- BUG: Potential incompatibility with "old" MP GGA workflow w.r.t. k-points in GGA static calculations HOT 2
- `ElasticMaker` shouldn't use submaker as default factory by design HOT 3
- BUG: Documentation currently does not show all the subpackages and modules available in atomate2
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 atomate2.