fluidityproject / fluidity Goto Github PK

Hi all,

I'm getting a fatal error mentioning load balancing issues when attempting to use flredecomp with a 1D mesh and petsc 3.7.3 (full error message attached). It works fine, however, if I configure and make fltools useing petsc 3.4.2.

Cheers,
Ben

flredecomp_error_message.txt

While looking through a buildbot log file on one of my branches, I noticed that this test is raising a lot of PETSC errors due to calling the euclid (i.e. LU) preconditioned from hypre, which appears to no longer exist in petsc 3.6. The test still passes, so it's obviously using something to solve the linear system, but it would probably be nice if this were made explicit. The test is antediluvian and owned by @dham, so I'm not sure who to ask to look at this.

The balzano wetting and drying tests all seem to use LinearMomentum with reference density set to 1.0. These should simply use Boussinesq as this sets a bad example and we should test what people use in practice.

Hi all,

Another issue has cropped up in relation to lagrangian detector IO.

In the lagrangian-detector-issues branch, I have added a test named "lagrangian_detector_checkpoint_newarray". This test picks up from a precomputed checkpoint, with one lagrangian detector array (Steve). The checkpointed .flml has been modified, with an additional lagrangian detector array (Bob) added, which is initialized via python (so one detector array should pick up from the checkpoint - Steve -, whilst the other should not -Bob).

The simulation fails at line 1624 of file Diagnostic_variables.F90:

(unit = 11, file = 'lagrangian_detectors_1_checkpoint_det.groups')
Fortran runtime error: End of file

Despite specifying that detector array Bob should be initialized via python, fluidity is trying to initialize it from a checkpoint.

From looking at the code, it seems that the detector IO routines cannot accommodate both checkpointed and initialized detector arrays simultaneously. Indeed, if there is one checkpointed detector array, the assumption is that that is true for all, which will not necessarily be the case.

Was there a reason that this was setup like this or is it a bug?

Best wishes,

Rhodri

Hi all,

Would there be any objection to the default build setup becoming --with-adjoint=no? At present, if you do not have libadjoint installed, you get hundreds of spurious warnings during the fluidity build (missing include directories etc...). As fluidity users shouldn't really be expected to install libadjoint, my preference would be to change the build default, such that the adjoint side of things is only built when requested.

How many people are actually using the adjoint functionality inside fluidity? Is this something that we want to support in the long-term or has everybody now migrated to libadjoint, firedrake etc...?

Rhod

When compiling with ifort 11.1:

ifort: command line warning #10156: ignoring option '-X'; no argument required

When compiling with ifort 15.0.0:

ifort: command line warning #10006: ignoring unknown option '-Xhost'

As I believe is common knowledge, the Intel Fortran compilers still appear to be very sensitive to the order of use statements in modules, with compiler errors liable to appear if these get too far away from the INTEL preferred order (if both a module and another which uses it are to be included, the parent must be included before the children).

Given that I'm currently running into problems with this while trying to use a branch on the imperial cluster, I'm proposing to fix this for as many modules as I need to, while also including a python script to detect this behaviour if this starts to be a problem for others. Since we also have external users running on intel, and others may have views on what they'd like to have happen I'm raising this as an issue now first.

As was raised in the AMCG Fluidity developers meeting, the current configure script doesn't support the default namescheme chosen for VTK libraries in (at least) version 6.2 and 6.3, as used in unstable versions of debian. An example of a workaround method is available here: 32eb490 however this is itself incompatible with the centos packages for VTK 6.1. The intention is to extend the existing autoconf scripts to include all reasonable namings.

This was originally reported by Giovanni Quattrocchi. The error message and backtrace are:

*** FLUIDITY ERROR ***
Source location: (Tidal_Diagnostics.F90,  439)
Error message: Error while calculating harmonic analysis phase!
Backtrace will follow if it is available:
/usr/bin/fluidity(fprint_backtrace_+0x1a) [0x4d274a]
/usr/bin/fluidity(__fldebug_MOD_flabort_pinpoint+0x210) [0x4cb660]
/usr/bin/fluidity(__tidal_diagnostics_MOD_save_harmonic_x_in_fields+0x245)  [0xa69ed5]
/usr/bin/fluidity(__tidal_diagnostics_MOD_update_harmonic_fields+0x87b)  [0xa6a7bb]
/usr/bin/fluidity(__tidal_diagnostics_MOD_calculate_tidal_harmonics+0x447)  [0xa6d1b7]
/usr/bin/fluidity(__diagnostic_fields_new_MOD_calculate_diagnostic_variable_scalar_multiple_indexed+0x331)  [0xa40b81]
/usr/bin/fluidity(__diagnostic_fields_new_MOD_calculate_diagnostic_variables+0x87d)  [0xa45abd]
/usr/bin/fluidity(__fluids_module_MOD_fluids+0x2e62) [0x4d0622]
/usr/bin/fluidity(mainfl+0xd3) [0x4cae63]
/usr/bin/fluidity(main+0x112) [0x4c0122]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f211c3ef76d]
/usr/bin/fluidity() [0x4c14b1]

First of all the error is rather unhelpful. Secondly, it seems to occur randomly: just changing the mesh it occurs in a setup that previously gave decent results (as experienced by myself as well).

The error occurs where it's trying to compute the phase from a complex tidal harmonic constituent whose value is 0.+0.j (i.e. both real and imaginary components are zero), as in that case the phase is undefined. It is unclear to me why this shouldn't occur during the spin up of the tidal diagnostics. The reason it only fails sometimes may have to do with the dodgy floating point comparison (==0) that it uses. I think if the harmonic constituent is 0.+0.j it should just give an argument (and amplitude) of 0 and not error. I'm just doing some experiments to see if this is indeed what's going on.

At the moment, the NetCDF reader is trying to second-guess netcdf dimensions and variable names. The newest GEBCO bathymetry follows convention COARDS, CF1.5, a CF convention not currently supported and therefore can not be read unless the user hacks the netcdf file in a very specific way.

A more appropriate solution would be to have the user inform Fluidity of the netcdf variables in Diamond. A quicker, less appropriate solution is to implement support for COARDS CF 1.5.

Relevant file: bathymetry/NetCDF_reader.cpp

Deal all,

I tried to compute the strain rate second invariant using P1DG-P2 and I received an error message saying that this diagnostic field is not available for discontinuous fields. I tried to use a vector galerkin projection to create a continuous velocity field but the strain_rate_second_invariant algorithm does not give me the option to use the new continuous field. I could perhaps use remap_fields within the strain rate routine just for my own branch but I felt that this is something that might has happened to other people and needs to be fixed also in the master branch.

Thanks,
Yorgos

I'm getting an error when using master, only when trying to build the schema, namely:

"schemas/prognostic_field_options.rnc:981:22: error: syntax error"

The only recent modification I can see was by James a few days ago in commit b1c41e7. Are you seeing this same problem James?

As it says in the title, this is to allow it to be set as a python diagnostic. This is useful a.o. in turbine parameterisations through enhanced bottom drag.

Could somebody please explain to me why, on current fluidity master, if I specify the following configure and build command:

./configure --enable-2d-adaptivity --enable-debugging LDFLAGS="-L/data/rhodrid/Packages/Zoltan/Zoltan_v3.81/build/lib -I/data/rhodrid/Packages/Zoltan/Zoltan_v3.81/build/include" && make clean && make

My system finds zoltan .mod files (v3.81) fine. However, if I make the following subtle modification (i.e. --with-adjoint=no):

./configure --with-adjoint=no --enable-2d-adaptivity --enable-debugging LDFLAGS="-L/data/rhodrid/Packages/Zoltan/Zoltan_v3.81/build/lib -I/data/rhodrid/Packag/Zoltan/Zoltan_v3.81/build/include" && make clean && make

It fails to find the zoltan .mod files, with the following error...

Halos_Derivation.F90:919.8:
    use zoltan
       1
Fatal Error: Can't open module file 'zoltan.mod' for reading at (1): No such file or directory

Could somebody that better understands configure please explain this to me? I'm clearly missing something!!

Best wishes,

Rhod

With adjoint log here: https://www.dropbox.com/s/lr7nxvh56s08nkm/config_with_adjoint.txt?dl=0
Without adjoint here: https://www.dropbox.com/s/z46310u30vvlio1/config_no_adjoint.txt?dl=0

libspatialindex creates temporary files when bulk loading data beyond a certain size, which is quite inefficient. I'm not certain this is completely safe in parallel either, as two processes could potentially generate the same temporary filename (perhaps with very low probability) due to the use of mktemp:

./lib/libspatialindex.a(Tools.o): In function `Tools::TemporaryFile::TemporaryFile()':
Tools.cc:(.text+0x34ac): warning: the use of `mktemp' is dangerous, better use `mkstemp'

The following edit disables the use of disk caching by the libspatialindex bulk loader in a minimally invasive way:

