SolutionUserObject fails when PostProcessors and Variables have same name

[SudiptaBiswas]

Bug Description

In general, MOOSE allows PostProcessors to have the same names as the materials or variables. However, SolutionUserObject fails to read such data from an exodus file due to the name clash. It throws in the following error which is coming from libMesh and is not directly indicative of the issue.

ERROR: incompatible variable 'var_name' has already been added for this system!
Stack frames: 13
0: 0   libmesh_dbg.0.dylib                 0x000000010b000c2c libMesh::print_trace(std::__1::basic_ostream<char, std::__1::char_traits<char> >&) + 460
1: 1   libmesh_dbg.0.dylib                 0x000000010aff7a2a libMesh::MacroFunctions::report_error(char const*, int, char const*, char const*) + 218
2: 2   libmesh_dbg.0.dylib                 0x000000010bcf9e9b libMesh::System::add_variable(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, libMesh::FEType const&, std::__1::set<unsigned short, std::__1::less<unsigned short>, std::__1::allocator<unsigned short> > const*) + 939
3: 3   libmesh_dbg.0.dylib                 0x000000010bcfb3d3 libMesh::System::add_variable(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, libMesh::Order, libMesh::FEFamily, std::__1::set<unsigned short, std::__1::less<unsigned short>, std::__1::allocator<unsigned short> > const*) + 83
4: 4   libmoose-dbg.0.dylib                0x00000001058b07f9 SolutionUserObject::readExodusII() + 2809
5: 5   libmoose-dbg.0.dylib                0x00000001058b349a SolutionUserObject::initialSetup() + 330
6: 6   libmoose-dbg.0.dylib                0x000000010546f502 FEProblemBase::initialSetup() + 5618
7: 7   libmoose-dbg.0.dylib                0x0000000104f831cf Transient::init() + 2415
8: 8   libmoose-dbg.0.dylib                0x000000010612dc47 MooseApp::executeExecutioner() + 183
9: 9   libmoose-dbg.0.dylib                0x000000010612ebbf MooseApp::run() + 335

Steps to Reproduce

SolutionUserObject to read an exodus file that has a Postprocessor with the same name as a Variable

Impact

Affects only the SolutionUserObject

[socratesgorilla]

Could not reproduce. Additionally, the issue would be in libmesh if it did exist, not moose, as thats where the error provided comes from. Recommend closing.

[socratesgorilla]

@permcody

[permcody]

Thanks for looking at tickets like this. If you can't reproduce, great! The right thing to do though would be to check in your test case as evidence and close this ticket.

This isn't really a libMesh problem even if libMesh is issuing the error. We may have been adding a placeholder variable to the system and that was overlapping with another scalar variable type already in the system triggering the error. I would suspect that this is still an issue. Can you post your input file?

@SudiptaBiswas - you don't happen to have your test case around do you?

[SudiptaBiswas]

I believe the issue is still there. I don't have anything handy. I can create a small test and post it here.

[socratesgorilla]

I can check it out once its posted

[SudiptaBiswas]

Here is how you can reproduce this issue. I am using existing test files as examples here,

Step 1. Add the following to this file https://github.com/idaholab/moose/blob/next/test/tests/userobjects/solution_user_object/discontinuous_value_solution_uo_p1.i

[Postprocessors]
  [./u]
    type = ElementIntegralVariablePostprocessor
    variable = u
  [../]
[]

Step 2: Run this, https://github.com/idaholab/moose/blob/next/test/tests/userobjects/solution_user_object/discontinuous_value_solution_uo_p2.i with https://github.com/idaholab/moose/blob/next/test/tests/userobjects/solution_user_object/discontinuous_value_solution_uo_p2.i#L43 commented out.

You should see an error saying: ERROR: incompatible variable u has already been added for this system!