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 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 Figure 2.

1. The users are first required to upload simulation outputs to an archival resource (e.g., Figshare¹ [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.
2. Run automated tests on Jupyter Notebooks using NBval [26] and Py.test [27].
3. Run validation tests on HTML files using HTMLProofer [28].
4. Lint and test front-end CoffeeScript using Coffeelint [29] and Mocha [30], respectively.
5. Display a temporary version of the website using Surge [21] for visual review.

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.

1. Wheeler, Daniel; @wd15
2. Keller, Trevor; @tkphd
3. DeWitt, Stephen J.; @stvdwtt
4. Jokisaari, Andrea M.; @amjokisaari
5. Schwen, Daniel; @dschwen
6. Guyer, Jonathan E.; @guyer

Also, see the contributors list on GitHub [32].

Software location

Languages

English