index 50427ee..66de5fa 100644
--- a/spatialindex-1.8.0/src/rtree/RTree.cc
+++ b/spatialindex-1.8.0/src/rtree/RTree.cc
@@ -207,7 +207,7 @@ SpatialIndex::ISpatialIndex* SpatialIndex::RTree::createAndBulkLoadNewRTree(
        switch (m)
        {
        case BLM_STR:
-               bl.bulkLoadUsingSTR(static_cast<RTree*>(tree), stream, bindex, bleaf, 10000, 100);
+               bl.bulkLoadUsingSTR(static_cast<RTree*>(tree), stream, bindex, bleaf, std::numeric_limits<uint32_t>::max(), 1);
                break;
        default:
                throw Tools::IllegalArgumentException("createAndBulkLoadNewRTree: Unknown bulk load method.");

There have been interface changes between parmetis 3.1 + metis 4, which fluidity uses and parmetis 4 + metis 5(.1) which have been out for quite a while now. Debian and Ubuntu packages are still on the older versions (although there is a libparmetis4 in experimental now). The reason this is an issue for a number of people is that petsc uses the new parmetis and metis versions, and if you build petsc with parmetis support fluidity picks up these instead of the older ones. Parmetis support for PETSc is necessary to use MUMPS (scotch support with MUMPS is broken).

Places we use metis/parmetis in fluidity:

• fldecomp calls metis and these calls need updating. We have discussed deprecating fldecomp previously - but some people (me a.o.) have indicated that they do some times still use it. Maybe it's time to revisit this discussion
• sam call parmetis. Again here the question is do we need maintain sam support or can everything been done via zoltan?

I'm seeing a bug in a number of our parallel short tests when run on CX1 with Intel and PETSc 3.5.2 (but not when run on workstations with GCC and Petsc 3.4.2), giving (in the example of 5material-droplet-parallel):

*** FLUIDITY ERROR ***
Source location: (Zoltan_integration.F90,  847)
Error message: After load balancing process would have an empty partition.
Backtrace will follow if it is available:
../../bin/flredecomp(fprint_backtrace_+0x2a) [0x88676a]
../../bin/flredecomp(fldebug_mp_flabort_pinpoint_+0x210) [0x4bfd00]
../../bin/flredecomp(zoltan_integration_mp_zoltan_drive_+0x2334) [0x8752a4]
../../bin/flredecomp(flredecomp+0x985) [0x4bc3f5]
../../bin/flredecomp(main+0xedb) [0x4bd4fb]
/lib64/libc.so.6(__libc_start_main+0xfd) [0x2ae0e42e4d5d]
../../bin/flredecomp() [0x4bb969]
Use addr2line -e <binary> <address> to decipher.
Error is terminal.

Full logs available at:

http://buildbot.ese.ic.ac.uk:8080/builders/5material-droplet-parallel/builds/299/steps/shell_5/logs/stdio

This appears to be a recent bug appearing with c6c446. a2ecea worked fine, c6c446 fails.

Github now have the concept of protected branches [https://github.com/blog/2051-protected-branches-and-required-status-checks]. These are branches which automatically refuse to accept forced push commits which change the branch history. I propose we activate this for the fluidity master branch

Turning this on for the master branch would prevent the accidental overwriting of existing work with new commits (It doesn't prevent all malicious behaviour but nothing much does) and would be a useful (but orthogonal) step in the process of having a CI server always do the final push to master branch.

The biggest downside that I can see is that if we ever need to delete history, only someone with suitable authority could do it.

When running with a free surface with mesh movement, and using LinearMomentum with a reference density rho=1.0 the contribution to the rhs of the continuity equation is not divided by rho in assemble/Free_Surface.F90, line 543. Without mesh movement in line 561, the term does get divided by rho.

Note that with the variable_density option we already divide by rho in the mass matrix mass_ele, but that option does not work with mesh movement because of the logic in line 364. If there is some reason we don't support that combination we should probably options check for that.

Ultimately this of course indicates that fs+mesh movem.+linearmom. isn't really tested, so we need some validation+testing work for this to be functional.

I get the following error message when trying to run a serial calculation with a binary GMSH file:

Error message: Error: can't find '$EndMeshFormat' (is this a GMSH mesh file?)

This is using master fluidity compiled with intel2015. If I use an ASCII GMSH file then it works. Any idea what I have done wrong?

The current implementation of serial mesh-to-mesh interpolation deals with periodic boundaries by cloning the position mesh across the boundary, but doesn't fix the connectivity. This then means that the frontal intersection finder routines can't find the additional mass. I'll test whether this was fixed in @stephankramer's Parallel periodic adaptive branch when I get round to it.

In ocean_forcing/bulk_parameterisation.F90:
the variable Rns is declared 'real' at line 575 and used in line 677 without being assigned a value. There is an assignment in line 677 in the embedded subroutine cor30a(), but Rns gets redeclared 'real' on line 768 which make it a separate variable local to that subroutine only. The same problem seems to hold for the variable Rnl - there might be (many?) more.

This makes the 'forcing' test fail on intel 14, so it would be nice if we could fix this and get a clean 'make test' with it. Also I don't understand how this currently gives the right answer, is this code actually in use?

Hi all,

A student of mine (Tim Jones) has recently been running a series of simulations where Lagrangian detectors are utilized for a range of models diagnostics. He is finding that simulations incorporating these detectors are incredibly temperamental, with segmentation faults and a number of assertion failures commonly observed inside detector subroutines, particularly as the number of detectors is increased. I have tried to generate some minimal reproducers for these features (his simulations are typically run across hundreds of cores, which makes debugging a challenge!) and have managed to come up with the first one (a segmentation fault during parallel detector exchange) today, hence this report.

In the branch lagrangian_detector_issues, I have modified the lagrangian_detector_3d test to include 100,000 detectors (a reasonably small number) and a slightly finer mesh resolution than was previously the case. The simulation is setup to run on 2 cores and produces a segmentation fault when exchanging detectors between cores. I have included a back-trace below. Any ideas what is going on? I have verified that this case runs fine on a single core.

I'll keep going on reproducing the cases that fail various asserts, but would be interested to hear if others have experienced similar issues with detectors (in parallel)... and if this is a simple fix or something more complex...

_#0 __memcpy_sse2_unaligned ()
at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:35
#1 0x00007fffd3158558 in ?? ()

from /usr/lib/openmpi/lib/openmpi/mca_btl_vader.so
#2 0x00007fffd270f948 in mca_pml_ob1_send_request_schedule_once ()

from /usr/lib/openmpi/lib/openmpi/mca_pml_ob1.so
#3 0x00007fffd270a258 in mca_pml_ob1_recv_frag_callback_ack ()

from /usr/lib/openmpi/lib/openmpi/mca_pml_ob1.so
#4 0x00007fffd3159813 in mca_btl_vader_poll_handle_frag ()

from /usr/lib/openmpi/lib/openmpi/mca_btl_vader.so
#5 0x00007fffd3159cc3 in ?? ()

from /usr/lib/openmpi/lib/openmpi/mca_btl_vader.so
#6 0x00007fffea9731ea in opal_progress () from /usr/lib/libopen-pal.so.13
#7 0x00007ffff3e56f65 in ompi_request_default_wait_all ()

from /usr/lib/libmpi.so.12
#8 0x00007ffff3e87d27 in PMPI_Waitall () from /usr/lib/libmpi.so.12
#9 0x00007ffff476b46a in pmpi_waitall__ () from /usr/lib/libmpi_mpifh.so.12
#10 0x000000000059e9d0 in detector_parallel::exchange_detectors (state=...,

detector_list=..., send_list_array=...) at Detector_Parallel.F90:446

#11 0x000000000059f83c in detector_parallel::distribute_detectors (state=...,

detector_list=...) at Detector_Parallel.F90:189

#12 0x00000000013a24fb in detector_move_lagrangian::move_lagrangian_detectors (

state=..., detector_list=..., dt=0.10000000000000001, timestep=61_

This issue appears if using spatial adaptivity in parallel, your mesh has faces and the preprocessor macro HAVE_MEMORY_STATS=1.

In subroutine renumber_positions in Fields_Manipulation.F90, if the input positions mesh has faces then it allocates memory for the output mesh faces. BUT it does this without registering the memory (using register_allocation of Memory_Diagnostics.F90). Then at some point later on, it will call 'proper' deallocate routines on said output mesh which will call register_deallocation for the memory. The result being a negative amount of memory registration which is reported at the end of the calculation.

This issue doesn't actually effect the outcome of the calculation as it is just femtools internal memory register, but did cause me to think I had got a bug for a couple of days.

It looks like a similar procedure takes place in the routine renumber_positions_elements, but in here it uses the 'proper' allocate routine for the faces type (add_faces), so memory is registered. Should the same process be used in the other routine?

It's come to my attention that we have broken executables in the tools directory (I rather think I broke them). In particular these are tools not built by the fltools tools target, so they aren't tested or built under buildbot. Is there consensus whether these should be fixed, or removed, and if fixed, should they be built by make fltools?

Tools:

• time_average_parallel
• test_laplacian_vector

also there are the Flint_* routines, which don't seem to get compiled into an executable.

Apologies if this is documented somewhere and I just couldn't find it, but while investigating changing flredecomp to work better with arbitrary file names, I've discovered that due to the regexps in the make_check_options script, module subroutines which end with parentheses are currently excluded from the auto generated check_options.F90 file. Is this behaviour deliberate, or a bug? If the latter, then a couple of modules also need patching:

1. to make the routines public
2. to let complete_field_path know about aliased fields.

When running 'make unittest' on a build with Intel 2015 compilers, an internal compiler error is thrown whilst building parameterisation/tests/test_inner_tensor_product.F90, as per the error below.

I have a built container in a private dockerhub repository which I can make available to developers working on resolving this bug; let me know if you need access.

[fluidity@7f0c51fa0551 tests]$ make
mpicxx -I../../include -I/usr/include/vtk -I/usr/include/python2.6 -DHAVE_NUMPY -I/usr/lib64/python2.6/site-packages/numpy/core/include -I/usr/include -I/usr/include -I/usr/include -I/opt/intel/impi/5.0.3.049/intel64/include -I/opt/intel//impi/5.0.3.049/intel64/include -Iinclude/ -DHAVE_PETSC -I/usr/include/vtk -DHAVE_VTK=1 -DHAVE_VTK=1 -L/opt/intel/composer_xe_2015/mkl/lib/intel64/ -I/usr/include/udunits2 -I/usr/include/python2.6 -DHAVE_NUMPY -I/usr/lib64/python2.6/site-packages/numpy/core/include -O3 -ip -xHost -I../include -I../../include -D TESTNAME=test_tensor_inner_product_ -o test_tensor_inner_product_main.o -c test_main.cpp
In file included from /usr/include/python2.6/pyconfig.h(6),
from /usr/include/python2.6/Python.h(8),
from ../../include/python_statec.h(5),
from test_main.cpp(46):
/usr/include/python2.6/pyconfig-64.h(1034): warning #47: incompatible redefinition of macro "_POSIX_C_SOURCE" (declared at line 162 of "/usr/include/features.h")
#define _POSIX_C_SOURCE 200112L
^

In file included from /usr/include/python2.6/pyconfig.h(6),
from /usr/include/python2.6/Python.h(8),
from ../../include/python_statec.h(5),
from test_main.cpp(46):
/usr/include/python2.6/pyconfig-64.h(1043): warning #47: incompatible redefinition of macro "_XOPEN_SOURCE" (declared at line 164 of "/usr/include/features.h")
#define _XOPEN_SOURCE 600
^

mpif90 -I../../include -vec-report=0 -DHAVE_NUMPY -I/usr/lib64/python2.6/site-packages/numpy/core/include -extend_source -O3 -ip -xHost -I/usr/include -I/usr/include -I/usr/include -I/opt/intel/impi/5.0.3.049/intel64/include -I/opt/intel//impi/5.0.3.049/intel64/include -Iinclude/ -r8 -I../ -c test_tensor_inner_product.F90
ifort: command line remark #10010: option '-vec-report=0' is deprecated and will be removed in a future release. See '-help deprecated'
test_tensor_inner_product.F90(50): catastrophic error: Internal compiler error: internal abort Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.
compilation aborted for test_tensor_inner_product.F90 (code 1)
make: *** [test_tensor_inner_product.o] Error 1
rm test_tensor_inner_product_main.o
[fluidity@7f0c51fa0551 tests]$

Dear all,

I have noticed that the classic damping functions like the van Driest one, which are usually used along with the second order SFS Smagorinsky model is not available for continuous Galerkin discretization of the velocity field while it is for the discontinuous one. I believe that the LES options should not be different for the two formulations and thus the options in diamond should be identical. Also, I found the van Driest function in Momentum_DG.F90 and not LES.F90, which is very confusing . I would be happy to help changing this.

Kind regards,
Yorgos

This tool does not seem to be tested. If it's not tested it can break any commit - or be removed if it happens to be in someone's way.

I looked into the question that was raised on the old launchpad site. It seems to be an issue when attempting to create a second order hex mesh from a first order mesh. Comments in the code tend to refer to tets, hexes were potentially overlooked when writing these routines.

In subroutine vtk_write_fields in VTK_interfaces.F90, if the model mesh is continuous but the state contains discontinuous fields to be output, then no vtkGhostLevels are output. This is because the element_halos are not copied to the discontinuous model_mesh.

It seems to me that the element_halos could be copied across from model to model_mesh and thus the vtkGhostLevels would be present in the pvtu. But maybe this is not correct or always the case.

You could argue that the output mesh should be chosen to be a discontinuous mesh in the options file in the first place but it could at least give a warning. Or if possible include the element halos in the dgify process.

My latest attempt to build using ifort 11.1 has produced the following errors:

Fields_Allocates.F90(2664): error #6780: A dummy argument with the INTENT(IN) attribute shall not appear in a variable definition context   [MESH]
      mesh%adj_lists%nnlist => nnlist
------^
Fields_Allocates.F90(2762): error #6780: A dummy argument with the INTENT(IN) attribute shall not appear in a variable definition context   [MESH]
      mesh%adj_lists%nelist => nelist
------^
Fields_Allocates.F90(2860): error #6780: A dummy argument with the INTENT(IN) attribute shall not appear in a variable definition context   [MESH]
      mesh%adj_lists%eelist => eelist

I believe this was changed in commit 9045e06 in order to get intel 14 to play ball. Is there any reason we can't declare the mesh intent(inout)?

The smoother routine in error_measures/Field_preprocessing looks for a scale factor at a key: adaptivity_options/preprocessing/helmholtz_smoother/smoothing_scale_factor
whereas the schema makes you specify an (anisotropic) length scale. Not sure which behaviour is more sensible, hence raising this as an issue.

adaptivity_options/preprocessing/helmholtz_smoother/smoothing_length_scale

The PETSC_DEFAULT_DOUBLE_PRECISION -> PETSC_DEFAULT_REAL conversion needs to be applied and SAME_PRECONDITIONER no longer exists (use KSP/PCSetReusePreconditioner() instead).

It appears that there is a slight bug in the code when inserting vector fields and tensor fields.

line 243:
call insert(state_2_split(1), extract_scalar_field(state_2, v_field%name), v_field%name)
I guess the function should be extract_vector_field.

Similarly in lines 237, 276 and 282.

The kinds int_4, int_8, int_16, real_4, real_8, and real_16 are incorrectly defined. For example

int_16 = selected_int_kind(16)

yields an 8 byte integer

The method allocate_petsc_csr_matrix_from_nnz in Sparse_Tools_Petsc.F90 seems broken when trying to build a block matrix, namely the petsc numbering is created too large and so a debugging assert fails.

If element_size is present, on Line 317 the index_rows (and the index_columns) is set to be the rows * element_size, where the input rows is the number of element block rows, making index_rows the actual number of rows in the matrix.

When the row_numbering is then created on Line 326, it is given nnodes=index_rows, rather than the original number of element block rows. As such, the row_numbering is created as size index_rows * blocks(1), which is too large (namely it becomes the number of actual rows in the matrix * the block size). This then breaks in an assert on Line 364.

I think the fix for this would be to set the index_rows and index_cols to be of size rows and columns. I think all the variables after this are then consistent (and consistent with the comments at the start of the routine).

This works for me, but I'm just a little worried that I have accidentally misunderstood the roles of blocks and element_size in this routine. @jrper suggested you might know more about this routine @stephankramer?

There appears to be a problem (stemming from commit 2382bc2) when using both OpenMP and debugging. I'm getitng failures in the following tests

Summary of test problems with failures or warnings:
mmat-impact.xml: F
1mat-shocktube-gmsh.xml: F
tracer_inflow_2d_dg_cg_quad.xml: F
mmat-gravity-col-p2lumpedp1.xml: F
gauss_point_buoyancy.xml: F
1mat-shocktube.xml: F
mmat-shocktube.xml: F
spherical_patch.xml: F
mmat-gravity-col-p2p1.xml: F

So these failures are all for the same reason (invalid cache), but are not limited to advection, some of these fail in Momentum_DG.F90. Looking at the cache invalidation (prepopulate_transform_cache in Transform_Element.F90), all that is required to trigger it is a different refcount in the coordinate mesh, compared to when the caching occured.

This wasn't picked up as there is no combined OpenMP and debugging build on buildbot, I'll email Tim to see if he can add one.

Running on xenial, python_diagnostic_field test crashes with output as below, though the test itself passes.

Reproduced both inside and outside a container.

*** Error in `fluidity': double free or corruption (!prev): 0x00000000032a4c30 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f4cac87c7e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x7fe0a)[0x7f4cac884e0a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f4cac88898c]
fluidity(_ZN4Spud13OptionManager6OptionD1Ev+0x134)[0xcbc884]
fluidity(_ZN4Spud13OptionManager6OptionD1Ev+0x49)[0xcbc799]
fluidity(_ZN4Spud13OptionManager6OptionD1Ev+0x49)[0xcbc799]
fluidity(_ZN4Spud13OptionManager6OptionD1Ev+0x49)[0xcbc799]
fluidity(_ZN4Spud13OptionManagerD1Ev+0x17)[0xcbc9a7]
/lib/x86_64-linux-gnu/libc.so.6(+0x39ff8)[0x7f4cac83eff8]
/lib/x86_64-linux-gnu/libc.so.6(+0x3a045)[0x7f4cac83f045]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf7)[0x7f4cac825837]
fluidity(_start+0x29)[0x4ac369]
======= Memory map: ========
00400000-00f1e000 r-xp 00000000 00:52 1572 /home/fluidity/fluidity/bin/fluidity
0111e000-0111f000 r--p 00b1e000 00:52 1572 /home/fluidity/fluidity/bin/fluidity
0111f000-012c1000 rw-p 00b1f000 00:52 1572 /home/fluidity/fluidity/bin/fluidity
012c1000-014a6000 rw-p 00000000 00:00 0
02ffa000-03abe000 rw-p 00000000 00:00 0 [heap]
7f4c946ba000-7f4c946f6000 r-xp 00000000 00:52 880 /home/fluidity/fluidity/lib/libspud.so.0
7f4c946f6000-7f4c948f6000 ---p 0003c000 00:52 880 /home/fluidity/fluidity/lib/libspud.so.0
7f4c948f6000-7f4c948f7000 r--p 0003c000 00:52 880 /home/fluidity/fluidity/lib/libspud.so.0
7f4c948f7000-7f4c948f8000 rw-p 0003d000 00:52 880 /home/fluidity/fluidity/lib/libspud.so.0
7f4c948f8000-7f4c948fd000 r-xp 00000000 00:52 2254 /home/fluidity/fluidity/python/libspud.so
7f4c948fd000-7f4c94afc000 ---p 00005000 00:52 2254 /home/fluidity/fluidity/python/libspud.so
7f4c94afc000-7f4c94afd000 r--p 00004000 00:52 2254 /home/fluidity/fluidity/python/libspud.so
7f4c94afd000-7f4c94afe000 rw-p 00005000 00:52 2254 /home/fluidity/fluidity/python/libspud.so
7f4c94afe000-7f4c94b39000 r-xp 00000000 00:52 6978 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_reordering.x86_64-linux-gnu.so
7f4c94b39000-7f4c94d38000 ---p 0003b000 00:52 6978 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_reordering.x86_64-linux-gnu.so
7f4c94d38000-7f4c94d39000 r--p 0003a000 00:52 6978 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_reordering.x86_64-linux-gnu.so
7f4c94d39000-7f4c94d3e000 rw-p 0003b000 00:52 6978 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_reordering.x86_64-linux-gnu.so
7f4c94d3e000-7f4c94d7f000 rw-p 00000000 00:00 0
7f4c94d7f000-7f4c94da0000 r-xp 00000000 00:52 6977 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_min_spanning_tree.x86_64-linux-gnu.so
7f4c94da0000-7f4c94f9f000 ---p 00021000 00:52 6977 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_min_spanning_tree.x86_64-linux-gnu.so
7f4c94f9f000-7f4c94fa0000 r--p 00020000 00:52 6977 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_min_spanning_tree.x86_64-linux-gnu.so
7f4c94fa0000-7f4c94fa4000 rw-p 00021000 00:52 6977 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_min_spanning_tree.x86_64-linux-gnu.so
7f4c94fa4000-7f4c94fa5000 rw-p 00000000 00:00 0
7f4c94fa5000-7f4c94fc2000 r-xp 00000000 00:52 6976 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_traversal.x86_64-linux-gnu.so
7f4c94fc2000-7f4c951c1000 ---p 0001d000 00:52 6976 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_traversal.x86_64-linux-gnu.so
7f4c951c1000-7f4c951c2000 r--p 0001c000 00:52 6976 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_traversal.x86_64-linux-gnu.so
7f4c951c2000-7f4c951c7000 rw-p 0001d000 00:52 6976 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_traversal.x86_64-linux-gnu.so
7f4c951c7000-7f4c951c8000 rw-p 00000000 00:00 0
7f4c951c8000-7f4c951e5000 r-xp 00000000 00:52 6975 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_tools.x86_64-linux-gnu.so
7f4c951e5000-7f4c953e4000 ---p 0001d000 00:52 6975 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_tools.x86_64-linux-gnu.so
7f4c953e4000-7f4c953e5000 r--p 0001c000 00:52 6975 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_tools.x86_64-linux-gnu.so
7f4c953e5000-7f4c953ea000 rw-p 0001d000 00:52 6975 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_tools.x86_64-linux-gnu.so
7f4c953ea000-7f4c95418000 r-xp 00000000 00:52 6972 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_shortest_path.x86_64-linux-gnu.so
7f4c95418000-7f4c95617000 ---p 0002e000 00:52 6972 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_shortest_path.x86_64-linux-gnu.so
7f4c95617000-7f4c95618000 r--p 0002d000 00:52 6972 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_shortest_path.x86_64-linux-gnu.so
7f4c95618000-7f4c9561e000 rw-p 0002e000 00:52 6972 /usr/lib/python2.7/dist-packages/scipy/sparse/csgraph/_shortest_path.x86_64-linux-gnu.so
7f4c9561e000-7f4c95671000 r-xp 00000000 00:52 6954 /usr/lib/python2.7/dist-packages/scipy/sparse/_csparsetools.x86_64-linux-gnu.so
7f4c95671000-7f4c95870000 ---p 00053000 00:52 6954 /usr/lib/python2.7/dist-packages/scipy/sparse/_csparsetools.x86_64-linux-gnu.so
7f4c95870000-7f4c95871000 r--p 00052000 00:52 6954 /usr/lib/python2.7/dist-packages/scipy/sparse/_csparsetools.x86_64-linux-gnu.so
7f4c95871000-7f4c95877000 rw-p 00053000 00:52 6954 /usr/lib/python2.7/dist-packages/scipy/sparse/_csparsetools.x86_64-linux-gnu.so
7f4c95877000-7f4c95b57000 r-xp 00000000 00:52 6943 /usr/lib/python2.7/dist-packages/scipy/sparse/_sparsetools.x86_64-linux-gnu.so
7f4c95b57000-7f4c95d56000 ---p 002e0000 00:52 6943 /usr/lib/python2.7/dist-packages/scipy/sparse/_sparsetools.x86_64-linux-gnu.so
7f4c95d56000-7f4c95d57000 r--p 002df000 00:52 6943 /usr/lib/python2.7/dist-packages/scipy/sparse/_sparsetools.x86_64-linux-gnu.so
7f4c95d57000-7f4c95d58000 rw-p 002e0000 00:52 6943 /usr/lib/python2.7/dist-packages/scipy/sparse/_sparsetools.x86_64-linux-gnu.so
7f4c95d58000-7f4c95dce000 r-xp 00000000 00:52 6907 /usr/lib/python2.7/dist-packages/numpy/random/mtrand.x86_64-linux-gnu.so
7f4c95dce000-7f4c95fce000 ---p 00076000 00:52 6907 /usr/lib/python2.7/dist-packages/numpy/random/mtrand.x86_64-linux-gnu.so
7f4c95fce000-7f4c95fcf000 r--p 00076000 00:52 6907 /usr/lib/python2.7/dist-packages/numpy/random/mtrand.x86_64-linux-gnu.so
7f4c95fcf000-7f4c9600a000 rw-p 00077000 00:52 6907 /usr/lib/python2.7/dist-packages/numpy/random/mtrand.x86_64-linux-gnu.so
7f4c9600a000-7f4c9600b000 rw-p 00000000 00:00 0
7f4c9600b000-7f4c96014000 r-xp 00000000 00:52 6880 /usr/lib/python2.7/dist-packages/numpy/fft/fftpack_lite.x86_64-linux-gnu.so
7f4c96014000-7f4c96213000 ---p 00009000 00:52 6880 /usr/lib/python2.7/dist-packages/numpy/fft/fftpack_lite.x86_64-linux-gnu.so
7f4c96213000-7f4c96214000 r--p 00008000 00:52 6880 /usr/lib/python2.7/dist-packages/numpy/fft/fftpack_lite.x86_64-linux-gnu.so
7f4c96214000-7f4c96215000 rw-p 00009000 00:52 6880 /usr/lib/python2.7/dist-packages/numpy/fft/fftpack_lite.x86_64-linux-gnu.so
7f4c96215000-7f4c96216000 r-xp 00000000 00:52 6864 /usr/lib/python2.7/lib-dynload/future_builtins.x86_64-linux-gnu.so
7f4c96216000-7f4c96415000 ---p 00001000 00:52 6864 /usr/lib/python2.7/lib-dynload/future_builtins.x86_64-linux-gnu.so
7f4c96415000-7f4c96416000 r--p 00000000 00:52 6864 /usr/lib/python2.7/lib-dynload/future_builtins.x86_64-linux-gnu.so
7f4c96416000-7f4c96417000 rw-p 00001000 00:52 6864 /usr/lib/python2.7/lib-dynload/future_builtins.x86_64-linux-gnu.so
7f4c96417000-7f4c96437000 r-xp 00000000 00:52 6853 /usr/lib/python2.7/dist-packages/numpy/linalg/_umath_linalg.x86_64-linux-gnu.so
7f4c96437000-7f4c96636000 ---p 00020000 00:52 6853 /usr/lib/python2.7/dist-packages/numpy/linalg/_umath_linalg.x86_64-linux-gnu.so
7f4c96636000-7f4c96637000 r--p 0001f000 00:52 6853 /usr/lib/python2.7/dist-packages/numpy/linalg/_umath_linalg.x86_64-linux-gnu.so
7f4c96637000-7f4c96638000 rw-p 00020000 00:52 6853 /usr/lib/python2.7/dist-packages/numpy/linalg/_umath_linalg.x86_64-linux-gnu.so
7f4c96638000-7f4c96852000 r-xp 00000000 00:52 2734 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f4c96852000-7f4c96a51000 ---p 0021a000 00:52 2734 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f4c96a51000-7f4c96a6d000 r--p 00219000 00:52 2734 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f4c96a6d000-7f4c96a79000 rw-p 00235000 00:52 2734 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f4c96a79000-7f4c96a7c000 rw-p 00000000 00:00 0
7f4c96a7c000-7f4c96a9a000 r-xp 00000000 00:52 6751 /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
7f4c96a9a000-7f4c96c99000 ---p 0001e000 00:52 6751 /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
7f4c96c99000-7f4c96c9a000 r--p 0001d000 00:52 6751 /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
7f4c96c9a000-7f4c96c9e000 rw-p 0001e000 00:52 6751 /usr/lib/python2.7/lib-dynload/_ctypes.x86_64-linux-gnu.so
7f4c96c9e000-7f4c96d52000 r-xp 00000000 00:52 6738 /usr/lib/python2.7/dist-packages/numpy/core/umath.x86_64-linux-gnu.so
7f4c96d52000-7f4c96f52000 ---p 000b4000 00:52 6738 /usr/lib/python2.7/dist-packages/numpy/core/umath.x86_64-linux-gnu.so
7f4c96f52000-7f4c96f53000 r--p 000b4000 00:52 6738 /usr/lib/python2.7/dist-packages/numpy/core/umath.x86_64-linux-gnu.so
7f4c96f53000-7f4c96f59000 rw-p 000b5000 00:52 6738 /usr/lib/python2.7/dist-packages/numpy/core/umath.x86_64-linux-gnu.so
7f4c96f59000-7f4c96f5b000 rw-p 00000000 00:00 0
7f4c97bd2000-7f4c97bd5000 r-xp 00000000 00:52 6852 /usr/lib/python2.7/dist-packages/numpy/linalg/lapack_lite.x86_64-linux-gnu.so
7f4c97bd5000-7f4c97dd4000 ---p 00003000 00:52 6852 /usr/lib/python2.7/dist-packages/numpy/linalg/lapack_lite.x86_64-linux-gnu.so
7f4c97dd4000-7f4c97dd5000 r--p 00002000 00:52 6852 /usr/lib/python2.7/dist-packages/numpy/linalg/lapack_lite.x86_64-linux-gnu.so
7f4c97dd5000-7f4c97dd6000 rw-p 00003000 00:52 6852 /usr/lib/python2.7/dist-packages/numpy/linalg/lapack_lite.x86_64-linux-gnu.so
7f4c97ffd000-7f4c981fd000 rw-p 00000000 00:00 0
7f4c98419000-7f4c9841f000 r-xp 00000000 00:52 2733 /usr/lib/python2.7/lib-dynload/_hashlib.x86_64-linux-gnu.so
7f4c9841f000-7f4c9861e000 ---p 00006000 00:52 2733 /usr/lib/python2.7/lib-dynload/_hashlib.x86_64-linux-gnu.so
7f4c9861e000-7f4c9861f000 r--p 00005000 00:52 2733 /usr/lib/python2.7/lib-dynload/_hashlib.x86_64-linux-gnu.so
7f4c9861f000-7f4c98620000 rw-p 00006000 00:52 2733 /usr/lib/python2.7/lib-dynload/_hashlib.x86_64-linux-gnu.so
7f4c98868000-7f4c988e8000 rw-p 00000000 00:00 0
7f4c988e8000-7f4c98a50000 r-xp 00000000 00:52 6737 /usr/lib/python2.7/dist-packages/numpy/core/multiarray.x86_64-linux-gnu.so
7f4c98a50000-7f4c98c4f000 ---p 00168000 00:52 6737 /usr/lib/python2.7/dist-packages/numpy/core/multiarray.x86_64-linux-gnu.so
7f4c98c4f000-7f4c98c51000 r--p 00167000 00:52 6737 /usr/lib/python2.7/dist-packages/numpy/core/multiarray.x86_64-linux-gnu.so
7f4c98c51000-7f4c98c5e000 rw-p 00169000 00:52 6737 /usr/lib/python2.7/dist-packages/numpy/core/multiarray.x86_64-linux-gnu.so
7f4c98c5e000-7f4c98c70000 rw-p 00000000 00:00 0
7f4c9c000000-7f4c9c021000 rw-p 00000000 00:00 0
7f4c9c021000-7f4ca0000000 ---p 00000000 00:00 0
7f4ca0026000-7f4ca0126000 rw-p 00000000 00:00 0
7f4ca1294000-7f4ca1295000 ---p 00000000 00:00 0
7f4ca1295000-7f4ca1a95000 rw-p 00000000 00:00 0
7f4ca2ac2000-7f4ca2acd000 r-xp 00000000 00:52 60 /lib/x86_64-linux-gnu/libnss_files-2.23.so
7f4ca2acd000-7f4ca2ccc000 ---p 0000b000 00:52 60 /lib/x86_64-linux-gnu/libnss_files-2.23.so
7f4ca2ccc000-7f4ca2ccd000 r--p 0000a000 00:52 60 /lib/x86_64-linux-gnu/libnss_files-2.23.so
7f4ca2ccd000-7f4ca2cce000 rw-p 0000b000 00:52 60 /lib/x86_64-linux-gnu/libnss_files-2.23.so
7f4ca2cce000-7f4ca2cd4000 rw-p 00000000 00:00 0
7f4ca2cd4000-7f4ca2cdf000 r-xp 00000000 00:52 58 /lib/x86_64-linux-gnu/libnss_nis-2.23.so
7f4ca2cdf000-7f4ca2ede000 ---p 0000b000 00:52 58 /lib/x86_64-linux-gnu/libnss_nis-2.23.so
7f4ca2ede000-7f4ca2edf000 r--p 0000a000 00:52 58 /lib/x86_64-linux-gnu/libnss_nis-2.23.so
7f4ca2edf000-7f4ca2ee0000 rw-p 0000b000 00:52 58 /lib/x86_64-linux-gnu/libnss_nis-2.23.so
7f4ca2ee0000-7f4ca2ef6000 r-xp 00000000 00:52 56 /lib/x86_64-linux-gnu/libnsl-2.23.so
7f4ca2ef6000-7f4ca30f5000 ---p 00016000 00:52 56 /lib/x86_64-linux-gnu/libnsl-2.23.so
7f4ca30f5000-7f4ca30f6000 r--p 00015000 00:52 56 /lib/x86_64-linux-gnu/libnsl-2.23.so
7f4ca30f6000-7f4ca30f7000 rw-p 00016000 00:52 56 /lib/x86_64-linux-gnu/libnsl-2.23.so
7f4ca30f7000-7f4ca30f9000 rw-p 00000000 00:00 0
7f4ca30f9000-7f4ca3101000 r-xp 00000000 00:52 54 /lib/x86_64-linux-gnu/libnss_compat-2.23.so
7f4ca3101000-7f4ca3300000 ---p 00008000 00:52 54 /lib/x86_64-linux-gnu/libnss_compat-2.23.so
7f4ca3300000-7f4ca3301000 r--p 00007000 00:52 54 /lib/x86_64-linux-gnu/libnss_compat-2.23.so
7f4ca3301000-7f4ca3302000 rw-p 00008000 00:52 54 /lib/x86_64-linux-gnu/libnss_compat-2.23.so
7f4ca390d000-7f4ca3916000 r-xp 00000000 00:52 3492 /lib/x86_64-linux-gnu/libcrypt-2.23.so
7f4ca3916000-7f4ca3b15000 ---p 00009000 00:52 3492 /lib/x86_64-linux-gnu/libcrypt-2.23.so
7f4ca3b15000-7f4ca3b16000 r--p 00008000 00:52 3492 /lib/x86_64-linux-gnu/libcrypt-2.23.so
7f4ca3b16000-7f4ca3b17000 rw-p 00009000 00:52 3492 /lib/x86_64-linux-gnu/libcrypt-2.23.so
7f4ca3b17000-7f4ca3b45000 rw-p 00000000 00:00 0
7f4ca3b45000-7f4ca3c14000 r-xp 00000000 00:52 3086 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
7f4ca3c14000-7f4ca3e14000 ---p 000cf000 00:52 3086 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
7f4ca3e14000-7f4ca3e17000 r--p 000cf000 00:52 3086 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
7f4ca3e17000-7f4ca3e19000 rw-p 000d2000 00:52 3086 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
7f4ca3e19000-7f4ca3e1a000 rw-p 00000000 00:00 0
7f4ca3e1a000-7f4ca3e60000 r-xp 00000000 00:52 3490 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0
7f4ca3e60000-7f4ca4060000 ---p 00046000 00:52 3490 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0
7f4ca4060000-7f4ca4062000 r--p 00046000 00:52 3490 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0
7f4ca4062000-7f4ca4064000 rw-p 00048000 00:52 3490 /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0
7f4ca4064000-7f4ca4065000 rw-p 00000000 00:00 0
7f4ca4065000-7f4ca4073000 r-xp 00000000 00:52 3488 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0
7f4ca4073000-7f4ca4272000 ---p 0000e000 00:52 3488 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0
7f4ca4272000-7f4ca4273000 r--p 0000d000 00:52 3488 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0
7f4ca4273000-7f4ca4274000 rw-p 0000e000 00:52 3488 /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0
7f4ca4274000-7f4ca429b000 r-xp 00000000 00:52 3486 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0
7f4ca429b000-7f4ca449b000 ---p 00027000 00:52 3486 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0
7f4ca449b000-7f4ca449c000 r--p 00027000 00:52 3486 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0
7f4ca449c000-7f4ca449d000 rw-p 00028000 00:52 3486 /usr/lib/x86_64-linux-gnu/libwind.so.0.0.0
7f4ca449d000-7f4ca44b2000 r-xp 00000000 00:52 3484 /usr/lib/x86_64-linux-gnu/libroken.so.18.1.0
7f4ca44b2000-7f4ca46b1000 ---p 00015000 00:52 3484 /usr/lib/x86_64-linux-gnu/libroken.so.18.1.0
7f4ca46b1000-7f4ca46b2000 r--p 00014000 00:52 3484 /usr/lib/x86_64-linux-gnu/libroken.so.18.1.0
7f4ca46b2000-7f4ca46b3000 rw-p 00015000 00:52 3484 /usr/lib/x86_64-linux-gnu/libroken.so.18.1.0
7f4ca46b3000-7f4ca46e3000 r-xp 00000000 00:52 3482 /usr/lib/x86_64-linux-gnu/libhcrypto.so.4.1.0
7f4ca46e3000-7f4ca48e3000 ---p 00030000 00:52 3482 /usr/lib/x86_64-linux-gnu/libhcrypto.so.4.1.0
7f4ca48e3000-7f4ca48e4000 r--p 00030000 00:52 3482 /usr/lib/x86_64-linux-gnu/libhcrypto.so.4.1.0
7f4ca48e4000-7f4ca48e5000 rw-p 00031000 00:52 3482 /usr/lib/x86_64-linux-gnu/libhcrypto.so.4.1.0
7f4ca48e5000-7f4ca48e6000 rw-p 00000000 00:00 0
7f4ca48e6000-7f4ca4985000 r-xp 00000000 00:52 3480 /usr/lib/x86_64-linux-gnu/libasn1.so.8.0.0
7f4ca4985000-7f4ca4b84000 ---p 0009f000 00:52 3480 /usr/lib/x86_64-linux-gnu/libasn1.so.8.0.0
7f4ca4b84000-7f4ca4b85000 r--p 0009e000 00:52 3480 /usr/lib/x86_64-linux-gnu/libasn1.so.8.0.0
7f4ca4b85000-7f4ca4b88000 rw-p 0009f000 00:52 3480 /usr/lib/x86_64-linux-gnu/libasn1.so.8.0.0
7f4ca4b88000-7f4ca4c0c000 r-xp 00000000 00:52 3478 /usr/lib/x86_64-linux-gnu/libkrb5.so.26.0.0
7f4ca4c0c000-7f4ca4e0b000 ---p 00084000 00:52 3478 /usr/lib/x86_64-linux-gnu/libkrb5.so.26.0.0
7f4ca4e0b000-7f4ca4e0e000 r--p 00083000 00:52 3478 /usr/lib/x86_64-linux-gnu/libkrb5.so.26.0.0
7f4ca4e0e000-7f4ca4e11000 rw-p 00086000 00:52 3478 /usr/lib/x86_64-linux-gnu/libkrb5.so.26.0.0
7f4ca4e11000-7f4ca4e12000 rw-p 00000000 00:00 0
7f4ca4e12000-7f4ca4e1a000 r-xp 00000000 00:52 3476 /usr/lib/x86_64-linux-gnu/libheimntlm.so.0.1.0
7f4ca4e1a000-7f4ca5019000 ---p 00008000 00:52 3476 /usr/lib/x86_64-linux-gnu/libheimntlm.so.0.1.0
7f4ca5019000-7f4ca501a000 r--p 00007000 00:52 3476 /usr/lib/x86_64-linux-gnu/libheimntlm.so.0.1.0
7f4ca501a000-7f4ca501b000 rw-p 00008000 00:52 3476 /usr/lib/x86_64-linux-gnu/libheimntlm.so.0.1.0
7f4ca501b000-7f4ca501e000 r-xp 00000000 00:52 3474 /lib/x86_64-linux-gnu/libkeyutils.so.1.5
7f4ca501e000-7f4ca521d000 ---p 00003000 00:52 3474 /lib/x86_64-linux-gnu/libkeyutils.so.1.5
7f4ca521d000-7f4ca521e000 r--p 00002000 00:52 3474 /lib/x86_64-linux-gnu/libkeyutils.so.1.5
7f4ca521e000-7f4ca521f000 rw-p 00003000 00:52 3474 /lib/x86_64-linux-gnu/libkeyutils.so.1.5
7f4ca521f000-7f4ca5226000 r-xp 00000000 00:52 3472 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4
7f4ca5226000-7f4ca5425000 ---p 00007000 00:52 3472 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4
7f4ca5425000-7f4ca5426000 r--p 00006000 00:52 3472 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4
7f4ca5426000-7f4ca5427000 rw-p 00007000 00:52 3472 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.4
7f4ca5427000-7f4ca5464000 r-xp 00000000 00:52 3470 /usr/lib/x86_64-linux-gnu/libgssapi.so.3.0.0
7f4ca5464000-7f4ca5664000 ---p 0003d000 00:52 3470 /usr/lib/x86_64-linux-gnu/libgssapi.so.3.0.0
7f4ca5664000-7f4ca5665000 r--p 0003d000 00:52 3470 /usr/lib/x86_64-linux-gnu/libgssapi.so.3.0.0
7f4ca5665000-7f4ca5667000 rw-p 0003e000 00:52 3470 /usr/lib/x86_64-linux-gnu/libgssapi.so.3.0.0
7f4ca5667000-7f4ca5668000 rw-p 00000000 00:00 0
7f4ca5668000-7f4ca5681000 r-xp 00000000 00:52 3468 /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25
7f4ca5681000-7f4ca5881000 ---p 00019000 00:52 3468 /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25
7f4ca5881000-7f4ca5882000 r--p 00019000 00:52 3468 /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25
7f4ca5882000-7f4ca5883000 rw-p 0001a000 00:52 3468 /usr/lib/x86_64-linux-gnu/libsasl2.so.2.0.25
7f4ca5883000-7f4ca589a000 r-xp 00000000 00:52 3466 /lib/x86_64-linux-gnu/libresolv-2.23.so
7f4ca589a000-7f4ca5a9a000 ---p 00017000 00:52 3466 /lib/x86_64-linux-gnu/libresolv-2.23.so
7f4ca5a9a000-7f4ca5a9b000 r--p 00017000 00:52 3466 /lib/x86_64-linux-gnu/libresolv-2.23.so
7f4ca5a9b000-7f4ca5a9c000 rw-p 00018000 00:52 3466 /lib/x86_64-linux-gnu/libresolv-2.23.so
7f4ca5a9c000-7f4ca5a9e000 rw-p 00000000 00:00 0
7f4ca5a9e000-7f4ca5aa8000 r-xp 00000000 00:52 3464 /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
7f4ca5aa8000-7f4ca5ca7000 ---p 0000a000 00:52 3464 /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
7f4ca5ca7000-7f4ca5ca8000 r--p 00009000 00:52 3464 /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
7f4ca5ca8000-7f4ca5ca9000 rw-p 0000a000 00:52 3464 /usr/lib/x86_64-linux-gnu/libkrb5support.so.0.1
7f4ca5ca9000-7f4ca5cac000 r-xp 00000000 00:52 3462 /lib/x86_64-linux-gnu/libcom_err.so.2.1
7f4ca5cac000-7f4ca5eab000 ---p 00003000 00:52 3462 /lib/x86_64-linux-gnu/libcom_err.so.2.1
7f4ca5eab000-7f4ca5eac000 r--p 00002000 00:52 3462 /lib/x86_64-linux-gnu/libcom_err.so.2.1
7f4ca5eac000-7f4ca5ead000 rw-p 00003000 00:52 3462 /lib/x86_64-linux-gnu/libcom_err.so.2.1
7f4ca5ead000-7f4ca5ed9000 r-xp 00000000 00:52 3460 /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1
7f4ca5ed9000-7f4ca60d8000 ---p 0002c000 00:52 3460 /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1
7f4ca60d8000-7f4ca60da000 r--p 0002b000 00:52 3460 /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1
7f4ca60da000-7f4ca60db000 rw-p 0002d000 00:52 3460 /usr/lib/x86_64-linux-gnu/libk5crypto.so.3.1
7f4ca60db000-7f4ca60dc000 rw-p 00000000 00:00 0
7f4ca60dc000-7f4ca619f000 r-xp 00000000 00:52 3458 /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3
7f4ca619f000-7f4ca639f000 ---p 000c3000 00:52 3458 /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3
7f4ca639f000-7f4ca63ac000 r--p 000c3000 00:52 3458 /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3
7f4ca63ac000-7f4ca63ae000 rw-p 000d0000 00:52 3458 /usr/lib/x86_64-linux-gnu/libkrb5.so.3.3
7f4ca63ae000-7f4ca63bf000 r-xp 00000000 00:52 3456 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.5.1
7f4ca63bf000-7f4ca65bf000 ---p 00011000 00:52 3456 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.5.1
7f4ca65bf000-7f4ca65c0000 r--p 00011000 00:52 3456 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.5.1
7f4ca65c0000-7f4ca65c1000 rw-p 00012000 00:52 3456 /usr/lib/x86_64-linux-gnu/libtasn1.so.6.5.1
7f4ca65c1000-7f4ca661a000 r-xp 00000000 00:52 3454 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.1.0
7f4ca661a000-7f4ca6819000 ---p 00059000 00:52 3454 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.1.0
7f4ca6819000-7f4ca6823000 r--p 00058000 00:52 3454 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.1.0
7f4ca6823000-7f4ca6825000 rw-p 00062000 00:52 3454 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.1.0
7f4ca6825000-7f4ca68a4000 r-xp 00000000 00:52 3100 /usr/lib/x86_64-linux-gnu/libgmp.so.10.3.0
7f4ca68a4000-7f4ca6aa3000 ---p 0007f000 00:52 3100 /usr/lib/x86_64-linux-gnu/libgmp.so.10.3.0
7f4ca6aa3000-7f4ca6aa4000 r--p 0007e000 00:52 3100 /usr/lib/x86_64-linux-gnu/libgmp.so.10.3.0
7f4ca6aa4000-7f4ca6aa5000 rw-p 0007f000 00:52 3100 /usr/lib/x86_64-linux-gnu/libgmp.so.10.3.0
7f4ca6aa5000-7f4ca6ad7000 r-xp 00000000 00:52 3452 /usr/lib/x86_64-linux-gnu/libhogweed.so.4.2
7f4ca6ad7000-7f4ca6cd6000 ---p 00032000 00:52 3452 /usr/lib/x86_64-linux-gnu/libhogweed.so.4.2
7f4ca6cd6000-7f4ca6cd7000 r--p 00031000 00:52 3452 /usr/lib/x86_64-linux-gnu/libhogweed.so.4.2
7f4ca6cd7000-7f4ca6cd8000 rw-p 00032000 00:52 3452 /usr/lib/x86_64-linux-gnu/libhogweed.so.4.2
7f4ca6cd8000-7f4ca6cdd000 r-xp 00000000 00:52 3450 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f4ca6cdd000-7f4ca6edc000 ---p 00005000 00:52 3450 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f4ca6edc000-7f4ca6edd000 r--p 00004000 00:52 3450 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f4ca6edd000-7f4ca6ede000 rw-p 00005000 00:52 3450 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f4ca6ede000-7f4ca6ee0000 r-xp 00000000 00:52 3448 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f4ca6ee0000-7f4ca70e0000 ---p 00002000 00:52 3448 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f4ca70e0000-7f4ca70e1000 r--p 00002000 00:52 3448 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f4ca70e1000-7f4ca70e2000 rw-p 00003000 00:52 3448 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f4ca70e2000-7f4ca70e9000 r-xp 00000000 00:52 3446 /usr/lib/x86_64-linux-gnu/libaec.so.0.0.3
7f4ca70e9000-7f4ca72e8000 ---p 00007000 00:52 3446 /usr/lib/x86_64-linux-gnu/libaec.so.0.0.3
7f4ca72e8000-7f4ca72e9000 r--p 00006000 00:52 3446 /usr/lib/x86_64-linux-gnu/libaec.so.0.0.3
7f4ca72e9000-7f4ca72ea000 rw-p 00007000 00:52 3446 /usr/lib/x86_64-linux-gnu/libaec.so.0.0.3
7f4ca72ea000-7f4ca7337000 r-xp 00000000 00:52 3444 /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.5
7f4ca7337000-7f4ca7536000 ---p 0004d000 00:52 3444 /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.5
7f4ca7536000-7f4ca7538000 r--p 0004c000 00:52 3444 /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.5
7f4ca7538000-7f4ca7539000 rw-p 0004e000 00:52 3444 /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2.10.5
7f4ca7539000-7f4ca753b000 rw-p 00000000 00:00 0
7f4ca753b000-7f4ca7548000 r-xp 00000000 00:52 3442 /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.5
7f4ca7548000-7f4ca7748000 ---p 0000d000 00:52 3442 /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.5
7f4ca7748000-7f4ca7749000 r--p 0000d000 00:52 3442 /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.5
7f4ca7749000-7f4ca774a000 rw-p 0000e000 00:52 3442 /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2.10.5
7f4ca774a000-7f4ca7791000 r-xp 00000000 00:52 3440 /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2
7f4ca7791000-7f4ca7990000 ---p 00047000 00:52 3440 /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2
7f4ca7990000-7f4ca7992000 r--p 00046000 00:52 3440 /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2
7f4ca7992000-7f4ca7994000 rw-p 00048000 00:52 3440 /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2
7f4ca7994000-7f4ca7ab7000 r-xp 00000000 00:52 3438 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.6.2
7f4ca7ab7000-7f4ca7cb6000 ---p 00123000 00:52 3438 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.6.2
7f4ca7cb6000-7f4ca7cc1000 r--p 00122000 00:52 3438 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.6.2
7f4ca7cc1000-7f4ca7cc3000 rw-p 0012d000 00:52 3438 /usr/lib/x86_64-linux-gnu/libgnutls.so.30.6.2
7f4ca7cc3000-7f4ca7cc4000 rw-p 00000000 00:00 0
7f4ca7cc4000-7f4ca7cf8000 r-xp 00000000 00:52 3436 /usr/lib/x86_64-linux-gnu/libnettle.so.6.2
7f4ca7cf8000-7f4ca7ef7000 ---p 00034000 00:52 3436 /usr/lib/x86_64-linux-gnu/libnettle.so.6.2
7f4ca7ef7000-7f4ca7ef9000 r--p 00033000 00:52 3436 /usr/lib/x86_64-linux-gnu/libnettle.so.6.2
7f4ca7ef9000-7f4ca7efa000 rw-p 00035000 00:52 3436 /usr/lib/x86_64-linux-gnu/libnettle.so.6.2
7f4ca7efa000-7f4ca7f15000 r-xp 00000000 00:52 3434 /usr/lib/x86_64-linux-gnu/librtmp.so.1
7f4ca7f15000-7f4ca8114000 ---p 0001b000 00:52 3434 /usr/lib/x86_64-linux-gnu/librtmp.so.1
7f4ca8114000-7f4ca8115000 r--p 0001a000 00:52 3434 /usr/lib/x86_64-linux-gnu/librtmp.so.1
7f4ca8115000-7f4ca8116000 rw-p 0001b000 00:52 3434 /usr/lib/x86_64-linux-gnu/librtmp.so.1
7f4ca8116000-7f4ca8147000 r-xp 00000000 00:52 3433 /usr/lib/x86_64-linux-gnu/libidn.so.11.6.15
7f4ca8147000-7f4ca8347000 ---p 00031000 00:52 3433 /usr/lib/x86_64-linux-gnu/libidn.so.11.6.15
7f4ca8347000-7f4ca8348000 r--p 00031000 00:52 3433 /usr/lib/x86_64-linux-gnu/libidn.so.11.6.15
7f4ca8348000-7f4ca8349000 rw-p 00032000 00:52 3433 /usr/lib/x86_64-linux-gnu/libidn.so.11.6.15
7f4ca8349000-7f4ca836a000 r-xp 00000000 00:52 3431 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f4ca836a000-7f4ca8569000 ---p 00021000 00:52 3431 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f4ca8569000-7f4ca856a000 r--p 00020000 00:52 3431 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f4ca856a000-7f4ca856b000 rw-p 00021000 00:52 3431 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f4ca856b000-7f4ca856d000 r-xp 00000000 00:52 2801 /usr/lib/x86_64-linux-gnu/libsz.so.2.0.1
7f4ca856d000-7f4ca876c000 ---p 00002000 00:52 2801 /usr/lib/x86_64-linux-gnu/libsz.so.2.0.1
7f4ca876c000-7f4ca876d000 r--p 00001000 00:52 2801 /usr/lib/x86_64-linux-gnu/libsz.so.2.0.1
7f4ca876d000-7f4ca876e000 rw-p 00002000 00:52 2801 /usr/lib/x86_64-linux-gnu/libsz.so.2.0.1
7f4ca876e000-7f4ca8777000 r-xp 00000000 00:52 2758 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1
7f4ca8777000-7f4ca8976000 ---p 00009000 00:52 2758 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1
7f4ca8976000-7f4ca8977000 r--p 00008000 00:52 2758 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1
7f4ca8977000-7f4ca8978000 rw-p 00009000 00:52 2758 /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.1
7f4ca8978000-7f4ca8982000 r-xp 00000000 00:52 2756 /usr/lib/x86_64-linux-gnu/libnuma.so.1.0.0
7f4ca8982000-7f4ca8b81000 ---p 0000a000 00:52 2756 /usr/lib/x86_64-linux-gnu/libnuma.so.1.0.0
7f4ca8b81000-7f4ca8b82000 r--p 00009000 00:52 2756 /usr/lib/x86_64-linux-gnu/libnuma.so.1.0.0
7f4ca8b82000-7f4ca8b83000 rw-p 0000a000 00:52 2756 /usr/lib/x86_64-linux-gnu/libnuma.so.1.0.0
7f4ca8b83000-7f4ca8ba3000 r-xp 00000000 00:52 2962 /usr/lib/x86_64-linux-gnu/libvtkCommonMath-6.2.so.6.2.0
7f4ca8ba3000-7f4ca8da3000 ---p 00020000 00:52 2962 /usr/lib/x86_64-linux-gnu/libvtkCommonMath-6.2.so.6.2.0
7f4ca8da3000-7f4ca8da4000 r--p 00020000 00:52 2962 /usr/lib/x86_64-linux-gnu/libvtkCommonMath-6.2.so.6.2.0
7f4ca8da4000-7f4ca8da5000 rw-p 00021000 00:52 2962 /usr/lib/x86_64-linux-gnu/libvtkCommonMath-6.2.so.6.2.0
7f4ca8da5000-7f4ca8dd1000 r-xp 00000000 00:52 2961 /usr/lib/x86_64-linux-gnu/libvtkCommonTransforms-6.2.so.6.2.0
7f4ca8dd1000-7f4ca8fd1000 ---p 0002c000 00:52 2961 /usr/lib/x86_64-linux-gnu/libvtkCommonTransforms-6.2.so.6.2.0
7f4ca8fd1000-7f4ca8fd3000 r--p 0002c000 00:52 2961 /usr/lib/x86_64-linux-gnu/libvtkCommonTransforms-6.2.so.6.2.0
7f4ca8fd3000-7f4ca8fd4000 rw-p 0002e000 00:52 2961 /usr/lib/x86_64-linux-gnu/libvtkCommonTransforms-6.2.so.6.2.0
7f4ca8fd4000-7f4ca9016000 r-xp 00000000 00:52 2965 /usr/lib/x86_64-linux-gnu/libvtksys-6.2.so.6.2.0
7f4ca9016000-7f4ca9216000 ---p 00042000 00:52 2965 /usr/lib/x86_64-linux-gnu/libvtksys-6.2.so.6.2.0
7f4ca9216000-7f4ca9217000 r--p 00042000 00:52 2965 /usr/lib/x86_64-linux-gnu/libvtksys-6.2.so.6.2.0
7f4ca9217000-7f4ca9218000 rw-p 00043000 00:52 2965 /usr/lib/x86_64-linux-gnu/libvtksys-6.2.so.6.2.0
7f4ca9218000-7f4ca9219000 rw-p 00000000 00:00 0
7f4ca9219000-7f4ca922a000 r-xp 00000000 00:52 2963 /usr/lib/x86_64-linux-gnu/libvtkCommonSystem-6.2.so.6.2.0
7f4ca922a000-7f4ca942a000 ---p 00011000 00:52 2963 /usr/lib/x86_64-linux-gnu/libvtkCommonSystem-6.2.so.6.2.0
7f4ca942a000-7f4ca942b000 r--p 00011000 00:52 2963 /usr/lib/x86_64-linux-gnu/libvtkCommonSystem-6.2.so.6.2.0
7f4ca942b000-7f4ca942c000 rw-p 00012000 00:52 2963 /usr/lib/x86_64-linux-gnu/libvtkCommonSystem-6.2.so.6.2.0
7f4ca942c000-7f4ca942d000 rw-p 00000000 00:00 0
7f4ca942d000-7f4ca9442000 r-xp 00000000 00:52 2960 /usr/lib/x86_64-linux-gnu/libvtkCommonMisc-6.2.so.6.2.0
7f4ca9442000-7f4ca9641000 ---p 00015000 00:52 2960 /usr/lib/x86_64-linux-gnu/libvtkCommonMisc-6.2.so.6.2.0
7f4ca9641000-7f4ca9642000 r--p 00014000 00:52 2960 /usr/lib/x86_64-linux-gnu/libvtkCommonMisc-6.2.so.6.2.0
7f4ca9642000-7f4ca9643000 rw-p 00015000 00:52 2960 /usr/lib/x86_64-linux-gnu/libvtkCommonMisc-6.2.so.6.2.0
7f4ca9643000-7f4ca965e000 r-xp 00000000 00:52 2894 /usr/lib/x86_64-linux-gnu/libvtkIOXMLParser-6.2.so.6.2.0
7f4ca965e000-7f4ca985d000 ---p 0001b000 00:52 2894 /usr/lib/x86_64-linux-gnu/libvtkIOXMLParser-6.2.so.6.2.0
7f4ca985d000-7f4ca985e000 r--p 0001a000 00:52 2894 /usr/lib/x86_64-linux-gnu/libvtkIOXMLParser-6.2.so.6.2.0
7f4ca985e000-7f4ca985f000 rw-p 0001b000 00:52 2894 /usr/lib/x86_64-linux-gnu/libvtkIOXMLParser-6.2.so.6.2.0
7f4ca985f000-7f4ca98ac000 r-xp 00000000 00:52 2933 /usr/lib/x86_64-linux-gnu/libvtkParallelCore-6.2.so.6.2.0
7f4ca98ac000-7f4ca9aab000 ---p 0004d000 00:52 2933 /usr/lib/x86_64-linux-gnu/libvtkParallelCore-6.2.so.6.2.0
7f4ca9aab000-7f4ca9aad000 r--p 0004c000 00:52 2933 /usr/lib/x86_64-linux-gnu/libvtkParallelCore-6.2.so.6.2.0
7f4ca9aad000-7f4ca9aae000 rw-p 0004e000 00:52 2933 /usr/lib/x86_64-linux-gnu/libvtkParallelCore-6.2.so.6.2.0
7f4ca9aae000-7f4ca9ab0000 r-xp 00000000 00:52 2533 /lib/x86_64-linux-gnu/libutil-2.23.so
7f4ca9ab0000-7f4ca9caf000 ---p 00002000 00:52 2533 /lib/x86_64-linux-gnu/libutil-2.23.so
7f4ca9caf000-7f4ca9cb0000 r--p 00001000 00:52 2533 /lib/x86_64-linux-gnu/libutil-2.23.so
7f4ca9cb0000-7f4ca9cb1000 rw-p 00002000 00:52 2533 /lib/x86_64-linux-gnu/libutil-2.23.so
7f4ca9cb1000-7f4ca9cd7000 r-xp 00000000 00:52 2818 /lib/x86_64-linux-gnu/libexpat.so.1.6.0
7f4ca9cd7000-7f4ca9ed7000 ---p 00026000 00:52 2818 /lib/x86_64-linux-gnu/libexpat.so.1.6.0
7f4ca9ed7000-7f4ca9ed9000 r--p 00026000 00:52 2818 /lib/x86_64-linux-gnu/libexpat.so.1.6.0
7f4ca9ed9000-7f4ca9eda000 rw-p 00028000 00:52 2818 /lib/x86_64-linux-gnu/libexpat.so.1.6.0
7f4ca9eda000-7f4ca9f4f000 r-xp 00000000 00:52 3095 /usr/lib/openmpi/lib/libopen-rte.so.12.0.2
7f4ca9f4f000-7f4caa14e000 ---p 00075000 00:52 3095 /usr/lib/openmpi/lib/libopen-rte.so.12.0.2
7f4caa14e000-7f4caa14f000 r--p 00074000 00:52 3095 /usr/lib/openmpi/lib/libopen-rte.so.12.0.2
7f4caa14f000-7f4caa152000 rw-p 00075000 00:52 3095 /usr/lib/openmpi/lib/libopen-rte.so.12.0.2
7f4caa152000-7f4caa154000 rw-p 00000000 00:00 0
7f4caa154000-7f4caa161000 r-xp 00000000 00:52 3092 /usr/lib/libibverbs.so.1.0.0
7f4caa161000-7f4caa361000 ---p 0000d000 00:52 3092 /usr/lib/libibverbs.so.1.0.0
7f4caa361000-7f4caa362000 r--p 0000d000 00:52 3092 /usr/lib/libibverbs.so.1.0.0
7f4caa362000-7f4caa363000 rw-p 0000e000 00:52 3092 /usr/lib/libibverbs.so.1.0.0
7f4caa363000-7f4caa3f3000 r-xp 00000000 00:52 2750 /usr/lib/openmpi/lib/libopen-pal.so.13.0.2
7f4caa3f3000-7f4caa5f3000 ---p 00090000 00:52 2750 /usr/lib/openmpi/lib/libopen-pal.so.13.0.2
7f4caa5f3000-7f4caa5f7000 r--p 00090000 00:52 2750 /usr/lib/openmpi/lib/libopen-pal.so.13.0.2
7f4caa5f7000-7f4caa5fb000 rw-p 00094000 00:52 2750 /usr/lib/openmpi/lib/libopen-pal.so.13.0.2
7f4caa5fb000-7f4caa600000 rw-p 00000000 00:00 0
7f4caa600000-7f4caa669000 r-xp 00000000 00:52 3429 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.4.0
7f4caa669000-7f4caa869000 ---p 00069000 00:52 3429 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.4.0
7f4caa869000-7f4caa86c000 r--p 00069000 00:52 3429 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.4.0
7f4caa86c000-7f4caa86d000 rw-p 0006c000 00:52 3429 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.4.0
7f4caa86d000-7f4caab00000 r-xp 00000000 00:52 2799 /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.10.1.0
7f4caab00000-7f4caacff000 ---p 00293000 00:52 2799 /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.10.1.0
7f4caacff000-7f4caad04000 r--p 00292000 00:52 2799 /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.10.1.0
7f4caad04000-7f4caad09000 rw-p 00297000 00:52 2799 /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.10.1.0
7f4caad09000-7f4caad0a000 rw-p 00000000 00:00 0
7f4caad0a000-7f4caad28000 r-xp 00000000 00:52 2805 /usr/lib/x86_64-linux-gnu/libhdf5_serial_hl.so.10.0.2
7f4caad28000-7f4caaf27000 ---p 0001e000 00:52 2805 /usr/lib/x86_64-linux-gnu/libhdf5_serial_hl.so.10.0.2
7f4caaf27000-7f4caaf28000 r--p 0001d000 00:52 2805 /usr/lib/x86_64-linux-gnu/libhdf5_serial_hl.so.10.0.2
7f4caaf28000-7f4caaf29000 rw-p 0001e000 00:52 2805 /usr/lib/x86_64-linux-gnu/libhdf5_serial_hl.so.10.0.2
7f4caaf29000-7f4caaf2a000 rw-p 00000000 00:00 0
7f4caaf2a000-7f4caaf2d000 r-xp 00000000 00:52 46 /lib/x86_64-linux-gnu/libdl-2.23.so
7f4caaf2d000-7f4cab12c000 ---p 00003000 00:52 46 /lib/x86_64-linux-gnu/libdl-2.23.so
7f4cab12c000-7f4cab12d000 r--p 00002000 00:52 46 /lib/x86_64-linux-gnu/libdl-2.23.so
7f4cab12d000-7f4cab12e000 rw-p 00003000 00:52 46 /lib/x86_64-linux-gnu/libdl-2.23.so
7f4cab12e000-7f4cab147000 r-xp 00000000 00:52 2535 /lib/x86_64-linux-gnu/libz.so.1.2.8
7f4cab147000-7f4cab346000 ---p 00019000 00:52 2535 /lib/x86_64-linux-gnu/libz.so.1.2.8
7f4cab346000-7f4cab347000 r--p 00018000 00:52 2535 /lib/x86_64-linux-gnu/libz.so.1.2.8
7f4cab347000-7f4cab348000 rw-p 00019000 00:52 2535 /lib/x86_64-linux-gnu/libz.so.1.2.8
7f4cab348000-7f4cab34f000 r-xp 00000000 00:52 2752 /lib/x86_64-linux-gnu/librt-2.23.so
7f4cab34f000-7f4cab54e000 ---p 00007000 00:52 2752 /lib/x86_64-linux-gnu/librt-2.23.so
7f4cab54e000-7f4cab54f000 r--p 00006000 00:52 2752 /lib/x86_64-linux-gnu/librt-2.23.so
7f4cab54f000-7f4cab550000 rw-p 00007000 00:52 2752 /lib/x86_64-linux-gnu/librt-2.23.so
7f4cab550000-7f4cab58e000 r-xp 00000000 00:52 3067 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0
7f4cab58e000-7f4cab78d000 ---p 0003e000 00:52 3067 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0
7f4cab78d000-7f4cab78e000 r--p 0003d000 00:52 3067 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0
7f4cab78e000-7f4cab78f000 rw-p 0003e000 00:52 3067 /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0
7f4cab78f000-7f4cab794000 r-xp 00000000 00:52 3053 /usr/lib/openmpi/lib/libmpi_usempi_ignore_tkr.so.6.1.0
7f4cab794000-7f4cab993000 ---p 00005000 00:52 3053 /usr/lib/openmpi/lib/libmpi_usempi_ignore_tkr.so.6.1.0
7f4cab993000-7f4cab994000 r--p 00004000 00:52 3053 /usr/lib/openmpi/lib/libmpi_usempi_ignore_tkr.so.6.1.0
7f4cab994000-7f4cab995000 rw-p 00005000 00:52 3053 /usr/lib/openmpi/lib/libmpi_usempi_ignore_tkr.so.6.1.0
7f4cab995000-7f4cab9c2000 r-xp 00000000 00:52 3050 /usr/lib/openmpi/lib/libmpi_usempif08.so.11.1.0
7f4cab9c2000-7f4cabbc1000 ---p 0002d000 00:52 3050 /usr/lib/openmpi/lib/libmpi_usempif08.so.11.1.0
7f4cabbc1000-7f4cabbc2000 r--p 0002c000 00:52 3050 /usr/lib/openmpi/lib/libmpi_usempif08.so.11.1.0
7f4cabbc2000-7f4cabbc3000 rw-p 0002d000 00:52 3050 /usr/lib/openmpi/lib/libmpi_usempif08.so.11.1.0
7f4cabbc3000-7f4cabcf8000 r-xp 00000000 00:52 2908 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7f4cabcf8000-7f4cabef8000 ---p 00135000 00:52 2908 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7f4cabef8000-7f4cabef9000 r--p 00135000 00:52 2908 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7f4cabef9000-7f4cabefd000 rw-p 00136000 00:52 2908 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7f4cabefd000-7f4cabf1b000 r-xp 00000000 00:52 3042 /usr/lib/x86_64-linux-gnu/libhdf5_openmpi_hl.so.10.0.2
7f4cabf1b000-7f4cac11a000 ---p 0001e000 00:52 3042 /usr/lib/x86_64-linux-gnu/libhdf5_openmpi_hl.so.10.0.2
7f4cac11a000-7f4cac11b000 r--p 0001d000 00:52 3042 /usr/lib/x86_64-linux-gnu/libhdf5_openmpi_hl.so.10.0.2
7f4cac11b000-7f4cac11c000 rw-p 0001e000 00:52 3042 /usr/lib/x86_64-linux-gnu/libhdf5_openmpi_hl.so.10.0.2
7f4cac11c000-7f4cac11d000 rw-p 00000000 00:00 0
7f4cac11d000-7f4cac3bf000 r-xp 00000000 00:52 3040 /usr/lib/x86_64-linux-gnu/libhdf5_openmpi.so.10.1.0
7f4cac3bf000-7f4cac5bf000 ---p 002a2000 00:52 3040 /usr/lib/x86_64-linux-gnu/libhdf5_openmpi.so.10.1.0
7f4cac5bf000-7f4cac5c4000 r--p 002a2000 00:52 3040 /usr/lib/x86_64-linux-gnu/libhdf5_openmpi.so.10.1.0
7f4cac5c4000-7f4cac5c9000 rw-p 002a7000 00:52 3040 /usr/lib/x86_64-linux-gnu/libhdf5_openmpi.so.10.1.0
7f4cac5c9000-7f4cac5cb000 rw-p 00000000 00:00 0
7f4cac5cb000-7f4cac604000 r-xp 00000000 00:52 2754 /usr/lib/x86_64-linux-gnu/libhwloc.so.5.6.8
7f4cac604000-7f4cac803000 ---p 00039000 00:52 2754 /usr/lib/x86_64-linux-gnu/libhwloc.so.5.6.8
7f4cac803000-7f4cac804000 r--p 00038000 00:52 2754 /usr/lib/x86_64-linux-gnu/libhwloc.so.5.6.8
7f4cac804000-7f4cac805000 rw-p 00039000 00:52 2754 /usr/lib/x86_64-linux-gnu/libhwloc.so.5.6.8
7f4cac805000-7f4cac9c4000 r-xp 00000000 00:52 48 /lib/x86_64-linux-gnu/libc-2.23.so
7f4cac9c4000-7f4cacbc4000 ---p 001bf000 00:52 48 /lib/x86_64-linux-gnu/libc-2.23.so
7f4cacbc4000-7f4cacbc8000 r--p 001bf000 00:52 48 /lib/x86_64-linux-gnu/libc-2.23.so
7f4cacbc8000-7f4cacbca000 rw-p 001c3000 00:52 48 /lib/x86_64-linux-gnu/libc-2.23.so
7f4cacbca000-7f4cacbce000 rw-p 00000000 00:00 0
7f4cacbce000-7f4cacedc000 r-xp 00000000 00:52 2964 /usr/lib/x86_64-linux-gnu/libvtkCommonCore-6.2.so.6.2.0
7f4cacedc000-7f4cad0dc000 ---p 0030e000 00:52 2964 /usr/lib/x86_64-linux-gnu/libvtkCommonCore-6.2.so.6.2.0
7f4cad0dc000-7f4cad0f4000 r--p 0030e000 00:52 2964 /usr/lib/x86_64-linux-gnu/libvtkCommonCore-6.2.so.6.2.0
7f4cad0f4000-7f4cad0fb000 rw-p 00326000 00:52 2964 /usr/lib/x86_64-linux-gnu/libvtkCommonCore-6.2.so.6.2.0
7f4cad0fb000-7f4cad0fc000 rw-p 00000000 00:00 0
7f4cad0fc000-7f4cad448000 r-xp 00000000 00:52 2959 /usr/lib/x86_64-linux-gnu/libvtkCommonDataModel-6.2.so.6.2.0
7f4cad448000-7f4cad647000 ---p 0034c000 00:52 2959 /usr/lib/x86_64-linux-gnu/libvtkCommonDataModel-6.2.so.6.2.0
7f4cad647000-7f4cad65c000 r--p 0034b000 00:52 2959 /usr/lib/x86_64-linux-gnu/libvtkCommonDataModel-6.2.so.6.2.0
7f4cad65c000-7f4cad66b000 rw-p 00360000 00:52 2959 /usr/lib/x86_64-linux-gnu/libvtkCommonDataModel-6.2.so.6.2.0
7f4cad66b000-7f4cad70f000 r-xp 00000000 00:52 2957 /usr/lib/x86_64-linux-gnu/libvtkCommonExecutionModel-6.2.so.6.2.0
7f4cad70f000-7f4cad90e000 ---p 000a4000 00:52 2957 /usr/lib/x86_64-linux-gnu/libvtkCommonExecutionModel-6.2.so.6.2.0
7f4cad90e000-7f4cad917000 r--p 000a3000 00:52 2957 /usr/lib/x86_64-linux-gnu/libvtkCommonExecutionModel-6.2.so.6.2.0
7f4cad917000-7f4cad919000 rw-p 000ac000 00:52 2957 /usr/lib/x86_64-linux-gnu/libvtkCommonExecutionModel-6.2.so.6.2.0
7f4cad919000-7f4cad98a000 r-xp 00000000 00:52 2936 /usr/lib/x86_64-linux-gnu/libvtkIOCore-6.2.so.6.2.0
7f4cad98a000-7f4cadb8a000 ---p 00071000 00:52 2936 /usr/lib/x86_64-linux-gnu/libvtkIOCore-6.2.so.6.2.0
7f4cadb8a000-7f4cadb8e000 r--p 00071000 00:52 2936 /usr/lib/x86_64-linux-gnu/libvtkIOCore-6.2.so.6.2.0
7f4cadb8e000-7f4cadb8f000 rw-p 00075000 00:52 2936 /usr/lib/x86_64-linux-gnu/libvtkIOCore-6.2.so.6.2.0
7f4cadb8f000-7f4cadb90000 rw-p 00000000 00:00 0
7f4cadb90000-7f4cadc30000 r-xp 00000000 00:52 2934 /usr/lib/x86_64-linux-gnu/libvtkIOLegacy-6.2.so.6.2.0
7f4cadc30000-7f4cade30000 ---p 000a0000 00:52 2934 /usr/lib/x86_64-linux-gnu/libvtkIOLegacy-6.2.so.6.2.0
7f4cade30000-7f4cade37000 r--p 000a0000 00:52 2934 /usr/lib/x86_64-linux-gnu/libvtkIOLegacy-6.2.so.6.2.0
7f4cade37000-7f4cade39000 rw-p 000a7000 00:52 2934 /usr/lib/x86_64-linux-gnu/libvtkIOLegacy-6.2.so.6.2.0
7f4cade39000-7f4cadf20000 r-xp 00000000 00:52 2893 /usr/lib/x86_64-linux-gnu/libvtkIOXML-6.2.so.6.2.0
7f4cadf20000-7f4cae120000 ---p 000e7000 00:52 2893 /usr/lib/x86_64-linux-gnu/libvtkIOXML-6.2.so.6.2.0
7f4cae120000-7f4cae12b000 r--p 000e7000 00:52 2893 /usr/lib/x86_64-linux-gnu/libvtkIOXML-6.2.so.6.2.0
7f4cae12b000-7f4cae12d000 rw-p 000f2000 00:52 2893 /usr/lib/x86_64-linux-gnu/libvtkIOXML-6.2.so.6.2.0
7f4cae12d000-7f4cae15c000 r-xp 00000000 00:52 2852 /usr/lib/x86_64-linux-gnu/libvtkIOParallelXML-6.2.so.6.2.0
7f4cae15c000-7f4cae35c000 ---p 0002f000 00:52 2852 /usr/lib/x86_64-linux-gnu/libvtkIOParallelXML-6.2.so.6.2.0
7f4cae35c000-7f4cae360000 r--p 0002f000 00:52 2852 /usr/lib/x86_64-linux-gnu/libvtkIOParallelXML-6.2.so.6.2.0
7f4cae360000-7f4cae361000 rw-p 00033000 00:52 2852 /usr/lib/x86_64-linux-gnu/libvtkIOParallelXML-6.2.so.6.2.0
7f4cae361000-7f4cae653000 r-xp 00000000 00:52 2812 /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
7f4cae653000-7f4cae853000 ---p 002f2000 00:52 2812 /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
7f4cae853000-7f4cae855000 r--p 002f2000 00:52 2812 /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
7f4cae855000-7f4cae8cc000 rw-p 002f4000 00:52 2812 /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
7f4cae8cc000-7f4cae8ef000 rw-p 00000000 00:00 0
7f4cae8ef000-7f4cae90b000 r-xp 00000000 00:52 3083 /usr/lib/x86_64-linux-gnu/libudunits2.so.0.1.0
7f4cae90b000-7f4caeb0b000 ---p 0001c000 00:52 3083 /usr/lib/x86_64-linux-gnu/libudunits2.so.0.1.0
7f4caeb0b000-7f4caeb0c000 r--p 0001c000 00:52 3083 /usr/lib/x86_64-linux-gnu/libudunits2.so.0.1.0
7f4caeb0c000-7f4caeb0d000 rw-p 0001d000 00:52 3083 /usr/lib/x86_64-linux-gnu/libudunits2.so.0.1.0
7f4caeb0d000-7f4caeb25000 r-xp 00000000 00:52 132 /lib/x86_64-linux-gnu/libpthread-2.23.so
7f4caeb25000-7f4caed24000 ---p 00018000 00:52 132 /lib/x86_64-linux-gnu/libpthread-2.23.so
7f4caed24000-7f4caed25000 r--p 00017000 00:52 132 /lib/x86_64-linux-gnu/libpthread-2.23.so
7f4caed25000-7f4caed26000 rw-p 00018000 00:52 132 /lib/x86_64-linux-gnu/libpthread-2.23.so
7f4caed26000-7f4caed2a000 rw-p 00000000 00:00 0
7f4caed2a000-7f4caed40000 r-xp 00000000 00:52 3079 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f4caed40000-7f4caef3f000 ---p 00016000 00:52 3079 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f4caef3f000-7f4caef40000 rw-p 00015000 00:52 3079 /lib/x86_64-linux-gnu/libgcc_s.so.1
7f4caef40000-7f4caeff2000 r-xp 00000000 00:52 2766 /usr/lib/openmpi/lib/libmpi.so.12.0.2
7f4caeff2000-7f4caf1f2000 ---p 000b2000 00:52 2766 /usr/lib/openmpi/lib/libmpi.so.12.0.2
7f4caf1f2000-7f4caf1f3000 r--p 000b2000 00:52 2766 /usr/lib/openmpi/lib/libmpi.so.12.0.2
7f4caf1f3000-7f4caf203000 rw-p 000b3000 00:52 2766 /usr/lib/openmpi/lib/libmpi.so.12.0.2
7f4caf203000-7f4caf216000 rw-p 00000000 00:00 0
7f4caf216000-7f4caf388000 r-xp 00000000 00:52 3074 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7f4caf388000-7f4caf588000 ---p 00172000 00:52 3074 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7f4caf588000-7f4caf592000 r--p 00172000 00:52 3074 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7f4caf592000-7f4caf594000 rw-p 0017c000 00:52 3074 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
7f4caf594000-7f4caf598000 rw-p 00000000 00:00 0
7f4caf598000-7f4caf5b0000 r-xp 00000000 00:52 3071 /usr/lib/openmpi/lib/libmpi_cxx.so.1.1.3
7f4caf5b0000-7f4caf7b0000 ---p 00018000 00:52 3071 /usr/lib/openmpi/lib/libmpi_cxx.so.1.1.3
7f4caf7b0000-7f4caf7b2000 r--p 00018000 00:52 3071 /usr/lib/openmpi/lib/libmpi_cxx.so.1.1.3
7f4caf7b2000-7f4caf7b3000 rw-p 0001a000 00:52 3071 /usr/lib/openmpi/lib/libmpi_cxx.so.1.1.3
7f4caf7b3000-7f4caf8bb000 r-xp 00000000 00:52 135 /lib/x86_64-linux-gnu/libm-2.23.so
7f4caf8bb000-7f4cafaba000 ---p 00108000 00:52 135 /lib/x86_64-linux-gnu/libm-2.23.so
7f4cafaba000-7f4cafabb000 r--p 00107000 00:52 135 /lib/x86_64-linux-gnu/libm-2.23.so
7f4cafabb000-7f4cafabc000 rw-p 00108000 00:52 135 /lib/x86_64-linux-gnu/libm-2.23.so
7f4cafabc000-7f4cafbe5000 r-xp 00000000 00:52 3060 /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0
7f4cafbe5000-7f4cafde4000 ---p 00129000 00:52 3060 /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0
7f4cafde4000-7f4cafde5000 r--p 00128000 00:52 3060 /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0
7f4cafde5000-7f4cafde7000 rw-p 00129000 00:52 3060 /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0
7f4cafde7000-7f4cafe3e000 r-xp 00000000 00:52 3057 /usr/lib/openmpi/lib/libmpi_mpifh.so.12.0.0
7f4cafe3e000-7f4cb003e000 ---p 00057000 00:52 3057 /usr/lib/openmpi/lib/libmpi_mpifh.so.12.0.0
7f4cb003e000-7f4cb003f000 r--p 00057000 00:52 3057 /usr/lib/openmpi/lib/libmpi_mpifh.so.12.0.0
7f4cb003f000-7f4cb0040000 rw-p 00058000 00:52 3057 /usr/lib/openmpi/lib/libmpi_mpifh.so.12.0.0
7f4cb0040000-7f4cb00b0000 r-xp 00000000 00:52 3035 /usr/lib/petscdir/3.6.3/linux-gnu-c-opt/lib/libmetis.so
7f4cb00b0000-7f4cb02af000 ---p 00070000 00:52 3035 /usr/lib/petscdir/3.6.3/linux-gnu-c-opt/lib/libmetis.so
7f4cb02af000-7f4cb02b0000 r--p 0006f000 00:52 3035 /usr/lib/petscdir/3.6.3/linux-gnu-c-opt/lib/libmetis.so
7f4cb02b0000-7f4cb02b1000 rw-p 00070000 00:52 3035 /usr/lib/petscdir/3.6.3/linux-gnu-c-opt/lib/libmetis.so
7f4cb02b1000-7f4cb03b5000 r-xp 00000000 00:52 2793 /usr/lib/x86_64-linux-gnu/libnetcdf.so.11.0.0
7f4cb03b5000-7f4cb05b5000 ---p 00104000 00:52 2793 /usr/lib/x86_64-linux-gnu/libnetcdf.so.11.0.0
7f4cb05b5000-7f4cb0603000 r--p 00104000 00:52 2793 /usr/lib/x86_64-linux-gnu/libnetcdf.so.11.0.0
7f4cb0603000-7f4cb0605000 rw-p 00152000 00:52 2793 /usr/lib/x86_64-linux-gnu/libnetcdf.so.11.0.0
7f4cb0605000-7f4cb3614000 rw-p 00000000 00:00 0
7f4cb3614000-7f4cb3653000 r-xp 00000000 00:52 3033 /usr/lib/petscdir/3.6.3/linux-gnu-c-opt/lib/libparmetis.so
7f4cb3653000-7f4cb3852000 ---p 0003f000 00:52 3033 /usr/lib/petscdir/3.6.3/linux-gnu-c-opt/lib/libparmetis.so
7f4cb3852000-7f4cb3853000 r--p 0003e000 00:52 3033 /usr/lib/petscdir/3.6.3/linux-gnu-c-opt/lib/libparmetis.so
7f4cb3853000-7f4cb3854000 rw-p 0003f000 00:52 3033 /usr/lib/petscdir/3.6.3/linux-gnu-c-opt/lib/libparmetis.so
7f4cb3854000-7f4cb38c2000 r-xp 00000000 00:52 3032 /usr/lib/libblas/libblas.so.3.6.0
7f4cb38c2000-7f4cb3ac1000 ---p 0006e000 00:52 3032 /usr/lib/libblas/libblas.so.3.6.0
7f4cb3ac1000-7f4cb3ac2000 r--p 0006d000 00:52 3032 /usr/lib/libblas/libblas.so.3.6.0
7f4cb3ac2000-7f4cb3ac3000 rw-p 0006e000 00:52 3032 /usr/lib/libblas/libblas.so.3.6.0
7f4cb3ac3000-7f4cb40b7000 r-xp 00000000 00:52 3027 /usr/lib/lapack/liblapack.so.3.6.0
7f4cb40b7000-7f4cb42b6000 ---p 005f4000 00:52 3027 /usr/lib/lapack/liblapack.so.3.6.0
7f4cb42b6000-7f4cb42b7000 r--p 005f3000 00:52 3027 /usr/lib/lapack/liblapack.so.3.6.0
7f4cb42b7000-7f4cb42bb000 rw-p 005f4000 00:52 3027 /usr/lib/lapack/liblapack.so.3.6.0
7f4cb42bb000-7f4cb54ba000 r-xp 00000000 00:52 2993 /usr/lib/petscdir/3.6.3/linux-gnu-c-opt/lib/libpetsc.so
7f4cb54ba000-7f4cb56ba000 ---p 011ff000 00:52 2993 /usr/lib/petscdir/3.6.3/linux-gnu-c-opt/lib/libpetsc.so
7f4cb56ba000-7f4cb56c3000 r--p 011ff000 00:52 2993 /usr/lib/petscdir/3.6.3/linux-gnu-c-opt/lib/libpetsc.so
7f4cb56c3000-7f4cb56df000 rw-p 01208000 00:52 2993 /usr/lib/petscdir/3.6.3/linux-gnu-c-opt/lib/libpetsc.so
7f4cb56df000-7f4cb58f1000 rw-p 00000000 00:00 0
7f4cb58f1000-7f4cb5917000 r-xp 00000000 00:52 36 /lib/x86_64-linux-gnu/ld-2.23.so
7f4cb593b000-7f4cb5ae1000 rw-p 00000000 00:00 0
7f4cb5b06000-7f4cb5b07000 rw-p 00000000 00:00 0
7f4cb5b07000-7f4cb5b08000 rwxp 00000000 00:00 0
7f4cb5b08000-7f4cb5b16000 rw-p 00000000 00:00 0
7f4cb5b16000-7f4cb5b17000 r--p 00025000 00:52 36 /lib/x86_64-linux-gnu/ld-2.23.so
7f4cb5b17000-7f4cb5b18000 rw-p 00026000 00:52 36 /lib/x86_64-linux-gnu/ld-2.23.so
7f4cb5b18000-7f4cb5b19000 rw-p 00000000 00:00 0
7ffc1a7f0000-7ffc1a85b000 rw-p 00000000 00:00 0 [stack]
7ffc1a8b7000-7ffc1a8b9000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
[c62e8389e039:01171] *** Process received signal ***
[c62e8389e039:01171] Signal: Aborted (6)
[c62e8389e039:01171] Signal code: (-6)
[c62e8389e039:01171] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x113e0)[0x7f4caeb1e3e0]
[c62e8389e039:01171] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x38)[0x7f4cac83a428]
[c62e8389e039:01171] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f4cac83c02a]
[c62e8389e039:01171] [ 3] /lib/x86_64-linux-gnu/libc.so.6(+0x777ea)[0x7f4cac87c7ea]
[c62e8389e039:01171] [ 4] /lib/x86_64-linux-gnu/libc.so.6(+0x7fe0a)[0x7f4cac884e0a]
[c62e8389e039:01171] [ 5] /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f4cac88898c]
[c62e8389e039:01171] [ 6] fluidity(_ZN4Spud13OptionManager6OptionD1Ev+0x134)[0xcbc884]
[c62e8389e039:01171] [ 7] fluidity(_ZN4Spud13OptionManager6OptionD1Ev+0x49)[0xcbc799]
[c62e8389e039:01171] [ 8] fluidity(_ZN4Spud13OptionManager6OptionD1Ev+0x49)[0xcbc799]
[c62e8389e039:01171] [ 9] fluidity(_ZN4Spud13OptionManager6OptionD1Ev+0x49)[0xcbc799]
[c62e8389e039:01171] [10] fluidity(_ZN4Spud13OptionManagerD1Ev+0x17)[0xcbc9a7]
[c62e8389e039:01171] [11] /lib/x86_64-linux-gnu/libc.so.6(+0x39ff8)[0x7f4cac83eff8]
[c62e8389e039:01171] [12] /lib/x86_64-linux-gnu/libc.so.6(+0x3a045)[0x7f4cac83f045]
[c62e8389e039:01171] [13] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf7)[0x7f4cac825837]
[c62e8389e039:01171] [14] fluidity(_start+0x29)[0x4ac369]
[c62e8389e039:01171] *** End of error message ***
Aborted

It looks like 317a728 accidentally committed some configured Makefiles to master in assemble and assemble/tests.

In the netcdf_read_* tests and the ERA python diagnostic script, tests for scipy version do a string comparison between scipy.version.version and '0.9.0' to check whether Scientific functionality is present as required in scipy. This fails on versions >= 0.10.0 as the versions lack leading zeros.

Following recent discussion during a pull request, the question of adding a .gitignore file system to the repository has come up. While this might be convenient for developers (depending on their workflow choices) there are obvious risks of encouraging lazy behaviour and bad housekeeping through through a poorly formatted selection. As such I propose the following as a starting point for discussion

root .gitignore file

### Various OS files

## OS X related
.DS_Store
.AppleDouble
.LSOverride
._*

## Linux related
*~

## Emacs files
# -*- mode: gitignore; -*-
\#*\#
/.emacs.desktop
/.emacs.desktop.lock
*.elc
auto-save-list
tramp
.\#*


 ### Python related files
 # Byte-compiled / optimized / DLL files
 __pycache__/
*.py[cod]

# C extensions
*.o
*.so

# Fortran extensions
*.mod

### directories
bin/
include/*.*
lib/

manual/.gitignore file

## Core latex/pdflatex auxiliary files:
*.aux
*.lof
*.log
*.lot
*.fls
*.out
*.toc

## Intermediate documents:
*.dvi


## Bibliography auxiliary files (bibtex/biblatex/biber):
*.bbl
*.bcf
*.blg
*-blx.aux
*-blx.bib
*.brf
*.run.xml


 # makeidx
*.idx
*.ilg
*.ind
*.ist

tests/.gitignore file

#temporary files created for tests
*.msh

In a previous issue ( #113 ) @ggorman suggested migrating fluidity to use CMake as its build system would make some of our support issues (particularly VTK) easier. Over the long weekend I've been experimenting with getting a working build together (see the branch https://github.com/FluidityProject/fluidity/tree/cmake_build). It's not finished yet, and brought up some other issues I'll be questioning shortly, but to summarise my findings so far:

1. VTK is indeed really easy, and PETSc isn't too nasty either
2. The language syntax makes a bit little bit more sense as a new user than autoconf, and feels a bit more like a programming exercise
3. The cross-compiler and cross-platform support is good,

however, as @stephankramer said, debugging is annoying and it's unclear which of multiple routes is the best way to pass a given flag to a given compiler.

I'm assuming this will be a won't fix, but I thought I'd open this to further discussion, particularly in the case that there's interest in having an experimental or unsupported CMake build scheme available for people on weird systems.

When using extrusion to generate the initial mesh in combination with general adaptivity (so no vertically_structured_adaptivity) a number of things can go wrong, as the base mesh becomes a separate un-adapted mesh after the first adapt. This is easy to break in the code, so it should be tested. Should also add an options check to ensure the base mesh has the exclude_from_adaptivity option.

Just to put this on record. Our issues with Intel and reading GMSH files has been reported. You can keep track of it here:

https://software.intel.com/en-us/forums/topic/534662

Hopefully there will be a fix soon, although our workaround seems to be fine at present.

I think a recent change to the configure script, line 1320, causes a build failure for old versions of GCC (< 4.8) that don't have the "-fno-aggressive-loop-optimizations" flag. Any chance we could test for the GCC version here?

This was reported by @anguscr on the fluidity mailing list:

In relation to recent mailing list discussions, if you've tried having a variable number of layers in a tidal simulation, the (re-)partitioned extruded meshes can have relative sizes quite outside the Zoltan tolerance levels (eg. 4:1).

Luckily the fix is quite straightforward -- in assemble/Zoltan_callbacks.F90, go to the following lines in zoltan_cb_owned_node_count():

   do i = 1, count
        obj_wgts(i) =obj_wgts(i)/max_obj_wgt
   end do

And either delete them or comment them out. I've tested the fix, and it's given me a decent speedup (2x).

Object weighting in Zoltan doesn't need to be normalised, and the above gives you a globally (rather than locally) valid column weighting without mpi_allreduce(). I'd patch the trunk myself but I've got a proposal deadline..

My OS is Centos6.7 64bit
I have installed fluidity in my computer with "yum install fuidity" , it told me flnished
but when I run fluidity with ,there is an error ,it seems like there is something wrong with openmpi

fluidity: symbol lookup error: /usr/lib64/openmpi/lib/libptscotch.so.0: undefined symbol: _SCOTCHorderSaveTree

Building on Ubuntu 14.04 with Intel 2015 compilers and running 'make unittest', the femtools tests fail to build test_find_node_ownership_af.F90 with error as below. Similar errors occur with _if.F90, and _rtree.F90.

I have a built container which I can make available via private dockerhub repository for testing this; contact me directly if you need access.

Error is:

mpif90 -I../../include -vec-report=0 -DHAVE_NUMPY -I/usr/lib64/python2.6/site-packages/numpy/core/include -extend_source -O3 -ip -xHost -I/usr/include -I/usr/include -I/usr/include -I/opt/intel/impi/5.0.3.049/intel64/include -I/opt/intel//impi/5.0.3.049/intel64/include -Iinclude/ -r8 -I/usr/include/vtk -I/usr/include/python2.6 -DHAVE_NUMPY -I/usr/lib64/python2.6/site-packages/numpy/core/include -I/usr/include -I/usr/include -I/usr/include -I/opt/intel/impi/5.0.3.049/intel64/include -I/opt/intel//impi/5.0.3.049/intel64/include -Iinclude/ -DHAVE_PETSC -I/usr/include/vtk -DHAVE_VTK=1 -DHAVE_VTK=1 -I../ -c test_find_node_ownership_af.F90
ifort: command line remark #10010: option '-vec-report=0' is deprecated and will be removed in a future release. See '-help deprecated'
test_find_node_ownership_af.F90(41): error #6450: This name has already been used as an external module name. [NODE_OWNERSHIP]
integer, dimension(:), allocatable :: l_coords, node_ownership
--------------------------------------------------^
test_find_node_ownership_af.F90(48): error #6450: This name has already been used as an external module name. [NODE_OWNERSHIP]
allocate(node_ownership(node_count(positions2)))
-----------^
test_find_node_ownership_af.F90(49): error #6450: This name has already been used as an external module name. [NODE_OWNERSHIP]
call find_node_ownership_af(positions1, positions2, node_ownership)
------------------------------------------------------^
test_find_node_ownership_af.F90(51): error #6337: This is not a valid lvalue or rvalue. [NODE_OWNERSHIP]
call report_test("[All node owners found]", any(node_ownership < 0), .false., "Not all node owners found")
--------------------------------------------------^
test_find_node_ownership_af.F90(51): error #6361: An array-valued argument is required in this context. [ANY]
call report_test("[All node owners found]", any(node_ownership < 0), .false., "Not all node owners found")
-----------------------------------------------------------------^
test_find_node_ownership_af.F90(53): error #6337: This is not a valid lvalue or rvalue. [NODE_OWNERSHIP]
call report_test("[Correct map size]", size(node_ownership) /= node_count(positions2), .false., "Incorrect map size")
----------------------------------------------^
test_find_node_ownership_af.F90(53): error #6361: An array-valued argument is required in this context. [SIZE]
call report_test("[Correct map size]", size(node_ownership) /= node_count(positions2), .false., "Incorrect map size")
----------------------------------------------^
test_find_node_ownership_af.F90(56): error #6450: This name has already been used as an external module name. [NODE_OWNERSHIP]
allocate(l_coords(ele_loc(positions1, node_ownership(i))))
------------------------------------------^
test_find_node_ownership_af.F90(56): error #6284: There is no matching specific function for this generic function reference. [ELE_LOC]
allocate(l_coords(ele_loc(positions1, node_ownership(i))))
----------------------^
test_find_node_ownership_af.F90(56): error #6385: The highest data type rank permitted is INTEGER(KIND=8). [ELE_LOC]
allocate(l_coords(ele_loc(positions1, node_ownership(i))))
----------------------^
test_find_node_ownership_af.F90(57): error #6450: This name has already been used as an external module name. [NODE_OWNERSHIP]
l_coords = local_coords(positions1, node_ownership(i), node_val(positions2, i))
----------------------------------------^
test_find_node_ownership_af.F90(57): error #6284: There is no matching specific function for this generic function reference. [LOCAL_COORDS]
l_coords = local_coords(positions1, node_ownership(i), node_val(positions2, i))
---------------^
test_find_node_ownership_af.F90(66): error #6450: This name has already been used as an external module name. [NODE_OWNERSHIP]
deallocate(node_ownership)
-------------^
compilation aborted for test_find_node_ownership_af.F90 (code 1)
make: *** [test_find_node_ownership_af.o] Error 1
rm test_find_node_ownership_af_main.o
[fluidity@7f0c51fa0551 tests]$

I'm hoping @agbuchan can provide more information and @fmilthaler is available to confirm the problem and the fix, but it appears that the current exodusII mesh reading code fails with Trellis 16 (the new name for cubit).

Comparing files output from the two versions, it seems the difference is that the newer version prescribes a local node which is not simply an enumeration of the nodes. Based on the limited documentation I can find, this is actually information needed by Trellis itself, rather than necessary to generate the geometry.

Faking the array to be in the original order appears to clear the problem (see branch 5cf18f9) but this actually suggests that the reader implementation is currently more complicated than it needs to be.