underworldcode / underworld2 Goto Github PK

We should flag a warning for this, as PIC is generally not a great option with quad mesh.

Need to check what happens if using an in memory sqlite database for vis data over long running simulations. Should ensure data from earlier timesteps is deleted or memory usage could blow up rapidly.

Also check there is an easy way to use per-timestep database export.

Just tried a fresh install on ubuntu, importing underworld gave this error:

ImportError: /home/ubuntu/underworlds/underworld2/libUnderworld/build/lib/libSolvers.so: undefined symbol: KSPGetTotalIterations

If a swarm is tied to a mesh, and the mesh is then deformed, the particle cell table will be incorrect (requiring update particle owners) and the particles may no longer be inside the domain.

There are a few options here. A decent default behaviour would be to use the local particle coordinates to remap the particles to the new mesh configuration. Alternatively, particles owners are updated, and particles outside the local domain are culled or moved to another proc.

At the very least we should prevent the mesh being deformed if swarm is tied to it to force users to do all deformations before the swarm is attached.

• cache results for faster evaluation #11
• clean up c++ interface where possible.. hopefully remove these double assignments https://github.com/underworldcode/underworld2/blob/development/libUnderworld/Underworld/Rheology/src/ConstitutiveMatrixCartesian.cpp#L268
  (possible set a 'parentFunctionIO' on the ParticleInCellCoordinate, which then gets 'index' from it's parent IO object).
• get rid of smart pointers for base function evaluations
• do evaluations in batch

Hi all,
Sorry for disturbing again. I find something wired when I ran a subduction model.

1. First of all, I find abnormally high value of StressField (isolated sharp peaks in fig.pre1) on the boundarys between domains(shapes). Can anybody explain why I cannot get more smooth value (it should be as such)?
   
   
2. The velocity field within the rigid continental plate and the oceanic slab is disordered when I try to manifest horizontal movement of the plate (see animation, click to enlarge). The horizontal component Vx of the velocity extracted from on a passive tracer (I place them on the overriding continental block/plate) also shows strong oscillation.
   
   
   Here is how it should looks like:
   
   Is this issue caused by insufficient grid resolution?
3. The stress tensor (read from StressField.xxxxx.h5, which should in fact refer to as the deviatoric stress tensor instead of the literal stress I guess) contains three components shown as StressField_X, StressField_Y, StressField_Z in Paraview, which are supposed to be the three independent variables stress_xx, stress_yy, stress_xy of the stress tensor. I'm a little bit confused: which is which?
   

Thank you for your time!

Best,
Qingwen

Checking for package X11... yes
Checking for package SDL... no
Checking for package Glut... no
Checking for package OpenGL... yes
**** WARNING ****
Need a windowing system for gLucifer Viewer, either
X11, SDL, Glut or AGL. None of these could be found.
The viewer will not be compiled.

These are still disabled as they do not currently return correct results under certain conditions.

Specifically, the surface jacobian is only correct when integrals are performed over certain walls (top/bottom in 2d).

Hi John

I have a model where periodic BCs seem to be working fine for a unit square version, but when I extend to a rectangular domain, they no longer seem to apply. I set the BCs like this :

slipBC = uw.conditions.DirichletCondition( variable=velocityField, nodeIndexSets=(None, JWalls) )

i.e. I pass None to the X velocity component. (I realise that this could introduce a null space problem, but I don't think that's the problem here)

As I say, in the unit square model, I'm getting periodic BC, and I can ask, for instance, what the max X velocity component on the IWalls is; in the rectangular model, the velocities on the IWalls look completely vertical, and a query on the boundary X velocities returns something like:

None Type has not attribute max...

As if the None argument in the BC setup is being taken literally.

Script is here:

https://github.com/dansand/vueesc/blob/master/base_model.py

MINX = 0 for the square model
MINX = -1., for the rectangular model

I have quite a complicated viscosity function now, and when I try to evaluate it, it takes more than 5 minutes. Adding extra functions on top (such as the visc_limited_Fn) seems to make the time required to increase non-linearly (is my guess, but I haven't actually timed the difference).

A full notebook example is here: https://github.com/OlympusMonds/lithospheric_modelling_recipe/blob/pyLMR/pyLMR.ipynb

Do you have any tips for speeding this up?

It looks like UW returns float32 objects from functions:

visc.data[:] = visc_Fn.evaluate(swarm)

print visc.data.dtype  # prints: float32
print np.finfo(np.float32).max  # prints: 3.40282e+38

This means that if a function returns a number higher than ~3.4e38, it becomes inf in the numpy array.

This is potentially problematic, because the calculation of the power-law equation definitely would output numbers bigger than this. The idea would then be to apply a brittle-law (or peierls creep law) over the top of this big number to bring it back to reality.

Also, LavaVu cannot handle infs and fails unceremoniously:

SQL prepare error: (insert into geometry (object_id, timestep, rank, idx, type, data_type, size, count, width, minimum, maximum, dim_factor, units, minX, minY, minZ, maxX, maxY, maxZ, labels, data) values (1, 0, 0, 0, 1, 3, 1, 84120, 0, 1.86972e+19, inf, 1, '', 0, 0, 0, 0, 0, 0, ?, ?)) no such column: inf

I know scaling would fix this - but so would float64..?

I think our testing should include the code compiling on machines
like raijin etc.

Not much use if it only runs on laptops.

from lmondy:

I've attached a log and notebook for a crash I'm getting. Seems to be related to the advector - whenever it kicks in, UW crashes.

The error seems to be:
StgDomain/Mesh/src/IGraph.c:911: failed assertion `fromEl < Sync_GetNumDomains( ((IGraph*)self)->remotes[fromDim] )'

pyLMR.ipynb.txt
crash.log.txt

Which is occurring after:
Time Integration
EP: SwarmAdvector_AdvectionSetup - 0.0000 [min] / 0.0000 max
1st order: HNCG0JZU__integrand - 0.0637 [min] / 0.0637 max
EP: SwarmAdvector_AdvectionFinish - 0.0261 (secs)
EP: GeneralSwarm_Update - 0.0000 (secs)
Time Integration - 0.0899301 [min] / 0.0899301 max

This occurs with or without the advDiff stuff.

Cheers,

Luke

The _setup phase is not run in a obvious parent-child hierarchy, this is a result of the existing AssignFromXML() functions in c.

To simplify this python class confusing we could cull the AssignFromXML() in the c layer - restoring balance to the force. This would improve python readability and reduce the c codebase

as per title. if user tries to use a default function in map function, we have kernel meltdown.

Hey folks

I've moved many models into docs/development/broken. These are models that either don't run to completion without issue, or that I wasn't sure were producing the correct results.

So if your models are here and you wish to retain them, please check that they run to completion and produce correct results. Also tidy them if necessary :-). Once satisfied, you can move them into docs/tutorials or docs/tests, and set permissions to read-only.

If they are tutorial style, Gareth & Rebecca have devised a fancy style guide for reference!

If you do not wish to retain them, remove them.

For info on what belongs where, naming conventions, and other novelties, check docs/development/guidelines.md.

In my old UW models, I often provide:

-Uzawa_velSolver_pc_factor_mat_solver_package mumps
-Uzawa_velSolver_ksp_type preonly
-Uzawa_velSolver_pc_type lu

to use mumps as a direct solve.

Is there an equivilant to pass through to the solver options? I tried passing them as kwargs to the .solve() function, but it seemed to ignore them.

Solver class appears to attach assembled objects to SLE at C level.. however the assembled objects lifetime is managed at the python level. ie, this explodes

import underworld as uw
mesh = uw.mesh.FeMesh_Cartesian()
vel = uw.fevariable.FeVariable(mesh,2)
pres = uw.fevariable.FeVariable(mesh.subMesh,1)
sys = uw.systems.Stokes(vel,pres,1.,(0.,0.))

solv = uw.systems.Solver(sys)
solv = uw.systems.Solver(sys)

solv.solve()

Either the solver class should make this interdependency explicit at the python level (so that lifetimes are managed correctly), or the objects should not be attached to the sle (if possible).

Code will not build on raijin. Fails at the h5py stage.
If h5py is removed then the build fails elsewhere.

this probably shouldn't be a valid input

elementMesh = uw.mesh.FeMesh_Cartesian( elementType='Q2/3213DPC1', 
                                         elementRes=(1,1), 
                                           minCoord=(0.,0.), 
                                           maxCoord=(0.9142,1.) )

The publications directory should reproduce results that other people have done with Underworld. I think it is ok to have benchmarks too, but I think we should be quite specific.

In the Arrhenius example, the notebook reproduces figure 1a of that M&S paper. I would note that the Ra is supposed to be 10^7 with \Delta\eta 3.10^4 and the viscosity is the Frank-Kamenetskii linearlised form. Even though this is a bit old fashioned, for reproducibility I suggest doing the same ! And then show how to do Fig 1b !

I would also recommend not calling the mesh linearMesh when using Q2 elements.

our previous hg hooks are currently disabled as they don't work with git.

have to gittify they, or think of a new strategy.

Hi devs. Just thought I'd interrupt quality day by throwing this one in there. If someone can get around do adding internal heating soon, I'd be really happy.

Repeated runs produce swarm layouts (when using space filler) which are visually quiet different.

I believe this is an issue with the SobolGenerator. Every new call iterates the SobolGeneratorGeneratorCount. Perhaps this iteration is not necessary, but it would mean that the space filler produces identical results for identical input.

Sorry for the spamming!

Here's what I do:

dim = 2

ires = 96
jres = 48

xmin, xmax = -200e3, 200e3
ymin, ymax = -160e3, 15e3

elementMesh = uw.mesh.FeMesh_Cartesian(elementType = 'Q1/dQ0', 
                                       elementRes = (ires, jres), 
                                       minCoord = (xmin, ymin), 
                                       maxCoord = (xmax, ymax))
linearMesh   = elementMesh
constantMesh = elementMesh.subMesh 

print linearMesh.specialSets.keys()
print constantMesh.specialSets.keys()

Output:

['MaxI_VertexSet', 'MinI_VertexSet', 'AllWalls', 'MinJ_VertexSet', 'MaxJ_VertexSet', 'Empty']
{}

I know it's more of cell than a vertex for dQ0, but it would be useful to have. For example, I'm trying to get the average pressure along a wall:

np.average(pressureField[constantMesh.specialSets["MaxJ_VertexSet"]])

and it fails on a KeyError.

Hi John

Here's the Swarm evaluation problem in a much simpler example. If you switch the refineMesh parameter on / off, the swarm evaluation output value changes quite a bit.

https://github.com/dansand/vueesc/blob/master/swarm_int_bug.ipynb

Cheers

Hi all,
I recently encounter a problem bothering me for two weeks. When I try to run underworld (the old v 1.7.1), it crashes frequently and output logs containing error massages like:

...
TimeStep = 7929, Start time = 5.67414e+15, prev timeStep dt = 2.80334e+11
Linear solver (stokesEqn-execute) 
Summary:
  Uzawa its. = 0001 , Uzawa residual = 2.8222473808963e-04
  |G^T u|/|u|               = 8.68710196e+03
  |f - K u - G p|/|f|       = 1.90102889e-06
  |f - K u - G p|_w/|f|_w   = 1.00000000e+00
  |u|_{\infty} = 2.98448575e-08 , u_rms = 6.40212771e-10
  |p|_{\infty} = 2.87173354e+10 , p_rms = 1.45071303e+10
  min/max(u) = -2.18850636e-08 [142] / 2.98448575e-08 [169]
  min/max(p) = -3.42226374e+09 [3777] / 2.87173354e+10 [63]
  \sum_i p_i = 4.64813204e+13 
Linear solver (stokesEqn-execute), solution time 2.689152e-01 (secs)
Time Integration
           EP:        SwarmAdvector_AdvectionSetup -    0.0000 [min] /    0.0002 [max] (secs)
    2nd order:               materialSwarmAdvector -    0.0037 [min] /    0.0055 [max] (secs)
           EP:       SwarmAdvector_AdvectionFinish -    0.0020 (secs)
           EP:          MaterialPointsSwarm_Update -    0.0008 (secs)
In func WeightsCalculator_CalculateAll(): for swarm "picIntegrationPoints"
5: Something went horribly wrong in _PCDVC_Calculate2D: Problem has an under resolved cell (Cell Id = 10), check or tune your population control parameters
Underworld: StGermain/Base/IO/src/Journal.c:547: Journal_Firewall: Assertion `expression' failed.
...

I highlight the error massage here:
Something went horribly wrong in _PCDVC_Calculate2D: Problem has an under resolved cell (Cell Id = 10), check or tune your population control parameters
Underworld: StGermain/Base/IO/src/Journal.c:547: Journal_Firewall: Assertion `expression' failed.
It seems that the same issue have been noticed by other people in the former forum of underworld but it is not accessible any more. Because of my lack of extra time for learning the new underworld 2, which I'm not familar with, I will not shift my attention from the old code to it immediately.
Anyone ever had the same problem? Any hint will be appreciated!

fn1**fn2 

is more fun than

fn.math.pow(fn1,fn2)

For some reason this version (and probably others) has issues producing bindings (for SwarmViewer.h). It doesn't seem to understand our function pointers in this instance, but elsewhere has no issue.

The best solution is to use a more modern version of swig. 1.3.4 is quiet old in any case.

The gLucifer examples have this code:

figtemp = glucifer.Figure( figsize=(800,400) )
figtemp + glucifer.objects.Surface( mesh, temperatureField, colours="blue white red" )
figtemp + glucifer.objects.Mesh( mesh )
figtemp.show()

I'm not sure what this means so I tried this

figtemp = glucifer.Figure( figsize=(800,400) )
figtemp1 = figtemp + glucifer.objects.Surface( mesh, temperatureField, colours="blue white red" )
figtemp2 = figtemp + glucifer.objects.Mesh( mesh )
figtemp2.show()

I get identical images for any of

figtemp.show()
figtemp1.show()
figtemp2.show()

It is as though the + operator is behaving like += in C.

This seems broken. I would expect these to be equivalent

figtemp += glucifer.objects ... 
figtemp = figtemp + glucifer.objects ...

OK, so I have a viscosity function like this:

sri_Fn = fn.tensor.second_invariant( 
                fn.tensor.deviatoric(
                    fn.tensor.symmetric ( 
                        velocityField.gradientFn )) )

non_newtonian_fn = 0.5 * fn.math.pow( A_Fn, -1. / n_Fn ) * \
                   fn.math.pow( sri_Fn, (1. / n_Fn) - 1.) * \
                   fn.math.pow( d_Fn, p_Fn / n_Fn ) * \
                   fn.math.pow( fH20_Fn, -r_Fn / n_Fn ) * \
                   fn.math.exp( (E_Fn + pressureField * V_Fn) / (n_Fn * R * temperatureField))

And down the page a bit, I use this:

stokesPIC.solve(nonLinearIterate=True)

And it seems to work OK (I'm assuming the sri_Fn will be updated on every non-linear iteration, because it's dependent on the velocityField?)

My question is about linking other things into the non-linear process. For example, this rheology depends on the lithostatic pressure. In old UW, we had the PressureCalibration plugin to make sure the pressure outputted by stokes was approximately right for this, and it kicked in after every linear stokes solve. Another example is the isostasy plugin, which could be run non-linearly and would run after each linear stokes solve too.

How can I link in processes like this to the non-linear solve?

So I can do this OK:

print velocityField.evaluate(swarm)

outputting this:

[[ 0.  0.]
 [ 0.  0.]
 [ 0.  0.]
 ..., 
 [ 0.  0.]
 [ 0.  0.]
 [ 0.  0.]]

But when I try:

print viscosity_Fn.evaluate(linearMesh)

I get this:

---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<ipython-input-39-c94b897fcb04> in <module>()
----> 1 print viscosity_Fn.evaluate(linearMesh)

/home/luke/Programs/uw2_dev/underworld/function/_function.pyc in evaluate(self, inputData, inputType)
    428             if inputType != None:
    429                 raise ValueError("'inputType' specification not supported for this input class.")
--> 430             return _cfn.Query(self._fncself).query(inputData._get_iterator())
    431         elif isinstance(inputData, np.ndarray):
    432             if inputType != None:

RuntimeError: Provided input to SwarmVariableFn does not appear to be of supported type.
Supported types are 'FEMCoordinate' and 'ParticleCoordinate'.

But if you look in https://github.com/underworldcode/underworld2/blob/development/libUnderworld/Underworld/Function/src/SwarmVariableFn.cpp line 73 - the code to actually do the mapping back to the mesh appears to be there - I just can't seem to find a way to produce a FEMCoordinate to feed to it.

Cheers,

Currently the Points drawing object only accepts swarm variables. It should be updated to use functions so that (in particular) swarm based functions can be directly visualised. The current workaround is to evaluate the function and copy the results into a new swarm variable, which can then be visualised.

Also, the Surface drawing object cannot draw swarm based functions because it evaluates on global coordinates. A nearest neighbour type algorithm would fix this.

A gLucifer error has cropped up a couple of times when working in notebooks. The images are generated (i.e. the code reports activity ) but not written to disk. I found this error while running notebooks as a different user from the one that installed the code but Joe seems to be getting this on a OS X 10.11 installation that otherwise seems ok.

Joe O'Rourke reported the error for Mac OS

One thing that might help is if we could have a verbose / debugging flag to tell us where the images are supposed to be going.

It might also be useful to have some notebooks which show an alternative to the gLucifer output mode.

To restart a simulation, does Swarm file need to be saved and loaded (like the other checkpotinted fields: temperature, velocity, pressure)? And how to do that?

currently cannot compile with --view-viewer=0. things needed:

• modify SConscript in libUnderworldPy to only compile LavaVu bindings when requried
• modify libUnderworldPy/init.py to conditionally import LavaVu bindings
• update glucifer module accordingly.. in particular, still want to be able to generate db.

Tried to build on Mac at commit 0610383

Found that I had to revert a couple of files: swigall.py, and ./config/packages/HDF5.py:

git checkout 2675978 swigall.py

git checkout d969231 ./config/packages/HDF5.py

Otherwise it couldn't find HDF5, and the swigging didn't work.

Dan

e.g.

tempBC = uw.conditions.DirichletCondition( variable = temperatureField,
indexSetsPerDof = (jWalls,) )

heatequation = uw.systems.SteadyStateHeat(temperatureField=temperatureField, fn_diffusivity=1.0, conditions=[tempBC,])

It seems to me that having the temperatureField passed into the uw.conditions.DirichletCondition class
is redundant,

I'm computing the following integral, which seems to be working fine (i.e. returning reasonable values). But some way into the model run, the function blows up and kills the job.

vdint = uw.utils.Integral((4.*mantleviscosityFn*sinner)*rockIntVar, linearMesh)
vdissfn.evaluate()[0]

RuntimeError: Value underflow error was encountered while evaluating function.

Will fn.exception.SafeMaths help here, or do I need to try and the root cause?

Need to specify no colour bar for a vector arrow plot object added after a surface object. If you don't then the colour bar will be the default colours (blue to orange) rather than the surface colours (blue white red). Below example is working version of a cell in "docs/tutorials/1_02_Convection_Example.ipynb".

figWithV = glucifer.Figure(figsize=(800,400))
figWithV + glucifer.objects.Surface(mesh, temperatureField, colours="blue white red")
figWithV + glucifer.objects.VectorArrows(mesh, velocityField, arrowHeadSize=0.2, lengthScale=0.2, colourBar=False)
figWithV.show()

Better if we can get the colour bar from a vector arrow object to not overwrite previous colour bars.

I have disabled it for now.

It needs to be functionised.

At the moment the evaluate method returns a data array corresponding to the domain of each processor. Is there an easy way to return the max / min value of the global data?

I have been struggling to get consistent versions of h5py / mpi4py on my El Capitanio mac os installation and the error appears to be one associated with inconsistent mpi versions locked in during compilation.

This feels pretty fragile and I wonder if it will be necessary to build our own mpi4py.

Hi, I am new to Underworld. Right now, I am trying to set different velocities at side boundaries using Stepfunction. I already tried using uniform velocity at side boundaries and the results turns out all right. But when I use step function (convergent in the upper part and Vx=0 in the lower part of model), there are no velocity shown in result. Does anyone know where is wrong? I attached my input file here.

/Users/InputFiles/BaseApps/ExtensionBaseApp.xml

 <!-- SCALING component definition -->
 <!-- scaling -->
 <struct name="default_scaling">
    <param name="Type">Scaling</param>
    <param name="spaceCoefficient_meters"> 1e6 </param>
    <param name="timeCoefficient_seconds"> 316.223 </param>
    <param name="massCoefficient_kilograms"> 8e19 </param>
    <param name="temperatureCoefficient_kelvin"> 1 </param>
 </struct>

 <!-- Shape Stuff -->
 <struct name="upperMantleShape">
    <param name="Type">Everywhere</param>
 </struct>
 <struct name="lowerMantleShape">
    <param name="Type">Box</param>
    <param name="startX" units="km">0.0</param>
    <param name="endX" units="km">4000</param>
    <param name="startY" units="km">0.0</param>
    <param name="endY" units="km">350</param>
 </struct>
 <struct name="ContinentShape">
    <param name="Type">Box</param>
    <param name="startX" units="km">0</param>
    <param name="endX" units="km">0</param>
    <param name="startY" units="km">0</param>
    <param name="endY" units="km">0</param>
 </struct>
<struct name="mainSlab">
    <param name="Type">Box</param>
    <param name="startX" units="km">1200</param>
    <param name="endX" units="km">3400</param>
    <param name="startY" units="km">900</param>
    <param name="endY" units="km">1000</param>
 </struct>
 <struct name="slabPerturbation">
    <param name="Type">PolygonShape</param>
    <list name="vertices">
       <asciidata>
          <columnDefinition name = "x" type="double" units="km"/>
          <columnDefinition name = "y" type="double" units="km"/>
          1200   1000 
          1200   900 
          1020   800 
          1020   900 
       </asciidata>
    </list>
 </struct>
 <struct name="slabShape">
    <param name="Type">Union</param>
    <list name="shapes">
       <param>mainSlab</param>
       <param>slabPerturbation</param>
    </list>
 </struct>


 <!-- Background Material Stuff -->
 <struct name="upperMantleViscosity">
    <param name="Type">MaterialViscosity</param>
    <param name="eta0" units="Pa*s">1e20</param>
 </struct>
 <struct name="upperMantle">
    <param name="Type">RheologyMaterial</param>
    <param name="Shape">upperMantleShape</param>
    <param name="density" units="kg*m^-3">3300</param>
    <param name="Rheology">upperMantleViscosity</param>
 </struct>

 <!-- Lower Mantle Material Stuff -->
 <struct name="lowerMantleViscosity">
    <param name="Type">MaterialViscosity</param>
    <!-- Viscosity 100 x Upper Mantle -->
    <param name="eta0" units="Pa*s">1e22</param>
 </struct>
 <struct name="LowerMantle">
    <param name="Type">RheologyMaterial</param>
    <param name="Shape">lowerMantleShape</param>
    <param name="density" units="kg*m^-3">3300</param>
    <param name="Rheology">lowerMantleViscosity</param>
 </struct>

 <!-- Continent Material Stuff -->
 <struct name="ContinentViscosity">
    <param name="Type">MaterialViscosity</param>
    <!-- Viscosity 200 x Upper Mantle -->
    <param name="eta0" units="Pa*s">1e20</param>
 </struct>
 <struct name="Continent">
    <param name="Type">RheologyMaterial</param>
    <param name="Shape">ContinentShape</param>
    <param name="density" units="kg*m^-3">3300</param>
    <param name="Rheology">ContinentViscosity</param>
 </struct>


 <!-- Slab Stuff -->
 <struct name="slabViscosity">
    <param name="Type">MaterialViscosity</param>
    <!-- Viscosity 200 x Upper Mantle (Background)-->
    <param name="eta0" units="Pa*s">1e22</param>
 </struct>
 <struct name="slabYielding">
    <param name="Type">Byerlee</param>
    <param name="StrainRateField">StrainRateField</param>
    <param name="BlockGeometry">geometry</param>
    <param name="FeMesh">linearMesh</param>
    <param name="cohesion" units="Pa">32e6</param>
    <param name="depthCoefficient">0.25</param>
 </struct>
 <struct name="Slab">
    <param name="Type">RheologyMaterial</param>
    <param name="Shape">slabShape</param>
    <param name="density" units="kg*m^-3">3380</param>
    <list name="Rheology">
       <param>slabViscosity</param>
       <param>slabYielding</param>
    </list>
 </struct>
 <!-- Slab Field Stuff -->
 <struct name="SlabField">
    <param name="Type">MaterialFeVariable</param>
    <param name="Swarm">picIntegrationPoints</param>
    <param name="Material">Slab</param>
    <param name="Context">context</param>
    <param name="Mesh">linearMesh</param>
 </struct>

 <!-- Lower Mantle Field Stuff -->
 <struct name="LowerMantleField">
    <param name="Type">MaterialFeVariable</param>
    <param name="Swarm">picIntegrationPoints</param>
    <param name="Material">LowerMantle</param>
    <param name="Context">context</param>
    <param name="Mesh">linearMesh</param>
 </struct>

   <struct name="EulerDeform">
    <list name="systems">

                   <struct>
                           <param name="mesh"> velocityMesh </param>
                           <param name="remesher">velocityRemesher</param>
                           <param name="velocityField"> VelocityField </param>
                           <list name="fields">
                                   <struct>
                                           <param name="field">VelocityField</param>
                                           <param name="variable">velocity</param>
                                   </struct>
                           </list>
                   </struct>
           </list>
   </struct>/struct>

/Users/huilin/Downloads/InputFiles/velocityBCs_HL.xml

   <!-- Visualisation stuff -->
   <include>Underworld/Viewports/ParticleMaterialVP.xml</include>
   <include>Underworld/Viewports/VelocityMagnitudeVP.xml</include>
   <include>gLucifer/window.xml</include>
   <struct name="components" mergeType="merge">
        <struct name="window" mergeType="merge">
            <param name="Viewport">ParticleMaterialVP VelocityMagnitudeVP</param>
        </struct>
   </struct>

<!-- Velocity BCs -->
<struct name="velocityBCs">
    <param name="type">CompositeVC</param>
    <list name="vcList">
        <struct>
            <param name="type"> WallVC </param>
            <param name="wall"> bottom </param>
            <list name="variables">
                <struct>
                    <param name="name">vy</param>
                    <param name="type">double</param>
                        <param name="value"> 0 </param>
                                   </struct>
            </list>
        </struct>
        <struct>
            <param name="type"> WallVC </param>
            <param name="wall"> left </param>
            <list name="variables">
                <struct>
                    <param name="name">vx</param>
                    <param name="type">func</param>
                                           <param name="value">StepFunctionProduct2</param>
                </struct>
            </list>
        </struct>
        <struct>
            <param name="type"> WallVC </param>
            <param name="wall"> right </param>
            <list name="variables">
                <struct>
                    <param name="name">vx</param>
                    <param name="type">func</param>
                                           <param name="value">StepFunctionProduct1</param>
                </struct>
            </list>
        </struct>
        <struct>
            <param name="type"> WallVC </param>
            <param name="wall"> front </param>
            <list name="variables">
                <struct>
                    <param name="name">vz</param>
                    <param name="type">double</param>
                                           <param name="value"> 0 </param>
                </struct>
            </list>
        </struct>
        <struct>
            <param name="type"> WallVC </param>
            <param name="wall"> back </param>
            <list name="variables">
                <struct>
                    <param name="name">vz</param>
                    <param name="type">double</param>
                                           <param name="value"> 0 </param>
                </struct>
            </list>
        </struct>
        <struct>
            <param name="type"> WallVC </param>
            <param name="wall"> top </param>
            <list name="variables">
                <struct>
                    <param name="name">vy</param>
                    <param name="type">double</param>
                                           <param name="value"> 0 </param>
                </struct>
            </list>
        </struct>
    </list>
</struct>

as per title.

Hi all,

Could someone give me a refresher on how to invoke UW in parallel with the new Python stuff? Can you do this in IPython OK?
I saw somewhere there is a plan for a tutorial in the docs.

Cheers,
Luke

The code now requires a c++11 compiler with fancy header files such as . We should check for that at configure time.
Also ipython notebook functionality is required now, well for system testing anyway.

We need to up date the configure.py to reflect the requirements of the code

Whenever I run a job it aborts at the end with the message below, not causing any real issue but should probably be cleaned up

*** The MPI_Comm_create_keyval() function was called after MPI_FINALIZE was invoked.
*** This is disallowed by the MPI standard.
*** Your MPI job will now abort.

Following on from #26

• Can we access the Inflow population control routine through Python?
• Does this happen automatically if I set
  swarm.particleEscape = True ?