The order of mesh coordinates in FEniCS output files viewed in Paraview

Question

I have a fenics based python code. I created a bash script which generates random numbers with a gaussian distribution, and assigns them to my code as an input value for Youngs Modulus - 'E'. For eg. the mean of my 'E' is 100MPa, and the coefficient of variation is 40%. So if I generate 100 random numbers, my code will run for 100 different values of 'E', and store 100 different folders with vtk solutions in them. This is exactly like Monte Carlo method.

• I generated 100 samples for 'E' value and that gave me 100 vtk files.
• I converted these 100 vtk files to 100 csv (comma separated value) files.
• I imported all of these csv files in matlab.

Here is the link to some of these csv files:

https://github.com/ChaitanyaGoyal/CSV-files

You can observe that the first 3 columns contain the solution vectors in x,y, and z direction, while the last 3 columns contain the node coordinates. Column 3 and 6 are zero because this is a 2D simulation. Hence only 'x' and 'y' exist. The total no. of rows should be equal to the no. of nodes on the mesh. So I was interested in extracting column 1 and 2 for some further processing for each of the 100 outputs.

Now, the matlab script that I created for processing the solution vectors in 1st and 2nd column and was based on the assumption that the 4th and 5th columns of csv file which contain the x and y coordinate will remain in same order for all these csv files. That will enable me to compare solution vectors 'x' and 'y' (column 1 and 2), for all 100 samples in my script. I thought this was obvious because its the same mesh being used every time. However, I just observed that column 4 and 5 are not the same for different csv files. Not only are the node coordinates in column '4' and '5', in different order for different csv files, but even the total no. of coordinates (i.e, the no. of rows in csv) is different for some cases. This observation has messed up everything now. I needed consistent matrices with common '4th and 5th' columns, and with same no. of rows. How was I to expect that I will get different no. of rows (i.e. nodes) for running a problem 100 times on the exact same mesh, with a different parameter value.

Is there a way to fix this? Any suggestions will be highly appreciated.

Comments

If you are using the python interface of dolfin you can do something like this (to avoid the step of paraview):

from dolfin import *
import numpy as np

mesh = UnitSquareMesh(10, 10)
V = FunctionSpace(mesh, "CG", 1)
u = interpolate(Expression("x[0]*x[1]"), V)

X = V.dofmap().tabulate_all_coordinates(mesh)
X.resize((V.dim(), 2))

x = X[:,0]
y = X[:,1]
values  = u.vector().array()

np.savetxt("foo.csv", np.c_[x, y, values], delimiter=",")

In the cpp interface something similar can be done using proper libraries and writing a simple function as here.

---

Thanks a lot for your suggestion on generation of csv directly from fenics. The main problem lies in getting this to work while running in parallel. I have also sent you a detailed email regarding the same.

Answer 1

The problem is now solved. It was an interesting learning experience. I observed that the unstructured behaviour was a result of parallel running on high resolution mesh with high no. of processors. I ran many cases for static and dynamic problems for different mesh sizes on different no. of processors, and this behaviour was observed only when mesh resolution was above average AND the minimum no. of cores was 16 or above. The extra no. of rows in the CSV can be attributed to the repetition of nodes from the boundaries of adjacent subdomains.

I created a MATLAB script which first removed the extra repetitive nodes (rows), and brought the no. of rows to the actual no. of nodes on the mesh (for all csv files). Then it sorted the 'x' and 'y' coordinate values for all CSV files and aligned the rows in perfect order which could be used at a later stage to generate vtk files from MATLAB for the resultant vectors.