Double exports in TXTExport

User Support
1

Running this code

import festim as F
import numpy as np
import sympy as sp
from matplotlib import pyplot as plt

C_0 = 1 # atom m^-3
D = 1 # 1 m^2 s^-1
profile_time = 25 # s
exact_solution = C_0 * (1 - sp.erf(F.x / sp.sqrt(4*D*F.t)))

model = F.Simulation()

### Mesh Settings ###
vertices = np.concatenate([
    np.linspace(0, 1, 100),
    np.linspace(1, 20, 200),
])

model.mesh = F.MeshFromVertices(vertices)

model.boundary_conditions = [
    F.DirichletBC(surfaces=[1], value=C_0, field="solute")
]

model.materials = [F.Material(id=1, D_0=D, E_D=0)]

model.T = F.Temperature(500)  # ignored in this problem

model.dt = F.Stepsize(
    initial_value=0.01,
    stepsize_change_ratio=1.1,
    milestones=[profile_time]
)

model.settings = F.Settings(
    absolute_tolerance=1e-10,
    relative_tolerance=1e-10,
    final_time=30
)

test_point_x = 0.45
derived_quantities = F.DerivedQuantities(
    [F.PointValue("solute", x=test_point_x)]
)
model.exports = [
    derived_quantities, 
    F.TXTExport(
        field="solute", 
        filename="./tmap_1b_concentration.txt",
        times=[profile_time]
    ),
]

model.initialise()
model.run()

gets me a .txt where every x except for 0 and 20 (the endpoints) appears twice with slightly different values, always 3 rows apart.

Example:
image

Why could this be?

2

Hey @jairrs

I think this is happening because there’s no node in the mesh at the point x=0.45, just need to increase the number of divisions by a further one and you should have a node at that location:

vertices = np.concatenate([
    np.linspace(0, 1, 101),
    np.linspace(1, 20, 200),
])
3

I don’t think the issue is related to x=0.45 but rather to the TXT export duplicating some lines. Maybe @VVKulagin has some hints?

4

Actually I think this is due to a DG projection in TXTExport. I don’t think there is anything we can do about this.

If we want to get rid of that we could at least make sure that values are sorted by x

We could also expose the finite element to the users in the export

5

It’s indeed related to the DG projection.

6

@jairrs this is the explanation of what is going on:

Since we sometimes have discontinuous mobile concentration profiles (when we have dissimilar materials) then we need to project the field on a discontinuous functionspace to capture the discontinuities. This is done by using DG (Discontinuous Galerkin) elements.

A single DG element has the same number of degrees of freedom than a CG element but for CG, the dofs are shared on the edged (see below).

image

This is why you see duplicated x coordinates with slightly different concentration values.

Several things you can do to get around this:

  • sort the values according to x (this could potentially be done in FESTIM…)
  • remove duplicated nodes with numpy unique np.unique or something similar.
7

I believe FESTIM should handle this. I don’t see any benefit to letting the user choose which concentration they want to use, and having both is confusing.

8

Yes, these were just workarounds while we implement a proper fix.

First up these duplicates should be very similar to like the 10th digit! So just picking one or the other should not change the results whatsoever.

The thing is you do need to have both since when you have an interface, you want to know which is the concentration on both sides of the interface.

I guess the internal FESTIM process should be:

  1. if there is only one material (or no conservation of chemical potential) then project to CG instead of DG
  2. If there are interfaces, since TXTExport is only used in 1D, project to DG but only keep the duplicates where there are interfaces (based on the materials border argument)
1 Like
9

This issue should be resolved in the next 1.4 release. See this PR for the details on the updated behavior of TXTExport.