Digital Discovery

Article types

Communications

Our Communication format is ideally suited to short studies - which can be preliminary in nature - that are of such importance that they require accelerated publication.

Communications must contain original and highly significant work whose interest to the Digital Discovery readership and high novelty warrants rapid publication. Authors should supply with their submission a justification of why the work merits urgent publication as a Communication. Referees will be asked to judge the work on these grounds.

Communications are given high visibility within the journal as they are published at the front of an issue. Communications will not normally exceed the length of four printed journal pages.

Full papers

Full papers must represent a significant development in the particular field and are judged according to originality, quality of scientific content and contribution to existing knowledge. Authors are encouraged to emphasise the importance and potential impact of the research presented. Although there is no page limit for Full papers, the appropriateness of length to content will be taken into consideration.

Papers describing hardware should focus on the development of open-source scientific hardware advancing the digitalization of chemistry, materials science, or biotechnology. The application of hardware to accelerated discovery should be clearly demonstrated in the manuscript. To enable reuse, a clear license should be provided for the materials and we have a strong preference for open-source hardware licenses, such as the CERN Open Hardware License.

More information about requirements and guidelines for writing a hardware paper can be found in the recently published Editorial.

Reviews & Perspectives

Reviews and Perspectives must be high-quality, authoritative, state-of-the-art accounts of the selected research field. They should be timely and add to the existing literature, rather than duplicate existing articles, and should be of general interest to the journal's wide readership.

All Reviews and Perspectives undergo rigorous peer review, in the same way as regular research papers.

All review content should consist of original text and interpretation, avoiding any direct reproduction. If a significant amount of other people's material is to be used, either textual or image-based, permission must be sought by the author in accordance with copyright law and must be made clear in the manuscript.

Reviews report a detailed, balanced and authoritative current account of the existing state of knowledge on a particular facet of within the field. Reviews may be shorter summaries highlighting important recent developments, or more detailed, balanced accounts, of the selected research field. Simple literature surveys will not be accepted for publication. Reviews should not contain unpublished original research. 

Perspectives present an authoritative state-of-the-art account of a research field. A Perspective may take the form of a personal account of research or a critical analysis of a topic of current interest. In either form, some new unpublished research may be included.

Opinions

Opinions are short, personal viewpoints on a topic of current interest to the community. They can be speculative in nature, and provided that they are not defamatory to the work of others, can be controversial and stimulate counter-opinion. They should contain rigorous, evidence-backed scientific justification, and bring significant and valuable insights to the field.
Opinions are typically three to four pages in length and are published by invitation of the Digital Discovery Editorial Board or Editorial Office. Authors interested in submitting an opinion should contact the Editorial Office at DigitalDiscovery-rsc@rsc.org. Opinions undergo a rigorous and full peer review procedure, in the same way as Full Papers.

Comments

Comments and Replies are a medium for the discussion and exchange of scientific opinions between authors and readers concerning material published in Digital Discovery.

For publication, a Comment should present an alternative analysis of and/or new insight into the previously published material. Any Reply should further the discussion presented in the original article and the Comment. Comments and Replies that contain any form of personal attack are not suitable for publication.

Comments that are acceptable for publication will be forwarded to the authors of the work being discussed, and these authors will be given the opportunity to submit a Reply. The Comment and Reply will both be subject to rigorous peer review in consultation with the journal’s Editorial Board where appropriate. The Comment and Reply will be published together.

Tutorial reviews

Tutorial reviews should provide an introduction and overview of an important topic of relevance to the journal readership. The topic should provide a good introduction to the development of a subject, its current state and indications of future directions the field is expected to take. These reviews can describe the use of modern software tools (such as AI systems and/or hardware control systems) or open hardware designs for chemical synthesis and/or characterization. Tutorial reviews can be aimed at audiences ranging from graduate students to faculty. Tutorial reviews should not contain unpublished original research.

Data and Code Availability

At the Royal Society of Chemistry, we believe that all data associated with research in a manuscript should be Findable, Accessible, Interoperable, and Reusable (FAIR). This principle enables other researchers to replicate and build upon existing work.

Submission Requirements:

