Projection into DG1 x CG1 space looks wrong - #211
Conversation
|
Can you wrap your code in ``` marks? Otherwise, some characters (notably '*') are interpreted as formatting, so your code comes out with random italics, and lacking characters. |
|
Probably a dmplex thing, one sec.... |
|
Nope, my first idea didn't work. |
|
Note that dmplex changed the interval numbering from |
|
I'm going to check this for DG as well, and will make a failing test. |
|
Some further experimentation indicates that this is probably a bug with the vtu output, not FFC. |
|
There are three bugs here.
from firedrake import *
m = PeriodicUnitIntervalMesh(4)
V = FunctionSpace(m, 'CG', 1)
print m.coordinates.dat.data
u = Function(V)
# Interpolate does this:
to_element = V.fiat_element
to_pts = []
for dual in to_element.dual_basis():
to_pts.append(dual.pt_dict.keys()[0])
coords = m.coordinates
coords_space = coords.function_space()
coords_element = coords_space.fiat_element
X = coords_element.tabulate(0, to_pts).values()[0]
for cell in range(4):
for k in range(2):
print cell, u.cell_node_map().values[cell][k], sum([X.T[k][i] * coords.dat.data[coords.cell_node_map().values[cell]][i] for i in range(2)])
u.dat.data[u.cell_node_map().values[cell][k]] = sum([X.T[k][i] * coords.dat.data[coords.cell_node_map().values[cell]][i] for i in range(2)])
print u.dat.dataI expect to see |
|
Actual output: This is after I have fixed bug 2. |
|
Michael, this seems to be a hangover from the move to dmplex due to facet numbering. I'm lost in a world of cones, all alike. Can you take a look? |
|
OK, the cell numbering in the UnitInterval Plex does not agree with the cell numbering of the periodic coordinates: Plex does 0, 1, ..., c, but the periodic coordinates are written for 0, c, 2, 3, ..., c-1. |
|
I think I have a fix for this. Will push when I get home. It's really ugly though. Colin, once I update, can you have another go with various pieces , or suggest done better ways if testing for breakages other than computing areas. I can think of some simple minded things computing interior facet integrals dotted against facet normals but there must be others. |
|
fix/periodic does this, I think. But I need to think harder, I'm not really sure what's going on. |
The test for if they were CG or not was wrong.
Ugly hack until we get fed it from DMPlex. Note that this is probably wrong when symbolic geometry stuff lands.
|
I /think/ this is fixed by this branch. But I would like some very careful eyes over this bit of the code. Here's a summary of various bits and pieces I have noticed.
|
|
I believe the hack to be correct, if aesthetically vile. |
|
Is there a good reason why the last cell is reversed? |
|
And are you implying some new/modified FFC code snippets for the facet normals? :) |
|
All existing facet normal code still passes with this change. So one might need some new code, but no existing code needs changing. Note that there are basically no tests of facets on periodic, so things may still be broken there. The last cell needs to be reversed so that the coordinate field lines up with the numbering. That's not a good reason, I can draw some pictures tomorrow if you'd like. |
|
Believeable. |
- Fix the coordinate field for periodic interval - Fix some corner cases in VTU output
|
Merged and hopefully fixed. Please, however, keep a keen eye on the periodic pieces, especially facets when they arrive, because these are still only very lightly tested. |
The following code:
produces a field where the slopes in each element go the wrong way. This can most easily be observed by opening the file in Paraview and selecting Filters -> Warp by Scalar, then clicking Apply.
Is something wrong with the numbering perhaps?