PFHub: The Phase-Field Community Hub

Daniel Wheeler1, Trevor Keller1, Stephen J. DeWitt2, Andrea M. Jokisaari3, Daniel Schwen3, Jonathan E. Guyer1, Larry K. Aagesen3, Olle G. Heinonen4, Michael R. Tonks5, Peter W. Voorhees6 and James A. Warren7 1 Materials Science and Engineering Division, Material Measurement Laboratory, National Institute of Standards and Technology, Gaithersburg, MD, US 2 Materials Science and Engineering Department, University of Michigan, Ann Arbor, MI, US 3 Fuel Modeling and Simulation Department, Idaho National Laboratory, Idaho Falls, ID, US 4 Argonne National Laboratory, Lemont, IL, US 5 Department of Materials Science and Engineering, University of Florida, Gainesville, FL, US 6 Department of Materials Science and Engineering, Northwestern University, Evanston, IL, US 7 Material Measurement Laboratory Office, Material Measurement Laboratory, National Institute of Standards and Technology, Gaithersburg, MD, US Corresponding author: Daniel Wheeler (daniel.wheeler@nist.gov)


Introduction
Generally, small scientific communities do not have the resources to build and host dedicated web infrastructure to support their varied content and data requirements. In particular, hosting and supporting a complex content management system (CMS) including web servers, web frameworks and databases requires a great deal of configuration and long term support and funding. Furthermore, a turnkey CMS solution may not meet requirements for most scientific communities that often use arcane data formats and require custom data displays along with client-side automation. The PFHub effort, instead of focusing on the CMS tool, focuses on customizing and delivering the client-side requirements whilst delegating back-end functionality to external services that provide dependable APIs [5].
The phase-field method (PFM) describes material interfaces at the mesoscopic scale between atomic scale models and macroscale models [6]. The PFM is well established and there are an assortment of code frameworks (e.g., FiPy [7], MMSP [8], MOOSE [9], PRISMS-PF [10]) available for solving the wide variety of phenomena associated with phase-field (e.g. dendritic growth, spinodal decomposition, grain growth) [11]. However, it is difficult for novice as well as seasoned phase-field practitioners to asses the capability of codes for different phenomena without extensive prototyping and groundwork. PFHub aims to provide a low barrier for comparing code output data using a standard set of metrics.
PFHub is a community effort spearheaded by the Center for Hierarchical Materials Design at Northwestern University and the National Institute of Standards and Technology in support of phase-field code development.
The current PFHub deployment [12] focuses on improving cross-collaboration between phase-field code developers and practitioners by providing a standardized set of benchmark problems [13,14] and a workflow for uploading and comparing benchmark results from different phase-field codes.
Community based scientific efforts often require web services to share and display data in unique ways between groups and institutions. These services are difficult to implement due to the groundwork required to investigate and prototype the many data-sharing and CMS tools available. The PFHub framework provides a template for other scientific projects beyond the phase-field community. The method outlined in this paper of using static infrastructure coupled with small independent third party web services provides a flexible approach eliminating the initial prototyping and on-going maintenance required for new infrastructure, while allowing developers to focus on their unique front-end data views.
This paper presents the first deployment of the PFHub framework including its client-side focused design, how it employs external services and metadata about the code base. The paper describes the relative ease with which other scientific groups might adapt the framework for their own purposes and deploy using the fully reproducible Nix environment [15].

