Backup causes random failure for XFEM problems

[jiangwen84]

Bug Description

When backupMultiApp is called, a new backup will be created. The backup will store MaterialProprety from MaterialPropertyStorage. The storage uses element id, so it looks for element id. If an element has a pointer, but does not have a valid id, it will throw out an error. For XFEM, some element will be deleted, but their points will still remain in the MaterialPropertyStoreage. Very randomly, their id could become invalid and trigger that error.

Steps to Reproduce

It fails randomly, and trigged by the backup. The bt is below

• thread Removed #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  • frame #0: 0x000000012bfadbb0 libmpi.12.dylibMPI_Abort frame #1: 0x0000000116285674 libmoose-dbg.0.dylibmoose::internal::mooseErrorRaw(msg="", prefix="") at MooseError.C:84:3
    frame Removed #2: 0x00000001157979aa libmoose-dbg.0.dylibvoid mooseError<char const (&) [37]>(args=<no value available>) [37]) at MooseError.h:240:3 frame #3: 0x00000001157978e5 libmoose-dbg.0.dylibvoid dataStore<libMesh::Elem const>(stream=0x00007ffee2e516d0, e=0x00007fbc0a69c170, context=0x00007fbceb0b7618) at DataIO.C:96:7
    frame Removed #4: 0x00000001154b0e05 libmoose-dbg.0.dylibvoid storeHelper<libMesh::Elem const*>(stream=0x00007ffee2e516d0, data=0x00007fbc0a69c170, context=0x00007fbceb0b7618) at DataIO.h:715:3 frame #5: 0x00000001154b0cd2 libmoose-dbg.0.dylibvoid dataStore<libMesh::Elem const*, HashMap<unsigned int, MaterialProperties> >(stream=0x00007ffee2e516d0, m=0x00007fbc78faaa40, context=0x00007fbceb0b7618) at DataIO.h:335:5
    frame Removed #6: 0x00000001154b0bc8 libmoose-dbg.0.dylibvoid dataStore<MaterialPropertyStorage>(stream=0x00007ffee2e516d0, storage=0x00007fbc78faaaa0, context=0x00007fbceb0b7618) at MaterialPropertyStorage.h:314:3 frame #7: 0x00000001154b0b55 libmoose-dbg.0.dylibvoid storeHelper(stream=0x00007ffee2e516d0, data=0x00007fbc78faaaa0, context=0x00007fbceb0b7618) at DataIO.h:715:3
    frame Removed #8: 0x00000001154b0623 libmoose-dbg.0.dylibRestartableData<MaterialPropertyStorage>::store(this=0x00007fbc78faa9e0, stream=0x00007ffee2e516d0) at RestartableData.h:164:3 frame #9: 0x000000011579ca78 libmoose-dbg.0.dylibRestartableDataIO::serializeRestartableData(this=0x00007ffee2e51b80, restartable_data=size=78, stream=0x00007fbd490ce190) at RestartableDataIO.C:114:24
    frame Removed #10: 0x000000011579f2c6 libmoose-dbg.0.dylibRestartableDataIO::createBackup(this=0x00007ffee2e51b80) at RestartableDataIO.C:347:5 frame #11: 0x0000000116224f58 libmoose-dbg.0.dylibMooseApp::backup(this=0x00007fbd2881f818) at MooseApp.C:1089:15
    frame Removed #12: 0x00000001157fa470 libmoose-dbg.0.dylibMultiApp::backup(this=0x00007fbd1853a3c8) at MultiApp.C:430:29 frame #13: 0x00000001157fa343 libmoose-dbg.0.dylibFullSolveMultiApp::backup(this=0x00007fbd1853a3c8) at FullSolveMultiApp.C:54:15
    frame Removed #14: 0x00000001153ddfb7 libmoose-dbg.0.dylibFEProblemBase::backupMultiApps(this=0x00007fbcea808218, type=(_raw_name = "TIMESTEP_BEGIN", _name = "TIMESTEP_BEGIN", _id = 16)) at FEProblemBase.C:4406:18 frame #15: 0x0000000114edbb7f libmoose-dbg.0.dylibPicardSolve::solve(this=0x00007fbd4981d080) at PicardSolve.C:160:12
    frame Removed #16: 0x0000000114ee7c26 libmoose-dbg.0.dylibSteady::execute(this=0x00007fbd4981ce18) at Steady.C:88:45 frame #17: 0x0000000116224768 libmoose-dbg.0.dylibMooseApp::executeExecutioner(this=0x00007fbd2880c418) at MooseApp.C:1023:19
    frame Removed #18: 0x00000001162256af libmoose-dbg.0.dylibMooseApp::run(this=0x00007fbd2880c418) at MooseApp.C:1150:5 frame #19: 0x000000010cdaec66 bison-dbgmain(argc=4, argv=0x00007ffee2e52968) at main.C:50:8
    frame Create new product "Stroma" #20: 0x00007fff67775cc9 libdyld.dylibstart + 1 frame #21: 0x00007fff67775cc9 libdyld.dylibstart + 1

One way to fix this is to remove property storage of elements before they are deleted.

Impact

It will fix issues where backup is needed for XFEM, such as for multiapp application.