Authors are expected to submit both their code and data to community-recognized data repositories, or to a general repository if no community-specific option is available. Referees must have access to the code and data during the peer-review process. Furthermore, to ensure long-term availability, any custom code referenced in the manuscript must be deposited in a persistent repository, such as Zenodo, Code Ocean, or Mendeley, upon acceptance. Authors must also obtain a DOIs for the code and/or data and submit it before publication.

Papers describing hardware should be accompanied by detailed supporting information, including a comprehensive bill of materials and a construction guide. All design files and software code should be hosted in a public, persistent repository, ensuring easy access and longevity of the resources. In addition to any finished products, authors should provide relevant files in editable format. For more information and guidance for writing hardware-focused manuscripts please read through our Editorial.

Industry Contributions:

We acknowledge that proprietary restrictions may apply to industry contributions. If full code cannot be made publicly available, authors must deposit pseudocode that can be openly accessed by readers upon acceptance. Additionally, a binary version of the software must be provided to editors and reviewers for testing, ensuring their anonymity. The Data Availability Statement (DAS) should specify how editors and reviewers can access the proprietary software or custom code.

Data Sharing:

Custom code must be accompanied by the complete dataset used for training and testing. If there are restrictions on the data utilized in the research, a representative dataset that enables similar conclusions to those demonstrated in the manuscript must be made publicly available. Similarly to a custom code, data must also be deposited in a persistent repository, with a DOI provided before publication.

Reporting Changes:

Any removal of code or data must be reported. In extreme cases, if authors fail to notify us of such changes, a note of concern may be published.

Policy on the Use of Large Language Models (LLMs) in Research

LLM Use for Inference

Reproducing results generated by large language models (LLMs) can be challenging due to factors like the stochastic nature of the generation process, commercial limitations, and the associated computational costs. To enhance transparency and facilitate validation of research findings, authors are required to:

• Provide log files that include the inputs and outputs used in their study. This documentation will allow for thorough analysis of the model's behavior and results, ensuring that readers can validate findings without reproducing the entire study.
• Specify the model identifier and generation date when using commercial LLMs. This information is crucial for identifying any changes or updates to the model that could impact reproducibility.

LLM Fine-Tuning

Given the increasing significance of fine-tuning LLMs, we offer the following guidance:

• Researchers who fine-tune open-weight LLM models should share the updated model weights to facilitate replication and further research.
• While we recognize the value of using commercial, closed-source LLMs, authors must make the input files used for fine-tuning publicly available to enable replication of the training process.

Hardware Papers:

Papers that describe hardware must include detailed supporting information, including a comprehensive bill of materials and a construction guide. All design files and software code should be hosted in a public, persistent repository to ensure easy access and longevity. Authors should provide relevant files in an editable format. For more information on our requirements for publishing hardware articles, please read our guidelines.

Data Availability Statements

To uphold high standards of transparency and reproducibility, all research articles submitted to Digital Discovery must include a Data Availability Statement (DAS). This statement should provide links to any code and datasets analysed or generated during the study and shared in external repositories. It must include:

• The name of the database, accession number, DOI, URL, or other relevant details.
• For deposited code, the exact version and date of access to the repository must be noted for future reproducibility.

Code and datasets deposited in a public repository must be formally cited in the reference section of the article. The DAS submitted at acceptance must include DOIs for both the most recent and archived versions of the software or code referenced in the manuscript. We recommend using Zenodo for referencing and citation for code and data deposited on GitHub.

The DAS must be submitted alongside all manuscripts as an accompanying file. Authors are also required to publish their data and/or code in a persistent repository and submit the revised DAS with the DOIs at the acceptance of their manuscript. DAS will be published as part of the articles and can be found by readers following the Conclusions section of the paper.

Examples of Data Availability Statements:

1. The code for [description] can be found at [URL] with [DOI – if available]. The version of the code employed for this study is version XXXX.
2. Data and processing scripts for this paper, including [description of data types], are available at [name of repository] at [URL – format https://doi.org/DOI].
3. This study was carried out using publicly available data from [name of repository] at [URL] with [accession number].
4. The data analysis scripts of this paper are available in the interactive notebook X [Example, Google Collab].
5. As this is a [Review/Perspective article], no primary research results, data, software, or code have been included.

Note: The statement “Data are available upon request from the authors” is not acceptable.