New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MappingQEulerian produces strange results in 2-d #2206
Comments
Interesting. Is the displacement field based on a discontinuous finite element? |
No it is not - we use |
What's the way to reproduce this problem? |
I'll see if I can bash out a small testcase later this evening :-) |
Unfortunately I haven't been able to reproduce the issue thus far. The test below works for polynomial degree 1 and 2. I can't imagine that the pathology is somehow specifically related to the solution generated in #include <deal.II/base/tensor.h>
#include <deal.II/dofs/dof_handler.h>
#include <deal.II/fe/fe_q.h>
#include <deal.II/fe/fe_system.h>
#include <deal.II/fe/mapping_q_eulerian.h>
#include <deal.II/grid/tria.h>
#include <deal.II/grid/tria_accessor.h>
#include <deal.II/grid/tria_iterator.h>
#include <deal.II/grid/grid_generator.h>
#include <deal.II/lac/vector.h>
#include <deal.II/numerics/data_out.h>
#include <iostream>
#include <fstream>
#include <vector>
#include <string>
using namespace dealii;
template<int dim>
void MapQE (void)
{
const unsigned int degree = 2; // Works for degree 1 as well
const unsigned int n_global_refinements = 2; // Use 3 refinement levels for degree 1
Triangulation<dim> triangulation;
GridGenerator::hyper_cube (triangulation,-1,1);
triangulation.refine_global (n_global_refinements); // Use 3 refinement levels for degree 1
const FESystem<dim> fe (FE_Q<dim> (degree), dim);
DoFHandler<dim> dof_handler (triangulation);
dof_handler.distribute_dofs (fe);
Vector<double> soln (dof_handler.n_dofs());
// Apply grid deformation
Tensor<2,dim> grad_u;
grad_u[0][0] = 0.1;
grad_u[0][1] = 0.2;
grad_u[1][0] = 0.3;
grad_u[1][1] = 0.4;
if (dim == 3)
{
grad_u[0][2] += 0.5;
grad_u[2][0] += 0.6;
grad_u[1][2] += 0.7;
grad_u[2][1] += 0.8;
grad_u[2][1] += 0.9;
}
Quadrature<dim> q_cell (fe.get_unit_support_points());
FEValues<dim> fe_values (fe, q_cell, update_q_points);
typename DoFHandler<dim>::active_cell_iterator
cell = dof_handler.begin_active(),
endc = dof_handler.end();
for (; cell!=endc; ++cell)
{
fe_values.reinit(cell);
std::vector<types::global_dof_index> local_dof_indices(fe.dofs_per_cell);
cell->get_dof_indices(local_dof_indices);
for (unsigned int I=0; I<fe.dofs_per_cell; ++I)
{
const unsigned int component_I = fe.system_to_component_index(I).first;
const Point<dim> X = fe_values.get_quadrature_points()[I];
const Tensor<1,dim> x = grad_u*X;
soln(local_dof_indices[I]) = x[component_I];
}
}
// Without mapping
{
DataOut<dim> data_out;
data_out.attach_dof_handler (dof_handler);
data_out.add_data_vector (soln,
std::vector<std::string> (dim, "displacement"),
DataOut<dim>::type_dof_data,
std::vector<DataComponentInterpretation::DataComponentInterpretation> (dim, DataComponentInterpretation::component_is_part_of_vector));
data_out.build_patches (degree);
const std::string filename
= std::string("solution-")
+ Utilities::int_to_string(dim)
+ std::string("d-001.vtk");
std::ofstream output (filename);
data_out.write_vtk (output);
}
// With mapping
{
DataOut<dim> data_out;
data_out.attach_dof_handler (dof_handler);
data_out.add_data_vector (soln,
std::vector<std::string> (dim, "displacement"),
DataOut<dim>::type_dof_data,
std::vector<DataComponentInterpretation::DataComponentInterpretation> (dim, DataComponentInterpretation::component_is_part_of_vector));
MappingQEulerian<dim> q_mapping(degree, dof_handler, soln);
data_out.build_patches(q_mapping, degree);
const std::string filename
= std::string("solution-")
+ Utilities::int_to_string(dim)
+ std::string("d-002.vtk");
std::ofstream output (filename);
data_out.write_vtk (output);
}
}
int main()
{
deallog.depth_console(0);
std::cout << std::setprecision(10);
MapQE<2>();
// MapQE<3>();
} |
Thanks for trying to come up with something that helps us reproduce this in a smaller setting. From the pictures, is it conceivable that in the output the y-coordinate of every point is computed correctly but the x-coordinate is not? Just trying to poke in the dark here... |
Spurred on by a new question in the forum, here's another attempt at a MWE. It produces a displaced grid for a single and multi-field "problem". Edit: Removed erroneous code and results. See updated code in this comment. |
what exactly does not work here? The comment part of the code looks ok to me. |
@jppelteret as for the project in three-field case, what you do looks fine as well:
however it should also be possible just to wrap everything (displacement, pressure, dilatation) into a single |
@davydden Re your last comment: Sure, I agree. I picked this up from some other tests I've been writing, so its a minimal transfer from another test-case to this. |
@davydden Thanks for doing a sanity check on the code I posted. Edit: Removed erroneous results. See updated code in this comment. |
@jppelteret let's chat about this on Monday unless someone will give a solution during the weekend. |
Sure, as I said it was a quick attempt to see if I could concretely nail down the issue. If someone can spot an obvious flaw in what I posted I'd be happy to hear about it! But, again, I myself haven't put too much thought into what's going on here. |
Found the problem: values[first_u_component+0] = X[0]*X[0]*X[1];
values[first_u_component+1] = X[1]*X[1]*X[0]; should be values[p][first_u_component+0] = X[0]*X[0]*X[1];
values[p][first_u_component+1] = X[1]*X[1]*X[0]; I'll update the MWE accordingly and double check the results. |
@jppelteret so in the updated MWE we only need |
Could this have something to do with this issue: https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#in-my-graphical-output-the-solution-appears-discontinuous-at-hanging-nodes ? |
@bangerth AFAICT there are no hanging nodes here. |
@davydden For the purpose of this particular issue, yes, we only need Serendipitously the other test The issue appears to be there's some expectation that one has called I've attached a complete set of code and results for anyone who is interested to peruse. |
@davydden I forgot to add that everything does appear to be working as expected for |
@davydden and I believe that this has something to do with |
@jppelteret -- do you think you can whittle this down further to just a few elements (say, 2x2)? That would greatly help debug the issue. |
Sure, I’ll try my best to do so!
… On 23 Jan 2017, at 17:18, Wolfgang Bangerth ***@***.***> wrote:
@jppelteret <https://github.com/jppelteret> -- do you think you can whittle this down further to just a few elements (say, 2x2)? That would greatly help debug the issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#2206 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ-dwpREAIvR-P98tulAKWrq0VVwjapEks5rVNLAgaJpZM4HcABB>.
|
@bangerth Attached is the smallest MWE that I could produce. The most simplified conditions that I could make reproduce the error are
Strangely, the problem does not manifest itself when the global refinement level is 1 (even if a quadratic FE is used). Also, the deformation map has to be nonlinear (or, at least not the linear map I tried). |
Checking the code, this will be solved by replacing
by
After tackling #12423 (this one is a manifestation that we should use the new variant without |
From testing #2205, I've found that using MappingQEularian in conjunction with DataOut in 2-d produces an incompatible displacement field. Attached is an example of this result that illustrates tearing that is not really there. This is a single material with the geometry formed by the GridGenerator::hyper_rectangle function, so all elements are definitely properly connected. Applying the warp function in Paraview renders the right result.
The text was updated successfully, but these errors were encountered: