Something Wrong with Displaced Outputs

[Liuux]

When I deal with some problems with displaced mesh,the outputs given by serial and parallel computation are different.The serial outputs are OK,but the parallel outputs have some problems. The example below shows the differences between serial and parallel outputs.This example comes from the MOOSE tests. The .i file is as below: [Mesh] dim = 2 file = square.e uniform_refine = 3 displacements = 'u aux_v' [] [Functions] [./aux_v_fn] type = ParsedFunction value = x*(y-0.5)/5 [../] [] [Variables] [./u] order = FIRST family = LAGRANGE [../] [./v] order = FIRST family = LAGRANGE [../] [] [Kernels] active = 'udiff uie vdiff vconv vie' [./udiff] type = Diffusion variable = u [../] [./uie] type = TimeDerivative variable = u [../] [./vdiff] type = Diffusion variable = v [../] [./vconv] type = Convection variable = v velocity = '-10 1 0' [../] [./vie] type = TimeDerivative variable = v [../] [] [BCs] active = 'uleft uright vleft vright' [./uleft] type = DirichletBC variable = u boundary = 1 value = 0 [../] [./uright] type = DirichletBC variable = u boundary = 2 value = 0.1 [../] [./vleft] type = DirichletBC variable = v boundary = 1 value = 1 [../] [./vright] type = DirichletBC variable = v boundary = 2 value = 0 [../] [] [AuxVariables] [./aux_v] order = FIRST family = LAGRANGE [../] [] [AuxKernels] [./aux_k_1] type = FunctionAux variable = aux_v function = aux_v_fn [../] [] [Executioner] type = Transient solve_type = 'PJFNK' start_time = 0.0 num_steps = 2 dt = .1 [./Adaptivity] refine_fraction = 0.2 coarsen_fraction = 0.3 max_h_level = 4 [../] [] [Outputs] [./out] type = Exodus use_displaced = true output_on = 'initial timestep_end' [../] [] If we run it using serial mode,the outputs are ok,but if we run it using parallel mode,the outputs become strange.I cant upload images here(when I try to upload images,it shows "Something went really wrong, and we can’t process that file".) so please try it by yourselves.The location of this example is /moose/test/tests/outputs/displaced.Please test it using serial and parallel mode separately,you will see the difference,and something wrong with parallel outputs.

[aeslaughter]

I was able to reproduce the problem. This test is restricted to run on a single processor, does any MOOSE developer know the reason?

On Wed, Sep 9, 2015 at 6:25 AM, Liuux notifications@github.com wrote:

When I deal with some problems with displaced mesh,the outputs given by serial and parallel computation are different.The serial outputs are OK,but the parallel outputs have some problems. The example below shows the differences between serial and parallel outputs.This example comes from the MOOSE tests. The .i file is as below: [Mesh] dim = 2 file = square.e uniform_refine = 3 displacements = 'u aux_v' [] [Functions] [./aux_v_fn] type = ParsedFunction value = x*(y-0.5)/5 [../] [] [Variables] [./u] order = FIRST family = LAGRANGE [../] [./v] order = FIRST family = LAGRANGE [../] [] [Kernels] active = 'udiff uie vdiff vconv vie' [./udiff] type = Diffusion variable = u [../] [./uie] type = TimeDerivative variable = u [../] [./vdiff] type = Diffusion variable = v [../] [./vconv] type = Convection variable = v velocity = '-10 1 0' [../] [./vie] type = TimeDerivative variable = v [../] [] [BCs] active = 'uleft uright vleft vright' [./uleft] type = DirichletBC variable = u boundary = 1 value = 0 [../] [./uright] type = DirichletBC variable = u boundary = 2 value = 0.1 [../] [./vleft] type = DirichletBC variable = v boundary = 1 value = 1 [../] [./vright] type = DirichletBC variable = v boundary = 2 value = 0 [../] [] [AuxVariables] [./aux_v] order = FIRST family = LAGRANGE [../] [] [AuxKernels] [./aux_k_1] type = FunctionAux variable = aux_v function = aux_v_fn [../] [] [Executioner] type = Transient solve_type = 'PJFNK' start_time = 0.0 num_steps = 2 dt = .1 [./Adaptivity] refine_fraction = 0.2 coarsen_fraction = 0.3 max_h_level = 4 [../] [] [Outputs] [./out] type = Exodus use_displaced = true output_on = 'initial timestep_end' [../] [] If we run it using serial mode,the outputs are ok,but if we run it using parallel mode,the outputs become strange.I cant upload images here(when I try to upload images,it shows "Something went really wrong, and we can’t process that file".) so please try it by yourselves.The location of this example is /moose/test/tests/outputs/displaced.Please test it using serial and parallel mode separately,you will see the difference,and something wrong with parallel outputs.

— Reply to this email directly or view it on GitHub https://github.com/idaholab/moose/issues/5673.

[permcody]

Look like you were the one who disabled it, unfortunately you didn't say why.... https://github.com/idaholab/moose/commit/a0bbb04e29a1d29bdb233cafc4c3501d001d15b0

[aeslaughter]

I wrote this:

# Test the displaced mesh output; the gold file for this was generated from
# moose_test/tests/mesh/adapt/displaced_adapt_test.i

git blame ~/projects/moose/test/tests/mesh/adapt/tests

93ca9c85 test/tests/adapt_test/tests (Cody Permann        2012-11-12 09:49:25 +0000  2)   [./displaced_test]

93ca9c85 test/tests/adapt_test/tests (Cody Permann        2012-11-12 09:49:25 +0000  3)     type = 'Exodiff'