Implementation and architecture
The PFHub framework provides a template for other small scientific communities to host custom content and integrate data from members of their community. The current deployment (see Figure 1) provides a facility for uploading, displaying and comparing results from benchmark problems supporting phase-field code developers and practitioners. However, the framework and overall philosophy are broadly transferable to other communities with some custom configuration and content generation. The framework uses the Jekyll static website generator [16] along with automated front-end processing to eliminate the need for a CMS [5], which is generally costly to maintain especially for small scientific communities with limited funding and staffing. The framework relies The hexbin splash provides links to phase-field papers and websites. This can easily be modified with alternative links and images by editing a YAML file.
on the API, WebSocket and webhook infrastructure that underpins the modern web and allows external services to have full-duplex communication between servers and browsers. In particular, PFHub relies on GitHub's well maintained API and webhook functionality for external services (such as Travis CI [17] and Staticman [18]). The workflow for uploading benchmark results relies on third party tools using the following steps, illustrated in 1. The users are first required to upload simulation outputs to an archival resource (e.g., Figshare 1 [19]) configured with permissive cross-origin resource sharing (CORS). 2. The metadata summarizing each simulation is entered into a form on the website (see Figure 3), including relevant details such as memory usage, run time and links to the data archived in the first step. 3. Upon submission, the Staticman app [18] submits the entered metadata as a pull request against the PFHub repository hosted by GitHub. The metadata is stored in a YAML file with a unique path in the repository, see [20] for an example. 4. Travis CI [17] performs linting on the submission and then launches a temporary version of the proposed website using Surge [21]. The PFHub admins can then examine the new submission and further changes can be made if necessary. 5. Once review has been completed to the satisfaction of both the uploading scientist and the website maintainers, the pull request is merged and served to the World Wide Web using a hosting service compatible with GitHub Pages.
A combination of Jekyll templates and CoffeeScript are used to access and download the data links in the submitted YAML files and then display the data in interactive plots on the website. CoffeeScript is a higher level language than JavaScript and, thus, more readable whilst also allowing programming in a more functional manner which makes data manipulation pipelines both more succinct and easier to understand. The interactive plots (see Figure 4) are displayed using the Plotly JavaScript Graphing Library [22] as it provides a programmable interface and requires minimal configuration, see [20] for typical data displayed on the interactive plots. The current deployment of PFHub has benchmark specifications consisting of equations, narrative, plots and code samples, and are composed in Jupyter Notebooks. The Jupyter Notebooks are included as static objects in the website after translation into HTML using the nbconvert tool [23]. There are currently 7 benchmark problems each with a number of variations. At the time of writing there are 109 separate benchmark result uploads [12] submitted as pull requests and approved following code review to ensure compatibility with the website.
The combination of a central repository on GitHub for website source code and metadata with distributed data records on third-party archives avoids the complexity and administrative overhead of maintaining a live database and associated back-end application.

Quality control
The framework has a fully automated test recipe deployed on Travis CI with an environment built using the Nix Package Manager [15]. A fully automated test environment using continuous integration allows all developers and users to have common feedback on code updates and determine the compatibility of result uploads with the deployed website. The environment is pinned to a specific version of the Nix Packages Collection (Nixpkgs) [24], ensuring fully reproducible   build and test phases as well as ensuring that the development and automated testing environments are identical. The full test recipe is outlined in a YAML file, .travis.yml, stored in the repository [25] and consists of the following steps.
1. Build the Nix environment from a persistent cache on Travis CI, reducing the build time.

Operating system
The PFHub framework can be deployed on any platform supporting Nix, which includes all contemporary Linux and macOS platforms. Since the framework is built with Jekyll and automated front-end processing, it can be deployed on GitHub's Pages infrastructure, which enables streamlined deployment without the need for any back-end infrastructure and, thus, is largely platform independent. For development purposes, a local installation of either Nix (on Linux or Mac) or Docker (on Linux, Mac or Windows) is required.

Programming language
PFHub is currently built and tested using the programming languages and versions outlined in Table 1.

Additional system requirements
There are no additional system requirements.

Dependencies
The entire environment can be built using the Nix Package Manager so the only required dependency is a functional Nix installation. The PFHub framework has over 2000 separate package dependencies using data from the Nix package manager. The full dependency graph for PFHub can be seen online [31].

List of contributors
This list is for contributors to the code base, but not those that have only uploaded output results to the website.

(3) Reuse potential
The PFHub framework can be readily adopted by other communities that want to follow a CMS-free philosophy and use well supported external services. The website infrastructure can be cloned as a Git repository or downloaded as a ZIP archive and deployed with minimum effort. The mechanism for uploading data using Staticman can be easily configured for a new repository location. However, customizing the content of the website for a particular scientific community would require considerable effort. The current effort is closely integrated with GitHub, but future deployments could be modified to use other repository services such as GitLab or BitBucket.
The following steps are the more challenging aspects of deploying the framework for a new community.
• Upload new data upload specifications (e.g. the phasefield benchmarks in the PFHub website [12]) in a format that Jekyll can parse, e.g., Jupyter Notebook, Markdown or HTML. • Edit the benchmarks.yaml file to reflect the new upload requirements and describe the figures that need to be generated on the upload comparison pages. • Edit the _config.yml file to update links and text related to the configuration for all aspects of the website. • Update Markdown files to reflect the new content and mission of the scientific community. • Remove data and files that are not required by the new community.
Further details on deployment and development of PFHub can be found in the development guide [34]. Currently, a deployment for a new community has not been attempted and, thus, the above steps need to be refined and documented.
Note 1 Certain commercial equipment, instruments, or materials (or suppliers, or software, ...) are identified in this paper to foster understanding. Such identification does not imply recommendation or endorsement by the National Institute of Standards and Technology, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose.