MOOSE not working after update

116 views
Skip to first unread message

Heather Sheldon

unread,
Feb 4, 2016, 10:57:46 PM2/4/16
to moose-users
We have just updated MOOSE on a Mac and a supercomputer, and neither is working. The error messages are different so they might be completely unrelated, but it seems a bit of a coincidence. Both were working just fine before we updated.

Error message on the Mac:

dyld: Symbol not found: __ZThn1056_N9AuxKernel16getSuppliedItemsEv

  Referenced from: /Users/kan071/projects/moose/modules/tensor_mechanics/lib/libtensor_mechanics-opt.0.dylib

  Expected in: flat namespace

 in /Users/kan071/projects/moose/modules/tensor_mechanics/lib/libtensor_mechanics-opt.0.dylib


Error message on the supercomputer:

[31m

*** ERROR ***
Invalid option "1" in MooseEnum.  Valid options (not case-sensitive) are "none crash jacobian jacobian_and_linear_systemnone". [39m

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00002aaab8195b15 in waitpid () from /lib64/libc.so.6
To enable execution of this file add
add-auto-load-safe-path /opt/gcc/4.9.0/snos/lib64/libstdc++.so.6.0.20-gdb.py
line to your configuration file "/home/ekanjirathingal/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/ekanjirathingal/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
info "(gdb)Auto-loading safe path"
#0  0x00002aaab8195b15 in waitpid () from /lib64/libc.so.6
#1  0x00002aaab8129cc1 in do_system () from /lib64/libc.so.6
#2  0x00002aaab024cbac in libMesh::print_trace(std::ostream&) () from /group/interns2015/ekanjirathingal/software/moose/scripts/../libmesh/installed/lib/libmesh_opt.so.0
#3  0x00002aaaada5fd9d in MooseEnum::operator=(std::string const&) () from /group/interns2015/ekanjirathingal/software/moose/framework/libmoose-opt.so.0
#4  0x00002aaaadbead8a in void Parser::setScalarParameter<MooseEnum>(std::string const&, std::string const&, libMesh::Parameters::Parameter<MooseEnum>*, bool, GlobalParamsAction*) () from /group/interns2015/ekanjirathingal/software/moose/framework/libmoose-opt.so.0
#5  0x00002aaaadbed81b in Parser::extractParams(std::string const&, InputParameters&) () from /group/interns2015/ekanjirathingal/software/moose/framework/libmoose-opt.so.0
#6  0x00002aaaadbf0cec in Parser::parse(std::string const&) () from /group/interns2015/ekanjirathingal/software/moose/framework/libmoose-opt.so.0
#7  0x00002aaaade86db2 in MooseApp::setupOptions() () from /group/interns2015/ekanjirathingal/software/moose/framework/libmoose-opt.so.0
#8  0x00002aaaade7c21a in MooseApp::run() () from /group/interns2015/ekanjirathingal/software/moose/framework/libmoose-opt.so.0
#9  0x0000000000404a88 in main ()
[0] /group/interns2015/ekanjirathingal/software/moose/framework/src/utils/MooseEnum.C, line 86, compiled Feb  4 2016 at 16:17:24
Rank 0 [Fri Feb  5 09:57:39 2016] [c0-0c0s2n0] application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0
_pmiu_daemon(SIGCHLD): [NID 00008] [c0-0c0s2n0] [Fri Feb  5 09:57:39 2016] PE RANK 0 exit signal Aborted
Application 4038381 exit codes: 134
Application 4038381 resources: utime ~1s, stime ~1s, Rss ~146612, inblocks ~325953, outblocks ~147
End time : 09:59:12
Finished

Andrew....@csiro.au

unread,
Feb 4, 2016, 11:14:13 PM2/4/16
to moose...@googlegroups.com

The errors are unrelated.  I don’t know about the first error – i would just “make clobber” and update_and_rebuild_libmesh and then rebuild moose as it’s likely you have a corrupted build somehow.

 

The second error comes from an input file – possibly one of the tensor_mechanics tests – that sets the parameter fspb_debug in a ComputeMultiPlasticityStress Material.  I changed the “fspb_debug” to be a moose enum, so you can’t set

 

fspb_debug = 1 (or any other integer)

 

anymore.  Instead you have to set fspb_debug to one of none; crash; jacobian; or jacobian_and_linear_system.  This parameter is used by developers (=me, basically) to debug the linear system building, and basically you should always set it to “none”.   It seems that your supercomputer is building AND testing moose, and the build succeeded but the test failed, but I don’t know how that test didn’t get updated, or maybe you haven’t actually updated moose properly on the supercomputer.

 

Does this help?

 

a

 

 

Ph: +61 7 3327 4497.  Fax: +61 7 3327 4666
Queensland Centre for Advanced Technologies
PO Box 883, Kenmore, Qld, 4069 
 

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/686af49a-8830-44c8-aef3-04c9f6ed75a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Heather Sheldon

unread,
Feb 5, 2016, 12:08:11 AM2/5/16
to moose-users
Ok we will try make clobber for the local installation. Thanks for that.

I didn't tell the supercomputer to run any tests as far as I'm aware! So I really don't understand what's going on there. There were some changes to the build script though since our previous (successful) builds. See attached. Maybe there is something strange in there? The build completed without any errors. I've also attached the log file from the build.

Cheers,
Heather
moose_build.sbatch
slurm-924829.out

Andrew....@csiro.au

unread,
Feb 5, 2016, 12:47:31 AM2/5/16
to moose...@googlegroups.com

OK, the error on the supercomputer seems to come from you (or ekanjirathingal) actually running moose on your own input file, not from when moose is building.  Have a look through the input file and see if you set “fspb_debug = 1”, and just set “fspb_debug = none” instead.

Heather Sheldon

unread,
Feb 5, 2016, 1:32:00 AM2/5/16
to moose-users
Great thanks, we did indeed have that in the input file. I just didn't find it when you first mentioned it because it is debug_fspb, not fspb_debug! Problem solved.

The local installation on the Mac is rebuilding now. Fingers crossed that will work too.

Thanks again.
Reply all
Reply to author
Forward
0 new messages