All notable changes to this project will be documented in this file.
+The format is based on Keep a Changelog, and this project generally adheres to Semantic Versioning.
+Atoms object is sorted when using MP input sets<= version pin on Atomate2 to resolve upstream breaking changepreset: Path type in the Espresso calculatorJobFailure error when a calculation fails, which stores the directory where the files remain as well as the parent errorpreset handlingpreset: Path type in the Vasp calculatoradditional_fields keyword argument to all recipesquasi_irc_job for internal consistencyfrom quacc import get_settings to fetch the current settings on a threadsettings_swap keyword argument that can be passed to the decorators when a workflow engine is used.QuaccSettings could carry over to a concurrent threadSETTINGS variable is gone! Modifying a global variable can cause havoc in multithreaded environments and was never compatible with workflow engines. Refer to the Modifying Settings page for the recommended approach. For most users without an active workflow engine, this will be the with change_settings() context manager.Atoms hashing to work on FIPS-encrypted OSsshear_strain value in quacc.atoms.defects.make_deformations_from_bulk to match that of PymatgenAtoms object in the output schema could get a stray calculator attached to it when passed between @jobsmaster branch of ASEnsteps from the OptSchemaRESULTS_DIR and SCRATCH_DIR settings can now be relative paths, if desiredfailed-quacc-12345- directory to distinguish these tasks from the running tasks in tmp-quacc-12345-loadfn("quacc_results.json.gz") where loadfn is from monty.serialization import loadfnfmax attribute was moved from the base level to the parameters_opt section since it is an input parameterquacc.settings.change_settings, that can be used to modify global settings temporarilyquacc.calculators.vasp.params.MPtoASEConverter to convert between Pymatgen- and Atomate2-style input parameters to ASE-compatabile parametersWORKFLOW_ENGINE, as noted in the docsVASP_MAG_CUTOFF from 0.05 to 0.02preset keyword argument from the QMOF recipespmg_input_set keyword argument from the Vasp calculatortimeout, parsl_resource_specification)Phonopy object based on the unrelaxed, rather than relaxed, structureget_phonopy() calls.json instead of .pcklatoms_info field from the AtomsSchema since this is already available in the database via Pymatgen's MSONAtoms serializationjsanitize once before uploading to the Storegrid_phonon_flowstr type instead of Pathslowconv from the default parameters of the ORCA recipesresults attributecopy_decompress_filesstore_intermediate_results=TrueWRITE_PICKLE setting, which by default, will write out a .pkl file containing the result schema to the directoryruff settingsstatic_job routines do a force calculation by default noworcablocks in ORCA recipesCHDIR settingnon_scf_job for VASPos.chdir calls to ensure thread safetypymatgen.io.ase.MSONAtoms to make MSONable Atoms@task distribution with VASP and Q-ChemState would raise an indexing error when passing around deferred dict entriesjob_parameters and job_decorators are both passed to customize_funcs()ValueError when the user provides SCRATCH_DIR or RESULTS_DIR as a relative path@task distribution with GULP, Espresso, and common phonon flow recipesquacc.schemas.atoms._quacc_sanitize functionos.chdir calls for multithread safetyruff for formatting, replacing the need for black and isortquacc.utils.files.copy_decompress_filescopy_files handling with workflow engines**calc_kwargs in MP flow recipesstore_intermediate_results keyword option to quacc.runners.ase.run_opt() to allow for storing of the logfiles in intermediate geometry optimization steps.FIRE to BFGS for most recipesDoubleRelaxSchema to be consistent between flowsdir_name in VASP output schemaNone now works as expectedPRIMARY_STORE setting has changed to STORE and is now formatted more intuitivelyblackMontyStore as the data store optionsupercell_matrix keyword argument to the phonon recipes.seekpath dependency is now required for phonon workflows, as reflected in the quacc[phonons] optional dependenciesmin_length: float | None keyword argument in phonon flows to min_lengths: float | tuple[float, float, float] | None for greater flexibility. The default value is now set to 20.0 instead of 15.0 as well.ValueError in generating the RunSchemadispersion=Truecommon_phonon_flow to accept new keyword arguments that enable symmetry reduction. A pre-relaxation step is now also carried out by default.ONETEP_CMD setting to be str instead of Path when used to instantiate the calculatorgrid_phonon_flowStructure info in the RunSchemaCREATE_UNIQUE_DIR setting is now set to True by default.OptSchema to be list[Atoms] instead of list[AtomsSchema]@job runs now has a name consistent with the folder where the results will ultimately be stored.OptSchemakpts as list[float] instead of list[int]CHECK_CONVERGENCE global setting when set to Falsekpts was None but kspacing was not Nonecovalent_to_db functiongrid_phonon recipe in Espresso (@tomdemeyere)WARNING to INFOphonon_flow when using the master branch of ASEtyper depenendecy in pyproject.toml to be typer[all] like it was supposed to belist[str] input argument format instead of a dict format when overriding defaultsase_relax_job for ORCArelax_job and post_processing_job for Quantum Espressoquacc.wflow_tools.customizers.strip_decorator and quacc.wflow_tools.customizers.redecorate are imported in the base __init__.py for easy user accessquacc.Remove is recommended in place of Nonequacc.wflow_tools.customizers.strip_decorator function is recommended instead of calling .__wrapped__.compute()quacc.wflow_tools.customizers module to aid in customizing pre-made recipes.fmax for quacc.recipes.mlp.core.relax_job to 0.05.quacc.utils.dicts.merge_dicts function to ._recursive_dict_pair_merge to better reflect its functionality.quacc.utils.dicts.merge_several_dicts function to .recursive_dict_merge to better reflect its functionality.~/ throughout quacc file handling mechanismscopy_decompress_files_from_dir was run in the current working directory.WORKFLOW_ENGINE quacc setting now accepts None.DEBUG quacc setting as been added.functools.partial() instead of kwargs. See the updated documentation.quacc.utils.files.copy_decompress_files_from_dircopy_files kwarg in most recipes can now include a directoryquacc.utils.files.copy_decompress to quacc.utils.files.copy_decompress_files~/ expanded in most casesDask workflow engine via Dask Delayed and Dask Distributed.CREATE_UNIQUE_WORKDIR to CREATE_UNIQUE_DIR to better reflect its utility.SCRATCH_DIR setting is now None instead of ~/.quacc_scratch. In other words, the default is to not use a scratch directory. This should help with onboarding, and the ability to set it as None may be broadly of interest. Setting the SCRATCH_DIR to a given Path will still work as expected.SCRATCH_DIR to RESULTS_DIR. Instead, they are recursively moved. This should speed up I/O operations.phonopy_kwargs keyword argument in quacc.recipes.common.phononsauto_kpts kwarg in the Vasp calculator to pmg_kpts_base.py module when appropriateAtoms arg from the calc_setup functionqchem_internal_relax_jobquacc.recipes.common, including quacc.recipes.common.slabs, quacc.recipes.common.defects, and quacc.recipes.common.phononsquacc.schemas.phononscalc_swaps: dict approach, additional parameters can be specified via the **kwargs. In practice, this means in recipes you can do scf = "diis", max_steps=100 instead of calc_swaps={"scf":"diis", "max_steps":100}, for instance.quacc.runners.calc to quacc.runners.asequacc.runners.prep to quacc.schemas.prepquacc info command-line argument for error reportingPath-based settings have .expanduser() appliedMaxSccIterations set to 200 by defaultkpts=None for structures with PBCsAtoms instead of Atoms | dict as inputfetch_atomsfetch_atoms functioncalc_swaps.VibThermoSchema that merges the VibSchema and ThermoSchema as a conveniencefreq_job and lj freq_job now use VibThermoSchema as the outputSCRATCH_DIR from Path.cwd() / ".scratch" to Path("~/.scratch")symprec=1e-8 to the default parameters of VASP relaxation jobs.None.None.quacc.utils.atoms/.slabs/.defects into quacc.atoms.core/.slabs/.defectsquacc.custodian to quacc.calculators.custodianquacc.utils.thermo.ideal_gas to quacc.builders.thermo.run_ideal_gasquacc.schemas.ase.summarize_thermo to quacc.schemas.ase.summarize_ideal_gas_thermoSCRATCH_DIR from /tmp to Path.cwd() / .scratch[optimizers] extras to [sella]quacc.utils.wflows into quacc.wflow_tools.decorators and quacc.wflow_tools.prefectquacc.utils.db into quacc.wflow_tools.dbquacc.utils.calc to quacc.runners.asequacc.presets to quacc.calculators.presetsRESULTS_DIR and SCRATCH_DIR paths when they contain ~RESULTS_DIR == SCRATCH_DIR since this is redundantRESULTS_DIR or SCRATCH_DIR are not present, they will be automatically madefreq_job recipe in Q-Chem (@samblau)LREAL = False in VASP BulkSet.yamlPath objects everywhere possible.make_slabs_from_bulk instead of make_max_slabs_from_bulklogging module when warnings do not need to be immediately addressed.make_max_slabs_from_bulk function.Vasp calculator.BulkSet.yaml in accordance with recent MP benchmarking (#849).fetch_atoms to quacc.schemas.mp_metagga_relax_flow to use a @flow decorator instead of @job@job instead of two.run_kwargs to the .run() method of the ASE optimizers.ct.dispatch when launching Covalent workflows.quacc.util to quacc.utilsWORKFLOW_ENGINE setting can now be set dynamically, as expected.pyproject.toml to better handle pip installs.relax_cell to be False by default for all recipes.SIGMA and ISMEAR in MPScanSet to match the new values to be used in Atomate2.WORKFLOW_ENGINE, to set the workflow manager.covalent-hpc-plugin in pyproject.toml.@job, @subflow, or @flow decorators to be workflow engine-agnostic.quacc package to be dependency-light.setups_pbe54.yaml.quacc.recipes.emt.jobflow and quacc.recipes.emt.prefect to quacc.recipes.emt._jobflow and quacc.recipes.emt._prefectLMAXMIX based on the Z value, not the s/p/d/f-block type.LMAXTAU to 8 for f-containing elements in Vasp calculator.quacc.recipes.emt.parsl since it is now obsolete.quacc config command-line option.PRIMARY_STORE quacc setting that, when specified, will automatically store all results in the specified Maggma store.quacc.schemas.cclib.summarize_run.RESULTS_DIR, which defaults to the current working directory.uks for unrestricted calculations instead of uhf.quacc.wflow_tools module.slab_relax_electron/slab_relax_app to just slab_relax regardless of workflow manager.CHANGELOG.md file.quacc.recipes.emt.parsl module.quacc along with a quacc config option to configure Covalent appropriately upon install.CREATE_UNIQUE_DIR global setting to have quacc automatically make a unique working directory for each calculation.CHECK_CONVERGENCE to global settings.quacc directory is now found in a src basefolder.Atoms object being passed in as an AtomsSchema.slab_relax_job kwarg in recipes.emt.slabs and recipes.vasp.slabs workflows can no longer be set to None, as there are few situations where this would be desired.quacc.recipes.vasp.jobflow module to prioritize Covalent and Parsl.See https://github.com/quantum-accelerators/quacc/releases/tag/v0.1.0 for more details.
+See https://github.com/quantum-accelerators/quacc/releases/tag/v0.0.6 for more details.
+See https://github.com/quantum-accelerators/quacc/releases/tag/v0.0.5 for more details.
+See https://github.com/quantum-accelerators/quacc/releases/tag/v0.0.4 for more details.
+See https://github.com/quantum-accelerators/quacc/releases/tag/v0.0.3 for more details.
+See https://github.com/quantum-accelerators/quacc/releases/tag/v0.0.2 for more details.
+See https://github.com/quantum-accelerators/quacc/releases/tag/v0.0.1 for more details.
+ + + + + + + + + + + + + + + + +We as members, contributors, and leaders pledge to make participation in our +community a harassment-free experience for everyone, regardless of age, body +size, visible or invisible disability, ethnicity, sex characteristics, gender +identity and expression, level of experience, education, socio-economic status, +nationality, personal appearance, race, caste, color, religion, or sexual +identity and orientation.
+We pledge to act and interact in ways that contribute to an open, welcoming, +diverse, inclusive, and healthy community.
+Examples of behavior that contributes to a positive environment for our +community include:
+Examples of unacceptable behavior include:
+Community leaders are responsible for clarifying and enforcing our standards of +acceptable behavior and will take appropriate and fair corrective action in +response to any behavior that they deem inappropriate, threatening, offensive, +or harmful.
+Community leaders have the right and responsibility to remove, edit, or reject +comments, commits, code, wiki edits, issues, and other contributions that are +not aligned to this Code of Conduct, and will communicate reasons for moderation +decisions when appropriate.
+This Code of Conduct applies within all community spaces, and also applies when +an individual is officially representing the community in public spaces. +Examples of representing our community include using an official e-mail address, +posting via an official social media account, or acting as an appointed +representative at an online or offline event.
+Instances of abusive, harassing, or otherwise unacceptable behavior may be +reported to the community leaders responsible for enforcement. +All complaints will be reviewed and investigated promptly and fairly.
+All community leaders are obligated to respect the privacy and security of the +reporter of any incident.
+Community leaders will follow these Community Impact Guidelines in determining +the consequences for any action they deem in violation of this Code of Conduct:
+Community Impact: Use of inappropriate language or other behavior deemed +unprofessional or unwelcome in the community.
+Consequence: A private, written warning from community leaders, providing +clarity around the nature of the violation and an explanation of why the +behavior was inappropriate. A public apology may be requested.
+Community Impact: A violation through a single incident or series of +actions.
+Consequence: A warning with consequences for continued behavior. No +interaction with the people involved, including unsolicited interaction with +those enforcing the Code of Conduct, for a specified period of time. This +includes avoiding interactions in community spaces as well as external channels +like social media. Violating these terms may lead to a temporary or permanent +ban.
+Community Impact: A serious violation of community standards, including +sustained inappropriate behavior.
+Consequence: A temporary ban from any sort of interaction or public +communication with the community for a specified period of time. No public or +private interaction with the people involved, including unsolicited interaction +with those enforcing the Code of Conduct, is allowed during this period. +Violating these terms may lead to a permanent ban.
+Community Impact: Demonstrating a pattern of violation of community +standards, including sustained inappropriate behavior, harassment of an +individual, or aggression toward or disparagement of classes of individuals.
+Consequence: A permanent ban from any sort of public interaction within the +community.
+This Code of Conduct is adapted from the Contributor Covenant, +version 2.1, available at +https://www.contributor-covenant.org/version/2/1/code_of_conduct.html.
+Community Impact Guidelines were inspired by +Mozilla's code of conduct enforcement ladder.
+For answers to common questions about this code of conduct, see the FAQ at +https://www.contributor-covenant.org/faq. Translations are available at +https://www.contributor-covenant.org/translations.
+ + + + + + + + + + + + + + + + +Quacc was originally designed and developed by Andrew S. Rosen.
+The currently active maintainers are as follows:
+ +Additional contributions were made by the individuals listed here. Their contributions are summarized below.
+Add Your Name!
+Don't see your name and want to update the list? Submit a PR and update this documentation page!
+Quacc was originally inspired by Atomate2, developed by Alex Ganose.
+ + + + + + + + + + + + + + + + +Q: How do I pronounce quacc?
A: Like the sound a duck makes: "quack!"
+Q: What's the philosophy behind quacc?
+A: This is a big question. I'll explain with some points that were on my mind when I made it:
+Everyone's computing needs are different, which means not everyone is going to want to use the same workflow engine. This has historically hindered the widespread adoption of prior computational materials science libraries and makes it difficult to share workflows with others. quacc supports several workflow engines out-of-the-box using largely the same syntax, and you can pick your favorite (or use none at all).
+We should leverage tools that are widely used in the community. Python packages like ASE and Pymatgen are staples in the computational materials science community. Rather than reinvent the wheel, quacc takes advantage of what is already out there and — crucially — makes them play nicely together.
+Developers should be able to focus on the science, not the workflow architecture. Many similar packages have the science closely intertwined with the workflow logic. This makes it difficult to write new workflows without learning the intricacies of the workflow stack. quacc solely relies on the use of function decorators that make it easy to transform typical functions into ones that are workflow-ready.
+An overeliance on classes and inheritance can be confusing at the expense of conciseneess. I love classes, but in a computational materials science library, too much class inheritance can make it difficult to track down what parameters are getting set where. Students are also less familiar with classes and may have a difficult time in understanding how they work. The recipes in quacc take a more direct and familiar functional programming approach.
+And last but not least, I'm opinionated. quacc represents choices that I think make the most sense for my group and me. Hopefully they make sense for you too.
+Q: Which workflow management system should I use?
+A: Good question! Check out the Workflow Engines Overview Guide for a comparison of several common options to see which might be best for you.
+Q: Why is quacc better than InsertMyFavoriteCode?
A: Better is all in the eye of the beholder. If you are happy with the tools you are using, my goal is not to convince you to switch. That said, if you find that writing high-throughput computational workflows has a huge learning curve or simply takes too much time away from your science, then quacc may be for you.
+Q: Do you have any tips for writing new workflows?
+A: When developing new workflows, I strongly recommend writing an initial draft based on a low-cost ASE calculator like EMT or LJ, which will allow you to test on your local machine with fast turnaround. Also try to keep things modular. Trying to do too much in one function can make it difficult to debug.
Q: How is quacc different than just using the Atomic Simulation Environment (ASE)
+A: quacc is designed to supercharge ASE for the efficient design of high-throughput workflows. Quacc makes it possible to easily design complex ASE workflows that can be run on heterogeneous compute environments with modern workflow managers, such as Covalent and Parsl. Quacc also makes it possible to combine ASE with the powerful Materials Project software stack, such as Custodian for on-the-fly error handling. For the database enthusiasts, quacc is interoperable with Maggma to store calculation results in a readily queryable format like MongoDB.
+Q: How is quacc different than Atomate2?
+A: Atomate2 is a fantastic code that can be used to run libraries of computational materials science workflows. Quacc was originally inspired by Atomate2 and can be thought of as a "sister code" to it. That said, there are several important differences.
+In Atomate2, workflows are built around the Materials Project software stack and can be cumbersome to interface with the Atomic Simulation Environment (ASE). In contrast, quacc was built around ASE from the ground up while still making it possible to leverage much of the software underlying the Materials Project. Since quacc is built around ASE, it is also trivial to add new recipes based on any code that has an existing ASE Calculator even if it is not in quacc yet.
+Atomate2 is built around Jobflow. Quacc is largely workflow engine-agnostic and has out-of-the-box support for numerous workflow codes, including but not limited to Jobflow.
+Atomate2 is often used as a database-first approach to materials science workflows. Quacc is fully compatible with the use of databases but only emphasizes their use for experts, with the goal of reducing the barrier to getting started.
+Atomate2 is developed and supported by the Materials Project team at Lawrence Berkeley National Laboratory. Quacc is developed and maintained by the Rosen Research Group at Princeton University.
+Q: I want to contribute a new recipe to quacc, but it will require additional dependencies. Is that a problem?
+A: Absolutely not a problem! Simply make your dependencies optional in the pyproject.toml file and use a monty.dev.requires decorator to ensure your recipes and tests only run if your necessary dependencies are installed. Refer to quacc.recipes.tblite.core and the [tblite] extras in the pyproject.toml file for an example.
BSD 3-Clause License
+
+Copyright (c) 2025, Andrew S. Rosen.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+- Redistributions of source code must retain the above copyright notice, this
+ list of conditions and the following disclaimer.
+
+- Redistributions in binary form must reproduce the above copyright notice,
+ this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+
+- Neither the name of the copyright holder nor the names of its
+ contributors may be used to endorse or promote products derived from
+ this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+