{"id":736,"date":"2023-04-12T12:37:15","date_gmt":"2023-04-12T12:37:15","guid":{"rendered":"https:\/\/blogs.aalto.fi\/catprofopen\/?p=736"},"modified":"2023-09-28T06:01:18","modified_gmt":"2023-09-28T06:01:18","slug":"catalysis-research-group-publishes-diffusion-reaction-model-code","status":"publish","type":"post","link":"https:\/\/blogs.aalto.fi\/catprofopen\/2023\/04\/12\/catalysis-research-group-publishes-diffusion-reaction-model-code\/","title":{"rendered":"Catalysis research group publishes diffusion\u2013reaction model code"},"content":{"rendered":"\n

Written by J\u00e4nis J\u00e4rvilehto (<\/em>https:\/\/linkedin.com\/in\/janisj<\/em><\/a>)<\/em><\/p>\n\n\n\n

The Catalysis research group has published its first-ever open code! Coined DReaM-ALD<\/em>, the recently published Matlab script provides an implementation of a diffusion\u2013reaction model developed by Ylilammi et al.<\/em> (J. Appl. Phys. 123<\/strong>, 205301 (2018), DOI: 10.1063\/1.5028178<\/a>). The model simulates atomic layer deposition in high-aspect-ratio structures and generates saturation profiles, which show how the film thickness evolves with penetration into the structure. This Matlab implementation was originally written by Emma Verkama in 2019 by request of Prof. Riikka Puurunen, and the code was later published by J\u00e4nis J\u00e4rvilehto. In addition to Github<\/a>, the code was also made available on Zenodo<\/a>. <\/p>\n\n\n\n

There was a significant delay (~3 years) between the creation and publication of the code. As there was no prior history of open code in the group, the barrier to publication was relatively high. Questions, such as\u2026<\/p>\n\n\n\n

Where should we publish the code? What kind of information would be useful for a potential user? How does the process work in general? Where do I click???<\/em><\/p>\n\n\n\n

\u2026may arise. While the best practices may seem obvious to a software engineer, generating research code can be a messy affair in other fields. Often, these researchers in other fields are less acquainted with the tools of the trade, such as a version control system like Github. Someone <\/em>in the group <\/em>would have to figure out how and where to publish the code so that it is easily accessible and citable. This causes useful and interesting projects to end up forgotten on university network drives, instead of being available for anyone to extend and experiment with. It is also difficult to replicate the results of a published work without access to the original code. <\/p>\n\n\n\n

As a starting point or inspiration for other groups that are unsure about open code, we\u2019ve summarized the steps we went through to get our code out there. We\u2019ve also linked some helpful resources we\u2019ve run into during the process!<\/p>\n\n\n\n

Step 1: Set up an Organization on Github<\/strong><\/p>\n\n\n\n

If your research group has not published on Github yet, it is a good idea to think about how the repositories should be organized. We opted to create an Organization <\/em>for the research group \u2014 this way the repository\u2019s association with the Catalysis research group is clear. Remember to assign a second Organization Owner<\/em> for your Organization<\/em>, just in case. The other research group members can be added as Organization Members<\/em>. <\/p>\n\n\n\n

Step 2: Decide on a license<\/strong><\/p>\n\n\n\n

Choose a license for the software you intend to publish, if you haven\u2019t already done so. Keep in mind that there may be restrictions on the type of license you can use, set by your organization or funding source. You can find an overview of common licenses at https:\/\/choosealicense.com\/<\/a>, for example. In our case, we opted for the MIT license. <\/p>\n\n\n\n

Step 3: Set up a repository<\/strong><\/p>\n\n\n\n

Next, it is time to set up a repository for the project. There are two paths to take here: either one directly creates the repository to be published later, or, a draft repository can be created first. On Github, all changes to a repository can be traced back, so a potential editing history of, for example, the README.md file will be publicly visible. We decided to forgo the draft repository, as we had already prepared the repository content elsewhere. However, we set the repository to Private <\/em>at this stage. At this point, you can push <\/em>your code and a LICENSE.txt file to the repository. <\/p>\n\n\n\n

Step 4: Create a README.md file<\/strong><\/p>\n\n\n\n

The README.md file is displayed whenever someone visits the repository. You can use the README.md as an opportunity to give a brief description of the project, reference relevant literature, explain how to use the code, and how you would like others to cite it in their work. We also decided to include a DOI badge<\/em>, among others, at the top of the README.md. We used https:\/\/shields.io\/<\/a> to generate the badges (shields<\/em>) for our README.md file. <\/p>\n\n\n\n

Step 5: Make the repository (easily) citable<\/strong><\/p>\n\n\n\n

Anyone can cite the repository as-is, however, there are some things you can do to make it more straightforward. For starters, we included a Citing <\/em>section in our README.md to give an example on how to cite the repository. Furthermore, we created a CITATION.cff file in the root of the repository using cffinit<\/a>. The CITATION.cff file causes Github to display a Cite this repository<\/em> button in the About <\/em>section of the repository, which provides a preformatted citation and BibTeX entry. The file contains citation information in a machine-readable format; you can find further information at https:\/\/citation-file-format.github.io\/<\/a>. <\/p>\n\n\n\n

At this point, we also created a .zenodo.json file for the Zenodo synchronization (enabled in Step 7). This json file is placed at the root of the repository and Zenodo uses it to generate the deposit metadata. There are various fields you can fill out using the .zenodo.json file, a complete list of which can be found at here<\/a>. We also validated our file before pushing it using a json validator, as it is easy to mess up the formatting. <\/p>\n\n\n\n

Step 6: Publish!<\/strong><\/p>\n\n\n\n

Here, the procedure varies slightly depending whether a draft repository was created or not. If you created a draft repository, simply copy its contents to a new, public repository. As we were satisfied with our repository, we simply changed its visibility to Public<\/em>. Now the code is publicly available on Github!<\/p>\n\n\n\n

Step 7: Synchronize the repository with Zenodo<\/strong><\/p>\n\n\n\n

To obtain a DOI for our repository, we archived it as a Zenodo deposit. The most efficient way to achieve this is to connect your Github account to Zenodo, enable synchronization for the repository on Zenodo, and finally create a Release <\/em>on Github. You can find more information on how to connect the accounts on https:\/\/help.zenodo.org\/<\/a>. After this, Zenodo will automatically issue a new versioned DOI <\/em>whenever a new Release <\/em>is created on Github. Notably, this only works if no prior Releases <\/em>have been created before enabling synchronization. After obtaining our first DOI, we decided to update it in the README.md and CITATION.cff files as well. <\/p>\n\n\n\n

Hopefully this blog post has been helpful in condensing the most relevant learnings of the process we went through to get our project published. While the steps may seem convoluted, the whole process should only take a few minutes, provided that the files have been prepared in advance. For further reading on research code, you can check out:<\/p>\n\n\n\n