## Stochastic Tools

The stochastic tools module is under heavy development and has gained some powerful features, with many more to come in the near future.

1. Support for distributed VectorPostprocessor (VPP) data was added to the framework. This allows massively parallel stochastic simulations to be performed with minimal memory impact. The VPP must be programmed to support data that is distributed or replicated. The mode of operation is controlled by the "parallel_type" parameter. When set to distributed mode an output file for each processor will be created.

2. The VPP statistics calculator was generalized to support replicated and distributed VPP data as well as for multiple vectors, see Statistics.

3. Support for computing bootstrap confidence level intervals was added to the statistics calculator, see Statistics.

4. An XML output object was created to allow for single file VPP output.

## Improved Mechanical and Thermal Contact Jacobians

Jacobians for kinematic-formulation base mechanical contact were improved so that their accuracy is not impacted by variable scaling. This change results in significantly improved linear and nonlinear convergence for contact problems used in conjunction with scaling (either manual or automatic). Thermal contact Jacobians were also improved in the month of February. We now supply dependence of the thermal contact residuals on primary-side degrees of freedom, including both (block) on-diagonal temperature and off-diagonal displacements degrees of freedom.

## libMesh level changes

The libMesh update in the month of February enabled adaptivity with the LAGRANGE_VEC finite element family. The update also enables used of periodic boundary conditions with LAGRANGE_VEC.

### Much faster periodic boundaries

This was actually in a previous libMesh update, but the improved performance makes it worth mentioning here. Periodic boundaries now use a tree-search (O(log N) complexity) instead of a linear (O(N)) search. Consequently, MOOSE users of the periodic BC capability should expect significant speed-up of their simulations (especially for large problems).

## Simplified TestHarness Scheduling

The parallel scheduling capability of the TestHarness has been changed to reduce potential pitfalls when creating several related tests. Previously, the TestHarness would make all tests in a single directory eligible to schedule at the same time unless "prereq" parameters were added to force serialization. Now the TestHarness will only schedule a single test from a single directory by default. High concurrency is still achievable by having several different directories in a single application. The prereq parameter should still be used to declare "true" dependencies since execution by input file order is not guaranteed.

It is possible to force parallel scheduling within a directory by using a new parameter parallel_scheduling = True at the top level of the test specification file. See the following example:


[Tests]
parallel_scheduling = True

[test1]
...
[]
[test2]
...
[]
[test3]
...
[]
[]


Extensive use of this parameter is not recommended since it could result in unintended I/O race conditions. It can be difficult to catch all file related outputs. For example, consider outputs due to recover testing, which many developers do not routinely perform on their own workstations. However, it can be convenient to use this parameter if a developer has several highly related tests that they do not wish to split up into separate directories.