Crash with adaptivity + high order scalar variables #12309

dschwen · 2018-10-14T23:03:01Z

Rationale

Moose crashes (or bails out with an assertion) if the mesh gets refined in a simulation that has ~~stateful material properties and~~ high order scalar variables (I'm assuming it's the scalar vars but I'll be continuing to check this).

I might me in uncharted territory here (or assuming I can use a capability that simply doesn't exist yet). But I'd expect a verbose error message rather than a crash nonetheless.

Description

Still working on a minimal input that works with vanilla MOOSE, but with my Marmot branch I get:

Assertion `var < this->n_vars(s)' failed.
var = 13
this->n_vars(s) = 13


Stack frames: 20
0: 0   libmesh_dbg.0.dylib                 0x000000010c3dc050 libMesh::print_trace(std::__1::basic_ostream<char, std::__1::char_traits<char> >&) + 2192
1: 1   libmesh_dbg.0.dylib                 0x000000010c3c62b1 libMesh::MacroFunctions::report_error(char const*, int, char const*, char const*) + 369
2: 2   libmagpie-dbg.0.dylib               0x000000010666483f libMesh::DofObject::n_comp(unsigned int, unsigned int) const + 3551
3: 3   libmesh_dbg.0.dylib                 0x000000010def89f0 libMesh::OldSolutionValue<double, &(void libMesh::FEMContext::point_value<double>(unsigned int, libMesh::Point const&, double&, double) const)>::eval_at_node(libMesh::FEMContext const&, unsigned int, unsigned int, libMesh::Node const&, double) + 144
4: 4   libmesh_dbg.0.dylib                 0x000000010deeb99d libMesh::GenericProjector<libMesh::OldSolutionValue<double, &(void libMesh::FEMContext::point_value<double>(unsigned int, libMesh::Point const&, double&, double) const)>, libMesh::OldSolutionValue<libMesh::VectorValue<double>, &(void libMesh::FEMContext::point_gradient<libMesh::VectorValue<double> >(unsigned int, libMesh::Point const&, double&, double) const)>, double, libMesh::VectorSetAction<double> >::operator()(libMesh::StoredRange<libMesh::MeshBase::const_element_iterator, libMesh::Elem const*> const&) const + 14221
5: 5   libmesh_dbg.0.dylib                 0x000000010decc50c void libMesh::Threads::parallel_for<libMesh::StoredRange<libMesh::MeshBase::const_element_iterator, libMesh::Elem const*>, libMesh::GenericProjector<libMesh::OldSolutionValue<double, &(void libMesh::FEMContext::point_value<double>(unsigned int, libMesh::Point const&, double&, double) const)>, libMesh::OldSolutionValue<libMesh::VectorValue<double>, &(void libMesh::FEMContext::point_gradient<libMesh::VectorValue<double> >(unsigned int, libMesh::Point const&, double&, double) const)>, double, libMesh::VectorSetAction<double> > >(double const&, libMesh::GenericProjector<libMesh::OldSolutionValue<double, &(void libMesh::FEMContext::point_value<double>(unsigned int, libMesh::Point const&, double&, double) const)>, libMesh::OldSolutionValue<libMesh::VectorValue<double>, &(void libMesh::FEMContext::point_gradient<libMesh::VectorValue<double> >(unsigned int, libMesh::Point const&, double&, double) const)>, double, libMesh::VectorSetAction<double> > const&) + 124
6: 6   libmesh_dbg.0.dylib                 0x000000010deca512 libMesh::System::project_vector(libMesh::NumericVector<double> const&, libMesh::NumericVector<double>&, int) const + 10594
7: 7   libmesh_dbg.0.dylib                 0x000000010dec79c9 libMesh::System::project_vector(libMesh::NumericVector<double>&, int) const + 153
8: 8   libmesh_dbg.0.dylib                 0x000000010ddee431 libMesh::System::restrict_vectors() + 865
9: 9   libmesh_dbg.0.dylib                 0x000000010ddef2c9 libMesh::System::prolong_vectors() + 25
10: 10  libmesh_dbg.0.dylib                 0x000000010dd2b3d5 libMesh::EquationSystems::reinit_solutions() + 10293
11: 11  libmoose-dbg.0.dylib                0x000000010952852b FEProblemBase::meshChangedHelper(bool) + 395
12: 12  libmoose-dbg.0.dylib                0x00000001095281fa FEProblemBase::adaptMesh() + 698
13: 13  libmoose-dbg.0.dylib                0x000000010901b2cd Transient::incrementStepOrReject() + 125
14: 14  libmoose-dbg.0.dylib                0x000000010901b067 Transient::execute() + 119
15: 15  libmoose-dbg.0.dylib                0x000000010a63c30b MooseApp::executeExecutioner() + 235
16: 16  libmoose-dbg.0.dylib                0x000000010a63cc5f MooseApp::run() + 335
17: 17  marmot-dbg                          0x0000000105adc396 main + 278
18: 18  libdyld.dylib                       0x00007fff74dbd085 start + 1
19: 19  ???                                 0x0000000000000003 0x0 + 3
[0] /Users/schwd/Programs/libmesh/installed/include/libmesh/dof_object.h, line 807, compiled nodate at notime
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0
[unset]: write_line error; fd=-1 buf=:cmd=abort exitcode=1
:
system msg for write_line failure : Bad file descriptor

(this error is triggered in serial and parallel runs)

Impact

The text was updated successfully, but these errors were encountered:

dschwen · 2018-10-15T02:34:24Z

Backtrace

`OldSolutionValue::eval_at_node` is being called with an invalid variable number (13)

frame #6: 0x00000001084d59f0 libmesh_dbg.0.dylib`libMesh::OldSolutionValue<double, &(void libMesh::FEMContext::point_value<double>(unsigned int, libMesh::Point const&, double&, double) const)>::eval_at_node(this=0x00007ffeefbf9290, c=0x00007ffeefbf8e48, i=13, (null)=2, n=0x000000011450e2e0, (null)=0) at generic_projector.h:489
   486 	  // exceeding FE order)
   487 	  if (n.old_dof_object &&
   488 	      n.old_dof_object->n_vars(sys.number()) &&
-> 489 	      n.old_dof_object->n_comp(sys.number(), i))
   490 	    {
   491 	      const dof_id_type old_id =
   492 	        n.old_dof_object->dof_number(sys.number(), i, 0);
(lldb) print i
(unsigned int) $6 = 13
(lldb) print sys._variable_numbers
(const std::__1::map<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, unsigned short, std::__1::less<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::allocator<std::__1::pair<const std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, unsigned short> > >) $7 = size=13 {
  [0] = (first = "ci", second = 0)
  [1] = (first = "cv", second = 1)
  [2] = (first = "global_strain", second = 4)
  [3] = (first = "gr0", second = 5)
  [4] = (first = "gr1", second = 6)
  [5] = (first = "gr2", second = 7)
  [6] = (first = "gr3", second = 8)
  [7] = (first = "gr4", second = 9)
  [8] = (first = "gr5", second = 10)
  [9] = (first = "gr6", second = 11)
  [10] = (first = "gr7", second = 12)
  [11] = (first = "u_x", second = 2)
  [12] = (first = "u_y", second = 3)
}

dschwen · 2018-10-15T02:52:34Z

Ok, I have a small vanilla MOOSE input (see below). The bug looks related to libmesh's System::variable_scalar_number (ping @roystgnr maybe?).

If a higher order scalar variable comes before a field variable then the variable scalar component numbering is not the same as the variable numbering and the error above is triggered. If the high order scalar variable is last in the list (try moving it to the bottom of the [Variables] block) the input runs fine.

[Mesh]
  type = GeneratedMesh
  dim = 1
[]

[Variables]
  [./dummy]
    family = SCALAR
    order = THIRD
  [../]
  [./u]
    order = FIRST
    family = LAGRANGE
  [../]
[]

[ScalarKernels]
  [./d1]
    type = ODETimeDerivative
    variable = dummy
  [../]
[]

[Kernels]
  [./ie]
    type = TimeDerivative
    variable = u
  [../]
[]

[Executioner]
  type = Transient
  num_steps = 2
[]

[Adaptivity]
  marker = uniform
  [./Markers]
    [./uniform]
      type = UniformMarker
      mark = REFINE
    [../]
  [../]
[]

dschwen · 2018-10-15T02:53:24Z

This has noting to do with stateful properties after all. It is just the indexing of variables and their scalar component numbers.

roystgnr · 2018-10-15T03:04:02Z

I'll see if I can reproduce this.

roystgnr · 2018-10-15T03:09:08Z

Shoot, but not tonight apparently. AFK and getting some weird build errors after pulling the latest MOOSE.

roystgnr · 2018-10-15T13:10:04Z

Pulling the latest MOOSE and trying to build with an outdated libMesh, it turns out. Better luck this morning.

dschwen · 2018-10-15T21:23:02Z

Can you reproduce this?

roystgnr · 2018-10-15T21:52:59Z

"Better luck this morning" turned out to be awful foreshadowing, as my day got eaten by a cascade of "why does the same gfortran module work fine on one computer and illegal-instruction on another" rooted nonsense. Sorry. Assuming that's all straight now I'll take a crack tonight.

roystgnr · 2018-10-16T15:47:08Z

I can reproduce this fine, thanks; still working at understanding it.

roystgnr · 2018-10-16T18:01:48Z

Ok, this looks like my fault for using (and documenting) variable_scalar_number inappropriately. Often it never makes a difference because users have been in the habit of declaring scalars last, but here it gives us the wrong offset.

I think we'll want a new number lookup (variable_scalar_number is appropriate for its uses outside the projection code) that skips SCALARs the way our dof numbering does on elements and nodes. And we'll also need to better document the true behavior of n_comp and dof_number (if you put SCALAR variables in the middle of your list then DofObject variables are no longer indexed by variable number) and check the other zillion uses of those methods for the same bug. This could take a while.

dschwen · 2018-10-16T22:07:18Z

We could enforce higher (than 1) order scalar variables to be at the end of the variable list (at least in MOOSE if adaptivity is active)

This is to handle the case (as triggered all-too-easily in idaholab/moose#12309) where we have multi-component variables which *precede* other single-component variables in the system being projected.

roystgnr · 2018-10-16T22:41:59Z

See if libMesh/libmesh#1904 works for you? That turned out to be much simpler than I'd feared; most methods really were behaving correctly, I was just constructing that one hierarchy of functors that wasn't.

On the other hand, just because that works for me on the simple case you've distilled here doesn't mean it'll work for your application code, so maybe I'll hold off on the hubris for a little bit.

SudiptaBiswas · 2018-11-21T19:55:34Z

Has this libmesh change (libMesh/libmesh#1904) made its way into MOOSE? I still have input files crashing with the following error msg,

combined-opt(97693,0x7fffb1d1c3c0) malloc: *** mach_vm_map(size=281336042602496) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0
[unset]: write_line error; fd=-1 buf=:cmd=abort exitcode=1
:
system msg for write_line failure : Bad file descriptor

The error can be reproduced by running the following input file with combined-opt,

[Mesh]
  type = GeneratedMesh
  dim = 2
  nx = 10
  ny = 10
  xmin = -0.5
  xmax = 0.5
  ymin = -0.5
  ymax = 0.5
[]

[MeshModifiers]
  [./cnode]
    type = AddExtraNodeset
    coord = '0.0 0.0'
    new_boundary = 100
  [../]
[]

[Variables]
  [./u_x]
  [../]
  [./u_y]
  [../]
  [./global_strain]
    order = THIRD
    family = SCALAR
  [../]
  [./c]
    [./InitialCondition]
      type = FunctionIC
      function = 'sin(2*x*pi)*sin(2*y*pi)*0.05+0.6'
    [../]
  [../]
  [./w]
  [../]
[]

[GlobalParams]
  derivative_order = 2
  enable_jit = true
  displacements = 'u_x u_y'
  block = 0
[]

[Kernels]
  [./TensorMechanics]
  [../]
  [./c_dot]
    type = CoupledTimeDerivative
    variable = w
    v = c
  [../]
  [./c_res]
    type = SplitCHParsed
    variable = c
    f_name = F
    kappa_name = kappa_c
    w = w
  [../]
  [./w_res]
    type = SplitCHWRes
    variable = w
    mob_name = M
  [../]
[]

[ScalarKernels]
  [./global_strain]
    type = GlobalStrain
    variable = global_strain
    global_strain_uo = global_strain_uo
  [../]
[]

[BCs]
  [./Periodic]
    [./all]
      auto_direction = 'x y'
      variable = 'c w u_x u_y'
    [../]
  [../]
  [./centerfix_x]
    type = PresetBC
    boundary = 100
    variable = u_x
    value = 0
  [../]
  [./centerfix_y]
    type = PresetBC
    boundary = 100
    variable = u_y
    value = 0
  [../]
[]

[Materials]
  [./consts]
    type = GenericConstantMaterial
    prop_names  = 'M   kappa_c'
    prop_values = '0.2 0.01   '
  [../]
  [./elasticity_tensor]
    type = ComputeElasticityTensor
    C_ijkl = '1 1'
    fill_method = symmetric_isotropic
  [../]
  [./strain]
    type = ComputeSmallStrain
    global_strain = global_strain
  [../]
  [./global_strain]
    type = ComputeGlobalStrain
    scalar_global_strain = global_strain
    global_strain_uo = global_strain_uo
  [../]
  [./stress]
    type = ComputeLinearElasticStress
  [../]
  [./chemical_free_energy]
    type = DerivativeParsedMaterial
    function = '4*c^2*(1-c)^2'
    args = 'c'
    outputs = exodus
  [../]
[]

[UserObjects]
  [./global_strain_uo]
    type = GlobalStrainUserObject
    execute_on = 'Initial Linear Nonlinear'
  [../]
[]

[Preconditioning]
  [./SMP]
    type = SMP
    full = true
  [../]
[]

[Executioner]
  type = Transient
  scheme = bdf2
  solve_type = 'PJFNK'
  line_search = basic
  petsc_options_iname = '-pc_type -ksp_gmres_restart -sub_ksp_type -sub_pc_type -pc_asm_overlap'
  petsc_options_value = 'asm         31   preonly   lu      1'
  l_max_its = 30
  nl_max_its = 12
  l_tol = 1.0e-4
  nl_rel_tol = 1.0e-8
  nl_abs_tol = 1.0e-10
  start_time = 0.0
  end_time = 2.0
[]

[Adaptivity]
 initial_steps = 2
 max_h_level = 2
 marker = EFM
[./Markers]
   [./EFM]
     type = ErrorFractionMarker
     coarsen = 0.2
     refine = 0.8
     indicator = GJI
   [../]
 [../]
 [./Indicators]
   [./GJI]
     type = GradientJumpIndicator
     variable = c
    [../]
 [../]
[]

[Outputs]
  exodus = true
[]

@roystgnr would you mind taking another look?

roystgnr · 2018-11-21T21:04:01Z

Your MOOSE is updated to the latest, so your libmesh submodule is updated to libMesh/libmesh@ab2cf97 ? That does include libMesh/libmesh#1904.

Can you try running in dbg mode and see if you get any more informative error info?

SudiptaBiswas · 2018-11-21T21:35:50Z

I am having trouble with lldb. I don't know why it's giving me the following error,

Process 15703 exited with status = -1 (0xffffffff) lost connection
error: process resume at entry point failed: Resume timed out.

roystgnr · 2018-11-21T22:30:58Z

I don't know either, but you don't need a debugger to run in dbg mode. If you just build and use combined-dbg instead of combined-opt then it'll turn on our assertions and you'll probably get some more informative output than that error from malloc.

SudiptaBiswas · 2018-11-21T22:40:44Z

Here is what I got

Assertion `_dof_indices_var.size() > var' failed.
_dof_indices_var.size() = 5
var = 5


Stack frames: 21
0: 0   libmesh_dbg.0.dylib                 0x000000010dc337ae libMesh::print_trace(std::__1::basic_ostream<char, std::__1::char_traits<char> >&) + 2366
1: 1   libmesh_dbg.0.dylib                 0x000000010dc1e41a libMesh::MacroFunctions::report_error(char const*, int, char const*, char const*) + 394
2: 2   libmesh_dbg.0.dylib                 0x000000010f067e47 libMesh::DiffContext::get_dof_indices(unsigned int) + 1335
3: 3   libmesh_dbg.0.dylib                 0x000000010f4e980d libMesh::OldSolutionValue<double, &(void libMesh::FEMContext::point_value<double>(unsigned int, libMesh::Point const&, double&, double) const)>::eval_old_dofs(libMesh::FEMContext const&, unsigned int, std::__1::vector<double, std::__1::allocator<double> >&) + 109
4: 4   libmesh_dbg.0.dylib                 0x000000010f4dc7f5 libMesh::GenericProjector<libMesh::OldSolutionValue<double, &(void libMesh::FEMContext::point_value<double>(unsigned int, libMesh::Point const&, double&, double) const)>, libMesh::OldSolutionValue<libMesh::VectorValue<double>, &(void libMesh::FEMContext::point_gradient<libMesh::VectorValue<double> >(unsigned int, libMesh::Point const&, double&, double) const)>, double, libMesh::VectorSetAction<double> >::operator()(libMesh::StoredRange<libMesh::MeshBase::const_element_iterator, libMesh::Elem const*> const&) const + 6485
5: 5   libmesh_dbg.0.dylib                 0x000000010f4bfde8 void libMesh::Threads::parallel_for<libMesh::StoredRange<libMesh::MeshBase::const_element_iterator, libMesh::Elem const*>, libMesh::GenericProjector<libMesh::OldSolutionValue<double, &(void libMesh::FEMContext::point_value<double>(unsigned int, libMesh::Point const&, double&, double) const)>, libMesh::OldSolutionValue<libMesh::VectorValue<double>, &(void libMesh::FEMContext::point_gradient<libMesh::VectorValue<double> >(unsigned int, libMesh::Point const&, double&, double) const)>, double, libMesh::VectorSetAction<double> > >(double const&, libMesh::GenericProjector<libMesh::OldSolutionValue<double, &(void libMesh::FEMContext::point_value<double>(unsigned int, libMesh::Point const&, double&, double) const)>, libMesh::OldSolutionValue<libMesh::VectorValue<double>, &(void libMesh::FEMContext::point_gradient<libMesh::VectorValue<double> >(unsigned int, libMesh::Point const&, double&, double) const)>, double, libMesh::VectorSetAction<double> > const&) + 136
6: 6   libmesh_dbg.0.dylib                 0x000000010f4bdd91 libMesh::System::project_vector(libMesh::NumericVector<double> const&, libMesh::NumericVector<double>&, int) const + 9681
7: 7   libmesh_dbg.0.dylib                 0x000000010f4bb5df libMesh::System::project_vector(libMesh::NumericVector<double>&, int) const + 159
8: 8   libmesh_dbg.0.dylib                 0x000000010f3f4bd7 libMesh::System::restrict_vectors() + 871
9: 9   libmesh_dbg.0.dylib                 0x000000010f3f5939 libMesh::System::prolong_vectors() + 25
10: 10  libmesh_dbg.0.dylib                 0x000000010f33dd00 libMesh::EquationSystems::reinit_solutions() + 9056
11: 11  libmesh_dbg.0.dylib                 0x000000010f33b979 libMesh::EquationSystems::reinit() + 25
12: 12  libmoose-dbg.0.dylib                0x000000010b98cda0 FEProblemBase::meshChangedHelper(bool) + 432
13: 13  libmoose-dbg.0.dylib                0x000000010b98dfa5 FEProblemBase::meshChanged() + 53
14: 14  libmoose-dbg.0.dylib                0x000000010b98c64c FEProblemBase::initialAdaptMesh() + 348
15: 15  libmoose-dbg.0.dylib                0x000000010b928945 FEProblemBase::initialSetup() + 6421
16: 16  libmoose-dbg.0.dylib                0x000000010ad4bbf7 Transient::init() + 5751
17: 17  libmoose-dbg.0.dylib                0x000000010c0a19a7 MooseApp::executeExecutioner() + 183
18: 18  libmoose-dbg.0.dylib                0x000000010c0a230f MooseApp::run() + 335
19: 19  combined-dbg                        0x000000010a87ba46 main + 358
20: 20  libdyld.dylib                       0x00007fffa8e8b235 start + 1

roystgnr · 2018-11-21T22:50:16Z

Aha! It looks like libMesh/libmesh#1904 missed a slightly different but related bug. Let me see if I can set up a PR for you to try.

roystgnr · 2018-11-21T22:52:14Z

In the meantime, is there a chance you could boil that test down to something small enough to add to the core MOOSE test suite? I'm getting more and more embarrassed that we don't have anything covering high order scalar projections in CI.

Hopefully this fixes the newer bug found in idaholab/moose#12309

roystgnr · 2018-11-21T22:54:28Z

Give libMesh/libmesh#1948 a try? Sorry I don't have time to see if I can replicate the problem myself; I'm going to be AFK for holiday/family stuff starting in about 20 minutes.

SudiptaBiswas · 2018-11-21T23:21:13Z

Thanks, @roystgnr. I will give it a try.

The smaller problem @dschwen created seem to work after libMesh/libmesh#1904. I only faced the issue again for the multiphysics problem. I will see if I can create a test problem for this.

SudiptaBiswas · 2018-11-26T20:34:55Z

Okay, here is a framework only input file for reproducing the error. I can add this to framework tests once the libmesh changes are available in MOOSE.

[Mesh]
  type = GeneratedMesh
  dim = 2
  nx = 10
  ny = 10
  xmin = -0.5
  xmax = 0.5
  ymin = -0.5
  ymax = 0.5
[]

[Variables]
  [./scalar]
    order = THIRD
    family = SCALAR
  [../]
  [./u]
    [./InitialCondition]
      type = FunctionIC
      function = 'x*x+y*y'
    [../]
  [../]
[]

[Kernels]
  [./u_dot]
    type = TimeDerivative
    variable = u
  [../]
  [./c_res]
    type = Diffusion
    variable = u
  [../]
[]

[ScalarKernels]
  [./d1]
    type = ODETimeDerivative
    variable = scalar
  [../]
[]

[BCs]
  [./Periodic]
    [./all]
      auto_direction = 'x y'
      variable = 'u'
    [../]
  [../]
[]

[Preconditioning]
  [./SMP]
    type = SMP
    full = true
  [../]
[]

[Executioner]
  type = Transient
  solve_type = 'PJFNK'
  petsc_options_iname = '-pc_type -sub_pc_type'
  petsc_options_value = 'asm         lu     '
  num_steps = 2
[]

[Adaptivity]
 initial_steps = 2
 max_h_level = 2
 marker = EFM
[./Markers]
   [./EFM]
     type = ErrorFractionMarker
     coarsen = 0.2
     refine = 0.8
     indicator = GJI
   [../]
 [../]
 [./Indicators]
   [./GJI]
     type = GradientJumpIndicator
     variable = u
    [../]
 [../]
[]

[Outputs]
  exodus = true
[]

This resolves idaholab#12309 and idaholab#12538 The libMesh bug here got fixed years ago, but apparently the MOOSE test coverage for the fix got lost in the couch cushions until I stumbled across it while searching old issues.

dschwen added the T: defect An anomaly, which is anything that deviates from expectations. label Oct 14, 2018

dschwen changed the title ~~Crash with adaptivity + stateful material property + scalar variable~~ Crash with adaptivity + <s>stateful material property</s> + scalar variable Oct 15, 2018

dschwen changed the title ~~Crash with adaptivity + <s>stateful material property</s> + scalar variable~~ Crash with adaptivity + high order scalar variables Oct 15, 2018

roystgnr mentioned this issue Oct 16, 2018

Do component_to_var lookups in OldSolution code libMesh/libmesh#1904

Merged

dschwen mentioned this issue Nov 13, 2018

Error while using Mesh Adaptivity with higher order scalar variables #12407

Closed

roystgnr added a commit to roystgnr/libmesh that referenced this issue Nov 21, 2018

eval_old_dofs needs var, not var_component

cdbb482

Hopefully this fixes the newer bug found in idaholab/moose#12309

roystgnr mentioned this issue Nov 21, 2018

eval_old_dofs needs var, not var_component libMesh/libmesh#1948

Merged

SudiptaBiswas mentioned this issue Nov 26, 2018

Add framework test for higher order scalar variable with mesh adaptivity #12538

Open

aeslaughter added the P: normal A defect affecting operation with a low possibility of significantly affects. label Apr 12, 2021

roystgnr mentioned this issue Jan 5, 2023

Add regression test for AMR w/ high-order SCALARs #23075

Merged

roystgnr closed this as completed in #23075 Jan 6, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Crash with adaptivity + high order scalar variables #12309

Crash with adaptivity + high order scalar variables #12309

dschwen commented Oct 14, 2018 •

edited

dschwen commented Oct 15, 2018 •

edited

dschwen commented Oct 15, 2018

dschwen commented Oct 15, 2018

roystgnr commented Oct 15, 2018

roystgnr commented Oct 15, 2018

roystgnr commented Oct 15, 2018

dschwen commented Oct 15, 2018

roystgnr commented Oct 15, 2018

roystgnr commented Oct 16, 2018

roystgnr commented Oct 16, 2018

dschwen commented Oct 16, 2018

roystgnr commented Oct 16, 2018

SudiptaBiswas commented Nov 21, 2018

roystgnr commented Nov 21, 2018

SudiptaBiswas commented Nov 21, 2018

roystgnr commented Nov 21, 2018

SudiptaBiswas commented Nov 21, 2018

roystgnr commented Nov 21, 2018

roystgnr commented Nov 21, 2018

roystgnr commented Nov 21, 2018

SudiptaBiswas commented Nov 21, 2018

SudiptaBiswas commented Nov 26, 2018

Crash with adaptivity + high order scalar variables #12309

Crash with adaptivity + high order scalar variables #12309

Comments

dschwen commented Oct 14, 2018 • edited

Rationale

Description

Impact

dschwen commented Oct 15, 2018 • edited

dschwen commented Oct 15, 2018

dschwen commented Oct 15, 2018

roystgnr commented Oct 15, 2018

roystgnr commented Oct 15, 2018

roystgnr commented Oct 15, 2018

dschwen commented Oct 15, 2018

roystgnr commented Oct 15, 2018

roystgnr commented Oct 16, 2018

roystgnr commented Oct 16, 2018

dschwen commented Oct 16, 2018

roystgnr commented Oct 16, 2018

SudiptaBiswas commented Nov 21, 2018

roystgnr commented Nov 21, 2018

SudiptaBiswas commented Nov 21, 2018

roystgnr commented Nov 21, 2018

SudiptaBiswas commented Nov 21, 2018

roystgnr commented Nov 21, 2018

roystgnr commented Nov 21, 2018

roystgnr commented Nov 21, 2018

SudiptaBiswas commented Nov 21, 2018

SudiptaBiswas commented Nov 26, 2018

dschwen commented Oct 14, 2018 •

edited

dschwen commented Oct 15, 2018 •

edited