93ca9c85 test/tests/adapt_test/tests (Cody Permann        2012-11-12 09:49:25 +0000  4)     input = 'displaced_adapt_test.i'

93ca9c85 test/tests/adapt_test/tests (Cody Permann        2012-11-12 09:49:25 +0000  5)     exodiff = 'displaced_adapt_test_out.e-s002 displaced_adapt_test_out.e-s002'

93ca9c85 test/tests/adapt_test/tests (Cody Permann        2012-11-12 09:49:25 +0000  6)     group = 'adaptive'

93ca9c85 test/tests/adapt_test/tests (Cody Permann        2012-11-12 09:49:25 +0000  7)     max_parallel = 1

93ca9c85 test/tests/adapt_test/tests (Cody Permann        2012-11-12 09:49:25 +0000  8)   [../]

[permcody]

That's a different test but may be related to the same issue.

[aeslaughter]

I copied the test from you, the only difference in the tests is that the Mesh version doesn't output the displaced mesh and the Outputs version does. If enable the displaced mesh output for your test, the results are the same. Regardless of who made the test, something is wrong.

On Wed, Sep 9, 2015 at 9:06 AM, Cody Permann notifications@github.com wrote:

That's a different test but may be related to the same issue.

— Reply to this email directly or view it on GitHub https://github.com/idaholab/moose/issues/5673#issuecomment-138940086.

[Liuux]

Is this a libmesh' s issue, or moose's? Could you give me some suggestion, I would like fix it.

[permcody]

Most likely MOOSE's issue. We'll take a look when we get a chance. I'll bump the priority since this issue is important to fix.

[Liuux]

Well,although a year and a half have passed by,this problem is still not being resolved. This bothers me a lot wen I try to use my code to solve real engineering problem.Now I really care how long it will take to fix this bug. @permcody

[aeslaughter]

I am looking into this again now.

[aeslaughter]

I don't believe there is anything wrong with MOOSE for this problem. The input file defines a problem that is not well-defined with respect to the boundaries. I created a simpler input file below that show the same problem.

The original problem is using "u" ("disp_x" below) for the x-displacement. At the same time this value is being prescribed with a DirichletBC. However, depending on the adaptivity the corner nodes on the right-hand side may be associated with the "top", "bottom", or "right" boundary. If the later case is hit then it works fine, the others cause the strange looking output being observed.

The problem is that the corner nodes are on two boundaries, which one do you choose? Within MOOSE we don't guarantee where a node for such a case will land.

[Mesh]
  type = GeneratedMesh
  dim = 2
  nx = 2
  ny = 2
  uniform_refine = 3
  displacements = 'disp_x disp_y'
[]

[Variables]
  [./disp_x]
    order = FIRST
    family = LAGRANGE
  [../]
[]

[Kernels]
  [./udiff]
    type = Diffusion
    variable = disp_x
  [../]
  [./uie]
    type = TimeDerivative
    variable = disp_x
  [../]
[]

[BCs]
  [./uleft]
    type = DirichletBC
    variable = disp_x
    boundary = 1
    value = 0
  [../]
  [./uright]
    type = DirichletBC
    variable = disp_x
    boundary = 2
    value = 0.1
  [../]
[]

[AuxVariables]
  [./disp_y]
    order = FIRST
    family = LAGRANGE
  [../]
[]

[AuxKernels]
  [./aux_k]
    type = FunctionAux
    variable = disp_y
    function = x*(y-0.5)/5
  [../]
[]

[Executioner]
  type = Transient
  solve_type = 'PJFNK'
  start_time = 0.0
  num_steps = 2
  dt = .1
[]

[Outputs]
  [./out]
    type = Exodus
#    use_displaced = true
  [../]
[]

[aeslaughter]

Here is another input file that adds a new nodeset that guarantees that the right-hand side is captured.

[Mesh]
  type = GeneratedMesh
  dim = 2
  xmin = 0
  ymin = 0
  nx = 16
  ny = 16
  displacements = 'disp_x disp_y'
[]

[MeshModifiers]
  [./right]
    type = BoundingBoxNodeSet
    bottom_left = '0.96 0 0'
    top_right = '1.1 1.1 0'
    new_boundary = 42
  [../]
[]

[Variables]
  [./disp_x]
    order = FIRST
    family = LAGRANGE
  [../]
[]

[Kernels]
  [./udiff]
    type = Diffusion
    variable = disp_x
  [../]
  [./uie]
    type = TimeDerivative
    variable = disp_x
  [../]
[]

[BCs]
  [./uleft]
    type = DirichletBC
    variable = disp_x
    boundary = left
    value = 0
  [../]
  [./uright]
    type = DirichletBC
    variable = disp_x
    boundary = 42
    value = 0.1
  [../]
[]

[AuxVariables]
  [./disp_y]
    order = FIRST
    family = LAGRANGE
  [../]
[]

[AuxKernels]
  [./aux_k]
    type = FunctionAux
    variable = disp_y
    function = x*(y-0.5)/5
  [../]
[]

[Executioner]
  type = Transient
  solve_type = 'PJFNK'
  start_time = 0.0
  num_steps = 2
  dt = .1
[]

[Outputs]
  [./out]
    type = Exodus
  [../]
[]

[Liuux]

@aeslaughter Thank you for your help! It seems that my problem has a perfect solution. now,I just need a few days to understand the mechanism clearly and use this method to deal with complex geometry.

[aeslaughter]

@Liuux Sorry it took so long for us to figure this out, please email the list if you need additional help understanding what is going on.