From: David K. <dav...@ak...> - 2018-07-24 12:38:10
|
On Tue, Jul 24, 2018 at 2:29 AM, Nikhil Vaidya <nik...@gm...> wrote: > Thanks for the answer. I tried removing the particular initialize call and > ran it again. This time I get the following error message: > > Assertion `proc < _first_df.size()' failed. > proc = 0 > _first_df.size() = 0 > > > Detaching after fork from child process 10172. > Stack frames: 17 > 0: libMesh::print_trace(std::ostream&) > 1: libMesh::MacroFunctions::report_error(char const*, int, char const*, > char const*) > 2: libMesh::DofMap::n_dofs_on_processor(unsigned short) const > 3: libMesh::PetscMatrix<double>::init() > 4: libMesh::RBConstruction::allocate_data_structures() > 5: libMesh::RBConstruction::initialize_rb_construction(bool, bool) > 6: libMesh::RBEIMConstruction::initialize_rb_construction(bool, bool) > 7: DwarfElephantInitializeRBSystemSteadyState::initializeOfflineStage() > 8: DwarfElephantInitializeRBSystemSteadyState::initialize() > 9: FEProblemBase::computeUserObjects(MooseEnumItem const&, Moose::AuxGroup > const&) > 10: FEProblemBase::initialSetup() > 11: DwarfElephantRBExecutioner::init() > 12: MooseApp::executeExecutioner() > 13: MooseApp::run() > 14: > /home/2014-0004_focal_therapy/PhDs/AdapTT/Nikhil/ > DwarfElephant/./DwarfElephant-dbg() > [0x40d0b5] > 15: __libc_start_main > 16: > /home/2014-0004_focal_therapy/PhDs/AdapTT/Nikhil/ > DwarfElephant/./DwarfElephant-dbg() > [0x40cf02] > [0] > /home/2014-0004_focal_therapy/PhDs/AdapTT/Nikhil/moose/ > scripts/../libmesh/installed/include/libmesh/dof_map.h, > line 545, compiled Jul 17 2018 at 13:35:22 > 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 > > > I will give a little more information about what it is I am trying to do. I > have created RBConstruction, RBEIMConstruction, RBEvaluation and > RBEIMEvaluation classes of my own. I have also created structures for the > theta objects. Instead of creating rb and eim assembly objects, I am > assembling the rb and eim matrices over MOOSE. To do this, I initialize the > eim and rb construction objects by skipping matrix and vector assemblies. I > can give more details about my implementation. Since I am not very familiar > with the inner workings of libMesh, I am finding it difficult to debug the > libMesh related parts of my code. > It looks like something is uninitialized, but unfortunately I can't tell what it would be based on your description. You said that you skip matrix and vector assemblies, so that could lead to some uninitialized data. Have you reviewed reduced_basis_ex4 and tried to mimic the approach that is used there? (I guess you have since you said you created your own subclasses of the EIM classes.) Best, David On Mon, Jul 23, 2018 at 2:51 PM, Roy Stogner <roy...@ic...> wrote: > > On Mon, 23 Jul 2018, Nikhil Vaidya wrote: > > Starting InitializeRB::initialize() >> Assertion `!this->is_initialized()' failed. >> >> Detaching after fork from child process 17473. >> Stack frames: 13 >> 0: libMesh::print_trace(std::ostream&) >> 1: libMesh::MacroFunctions::report_error(char const*, int, char const*, >> char const*) >> 2: libMesh::System::init() >> > > In DwarfElephant, I am calling all the funtions called in the libMesh >> example 4 as they are. What could be the problem? >> > > The superficial problem looks simple enough: your System object(s) > already had init called (whether directly or via a data read) and now > your new class is trying to call init on them again. > > The root problem and fix depends on exactly what you're trying to do > there. > --- > Roy > ------------------------------------------------------------ ------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Libmesh-users mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libmesh-users |