Let's see if that fixes it on every platform

...that is empties and mapped onto the solution dataset between recoils.

...and split it into a runner that sums up element wise and a runner that keeps discrete defect lists around.

The latter shall be used with a DiracKernel to insert the defects and possible with a stochastic cluster dynamics

This is waiting on libMesh/libmesh#748 which will allow serializationand communication of the complex datastructures in these User Objects.

• Implement threading in MyTRIMRun
• Support MPI parallelization in MyTRIMRasterizer and MyTRIMRun

This should be NeutronEnergyType and the static string vector should also have a new name

@snschune this needs a few changes. PR coming up.

• Move them from MAMMOTH but don't rename
• Rename

For testing purposes add a kernel that forms an annihilation term for vacancies and interstitials

Missing MooseMesh and MooseSyntax includes.

Let's leave this open

Excess energy from recoils needs to be binned in the element runner and reported back to MOOSE. This will allow us to simulate the recoil heating from fission fragments.

Sampling IonBase::_dir on the unit sphere can be done without rejection.

Apart from adding replacement collisions (#14) the interstitial vacancy balance should be preserved as we are producing Frenkel pairs (at least in a closed periodic system).
We currently produce significantly less vacancies than interstitials.

Pleeeeease :-)

You slipped in a a broken assert @snschune

/Users/schwd/Programs/magpie/include/utils/MultiIndex.h:441:18: error: use of undeclared identifier '_index'

By having a PKA generator assign a tag that is not -1 we should correctly create vacant sites at the PKA starting points. Such a generator would not create an excess of interstitials (#48).

Both the rasterizer as well as the runner need to be pushed to PRE_AUX.

Depends on idaholab/moose#7030

Add a mesh class with interfaces to get high level mesh data to suppress biassing and to force QUAD4/HEX8 elements, etc.

This will be used by an (optional) internal PointLocator replacement.

The MultivariateDiscretePDF class will be the interface between Mammoth and Magpie.
Magpie needs to able to provide this way of sampling initial Z/A, energy and direction of flight
to mytrim.

First, I'll implement base class that simply provides a drawSample<T>(T & sample) method and contains a Real _normalization variable. _normalization enables multiple pdf objects to be scaled correctly w.r.t. each other.

In our case T is of type IonBase, so I'll implement a template specialization for that case.

The rasterizer knows the timestep (or time passed since the last MyTRIM phase). I could pass a MaterialUserObject to generate a set of PKA origin points (using the #23 randomElementPoint function.

The MaterialUserObject would encapsulate the logic to calculate a set of PKA energies with the correct probabilities. Initially this could be empirical, and eventually we'll use neutronics data.

Create source term kernels for nonlinear variables.

MAMMOTH needs to transfer neutronics data to be used by MAGPIE PKA samplers. We need to figure out a way to implement this transfer regardless of which app is master and which one is slave.

A homogenized sample could be used for high energy recoils like fission fragments and a probability could be applied for accepting or rejecting the first generation recoils. This would make it feasible to simulate lower fission rates in in small samples that otherwise get an entire ff cascade folded onto itself (through periodicity).

Homogenization will also speed up these recoils.

Analyze the periodicity of the variables coupled into the MyTRIMRasterizer and make a decision on periodicity. One option is to take the maximum periodic dimensions, or the periodicity information of the first coupled variable, etc.

This will help debug the automatic material density calculation. It should output the density in g/cm^3 that the MooseMyTRIMMaterial::calculateDensity function calculates. It will apply the same procedure as MooseMyTRIMSample::lookupMaterial.

Uninitialized values etc. test segfaults in civet

Blocks #25

For debugging and model systems.

The TRIM run will be handled by a pair of user objects:

• ElementUserObject which rasters the simulation domain into a regular grid of TRIM materials. This requires a list of coupled variables and vectors with TRIM parameters. The grid is AllGather'd
• GeneralUserObject which runs TRIM in each thread/core, generating a global defect map that is all gatherd.

Kernels will utilize the second UO (subject of a future PR) to apply defect production rates.

These should be cleaned up to use the neato new C++11 features.

I'm renaming a lot of stuff in MyTRIM. Magpie will need to be updated accordingly.

I'll try this first before going with #76. Let's see what the speedup is.

• Do profiling
• Implement new PointLocator

I will need objects storing multi index type data for implementing multivariate discrete pdfs (i.e. ladder pdfs).

There doesn't seem to be a good reason this converts to floating point, adds an epsilon and uses std::floor...

This uses some outdated patterns.

@pghasse Use this issue in PR #91

Need this to start cascades in random locations.

getMinInDimension and isTranslatedPeriodic only work on regular orthogonal meshes

And/or limit maximum free free path length in thin media (this would chop up free flight in thin media or the vacuum).

This would drive ballistic mixing.

Per libMesh/libmesh#813 size and size_sq on TypeVector are deprecated and need to be replaced with norm and norm_sq.

This will mean that Magpie compilation errors out unless C++ was enabled upon libMesh building and the required features are found to be supported.

Magpie is an optional dependence in several MOOSE apps. We can and should use this opportunity to go ahead on the C++11 adoption (which is planned for MOOSE framework as well).

This will make Magpie a proving ground for C++11 features.

The PointLocator based sample is generic, which is fine for complex meshes. For regular GeneratedMeshes we can figure out the element id and the local MyTRIM material much easier (using integer divisions etc.).

• Move MooseMyTRIMSample to MooseMyTRIMElementSample
• Create MooseMyTRIMGridSample
• Move MyTRIMRasterizer to MyTRIMElementRasterizer
• Create MyTRIMGridRasterizer

To reduce the amount of point locator lookups a grid based rasterizer could be useful. This may need to be combined with a modified Dirac runner that snaps the defect data to a grid and caches the point locator results.

Find out why pka->tag contains junk sometimes.