Re: MOLTRES installation issue
Alex Lindsay
By default "heavy" tests don't get run since they can take a few minutes. Since the other ones passed I think your Moltres application is ready to go! If you ever do want to run the heavy test you can run all the tests with `run_tests --all` or just the heavy tests with `run_tests --heavy`.Thanks Alex that worked and it passed the tests (with the first test being skipped because it was "heavy"?). Yep no worries you can put this on the moltres-users group no worries, I probably should have just asked it there in the first place, and I will use it from now on.
I have not thought about this myself but it sounds very interesting. It sounds like something we could wrap in a MultiApp. So we probably wouldn't write it as MOOSE code (since MOOSE is explicitly for finite element methods (although you can choose basis functions such that you can perform finite volume as well)), but we could couple the DEM code to the Moltres/MOOSE code with MultiApp.
I will have a play around with MOLTRES and see if I can understand how it all works. As a direction that I would like to go, have you thought about including DEM particle simulations into MOLTRES for simulation of PB-FHR designs like Berkeley's or the TMSR-SF? And if not do you think there is the scope for it to be developed within MOLTRES to have a FEM-DEM-Neutronic coupled simulation of a PB-FHR?
Alex
Thanks,
Robert Mardus-Hall
PhD Candidate, School of Mechanical and Manufacturing Engineering
UNSW Australia
E: r.mard...@student.unsw.edu.au
W: engineering.unsw.edu.au/mechanical-engineering
From: Alex Lindsay <al...@illinois.edu>
Sent: 29 June 2017 00:55:45
To: Robert Mardus-Hall
Subject: Re: MOLTRES installation issueUnfortunately, updating your MOOSE environment created the new issues with the undefined references because you probably introduced a new compilation environment which can affect compilation flags and preprocessing directives. So we could probably try and pick off the stale object files strategically, but the most sure-fire way to ensure a complete build is to do the following:
cd ~/projects/moltres
git clean -fxd
cd ~/projects/moltres/squirrel
git clean -fxd
cd ~/projects/moose/libmesh
git clean -fxd
cd ~/projects/moose
git clean -fxd
export METHODS='opt dbg'
scripts/update_and_rebuild_libmesh.sh
cd ~/projects/moltres
make -j8
METHOD=dbg make -j8
Note that I've given directions for building both 'opt' and 'dbg' executables. When doing analysis I always use 'opt', but if I run into undesirable behavior, I always jump into a debugger and use the 'dbg' executable.
May I cc this discussion to the moltres-users forum? Questions like these could be very helpful to future Moltres users.
Alex
On 06/28/2017 12:00 AM, Robert Mardus-Hall wrote:
Hi Alex,
Thanks for that, I pulled the most recent MOOSE version and have progress a bit further in the Moltres installation. I seem to be running into a problem with the creation of the moltres-opt executable, with a conflict between libnetcdf.so.7 and libnetcdf.so.11 possibly. I'm not sure if you have seen this problem before.
I updated the MOOSE environment to the latest release (1.1-29), but this did not fix the problem either.
Below are the git show -n 1 and git branch -a outputs you also asked for just incase you still need them to help diagnose the issue.
>>robert@XPS15:~/projects/moltres$ git show -n 1commit 4fc91daf8bafa9aec1e67c8b1725330dcd158fe4Merge: da41f90 c8e4386Author: Alex Lindsay <alexlin...@gmail.com>Date: Mon Jun 26 17:04:44 2017 -0500
Merge pull request #31 from lindsayad/3d_heat_transfer3d heat transfer
>>robert@XPS15:~/projects/moltres$ git branch -a* develremotes/origin/HEAD -> origin/develremotes/origin/develremotes/origin/master
So this is the error I am getting now, a problem linking the executable, which it seems to not end up creating, possibly due to the libnetcdf.so.7 conflicting with libnetcdf.so.11. I think I recall a similar conflict message appearing when compiling MOOSE, however the tests all passed and nothing appeared to be wrong.
>>robert@XPS15:~/projects/moltres$ make -j8MOOSE Updating header /home/robert/projects/moose/modules/module_loader/include/base/ModuleLoaderRevision.h...MOOSE Updating header /home/robert/projects/moose/modules/phase_field/include/base/PhaseFieldRevision.h...MOOSE Updating header /home/robert/projects/moose/modules/tensor_mechanics/include/base/TensorMechanicsRevision.h...MOOSE Updating header /home/robert/projects/moose/modules/navier_stokes/include/base/NavierStokesRevision.h...MOOSE Updating header /home/robert/projects/moose/modules/fluid_properties/include/base/FluidPropertiesRevision.h...Linking Executable /home/robert/projects/moltres/moltres-opt.../usr/bin/ld: warning: libnetcdf.so.7, needed by /home/robert/projects/moose/framework/contrib/pcre/libpcre-opt.so, may conflict with libnetcdf.so.11/home/robert/projects/moose/modules/tensor_mechanics/lib/libtensor_mechanics-opt.so: undefined reference to `non-virtual thunk to AuxKernel::coupledDotDu(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)'/home/robert/projects/moose/modules/tensor_mechanics/lib/libtensor_mechanics-opt.so: undefined reference to `non-virtual thunk to AuxKernel::getVectorPostprocessorValue(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'/home/robert/projects/moose/modules/phase_field/lib/libphase_field-opt.so: undefined reference to `non-virtual thunk to InitialCondition::getSuppliedItems()'/home/robert/projects/moose/modules/tensor_mechanics/lib/libtensor_mechanics-opt.so: undefined reference to `non-virtual thunk to AuxKernel::getVectorPostprocessorValueByName(VectorPostprocessorName const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'/home/robert/projects/moose/modules/tensor_mechanics/lib/libtensor_mechanics-opt.so: undefined reference to `RankTwoTensor::operator()(unsigned int, unsigned int) const'/home/robert/projects/moose/modules/tensor_mechanics/lib/libtensor_mechanics-opt.so: undefined reference to `RankFourTensor::operator()(unsigned int, unsigned int, unsigned int, unsigned int) const'/home/robert/projects/moose/modules/phase_field/lib/libphase_field-opt.so: undefined reference to `non-virtual thunk to GeneralUserObject::getVectorPostprocessorValueByName(VectorPostprocessorName const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'/home/robert/projects/moose/modules/phase_field/lib/libphase_field-opt.so: undefined reference to `non-virtual thunk to InitialCondition::getRequestedItems()'/home/robert/projects/moose/modules/tensor_mechanics/lib/libtensor_mechanics-opt.so: undefined reference to `RankFourTensor::operator()(unsigned int, unsigned int, unsigned int, unsigned int)'/home/robert/projects/moose/modules/phase_field/lib/libphase_field-opt.so: undefined reference to `non-virtual thunk to GeneralUserObject::getVectorPostprocessorValue(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'/home/robert/projects/moose/modules/tensor_mechanics/lib/libtensor_mechanics-opt.so: undefined reference to `non-virtual thunk to AuxKernel::coupledCallback(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool)'/home/robert/projects/moose/modules/phase_field/lib/libphase_field-opt.so: undefined reference to `non-virtual thunk to GeneralUserObject::getRequestedItems()'/home/robert/projects/moose/modules/phase_field/lib/libphase_field-opt.so: undefined reference to `RankTwoTensor::operator()(unsigned int, unsigned int)'/home/robert/projects/moose/modules/tensor_mechanics/lib/libtensor_mechanics-opt.so: undefined reference to `non-virtual thunk to AuxKernel::getRequestedItems()'/home/robert/projects/moose/modules/phase_field/lib/libphase_field-opt.so: undefined reference to `non-virtual thunk to GeneralUserObject::getSuppliedItems()'/home/robert/projects/moose/modules/tensor_mechanics/lib/libtensor_mechanics-opt.so: undefined reference to `non-virtual thunk to ElementIntegralPostprocessor::getValue()'/home/robert/projects/moose/modules/phase_field/lib/libphase_field-opt.so: undefined reference to `non-virtual thunk to DerivativeMultiPhaseBase::initialSetup()'/home/robert/projects/moose/modules/tensor_mechanics/lib/libtensor_mechanics-opt.so: undefined reference to `non-virtual thunk to AuxKernel::getSuppliedItems()'/home/robert/projects/moose/modules/tensor_mechanics/lib/libtensor_mechanics-opt.so: undefined reference to `non-virtual thunk to AuxKernel::coupledDot(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)'collect2: error: ld returned 1 exit status/home/robert/projects/moose/framework/app.mk:184: recipe for target '/home/robert/projects/moltres/moltres-opt' failedmake: *** [/home/robert/projects/moltres/moltres-opt] Error 1
Thanks for your help.
Kind regards,
Robert Mardus-Hall
PhD Candidate, School of Mechanical and Manufacturing Engineering
UNSW Australia
E: r.mard...@student.unsw.edu.au
W: engineering.unsw.edu.au/mechanical-engineering
From: Lindsay, Alexander <al...@illinois.edu>
Sent: 27 June 2017 22:37:47
To: Robert Mardus-Hall
Subject: Re: MOLTRES installation issueOops should have looked more closely at the error message to begin with...I know exactly what the issue is. When did you last update MOOSE? I submitted a pull request last week or so that added the VectorPostprocessorInterface for boundary conditions so you will need to pull down the most recent MOOSE in order for that compilation to workHi Alex,
It was great to meet yourself and Katy at the Berkeley MSR workshop the other week and learn about what you are doing with Moltres. I just got back from the test of my holiday in the US yesterday, and today I am trying to install Moltres from the instructions given on Github. I have followed the MOOSE install and run the tests, which passed everything (except for any skipped tests), and am now having trouble with compiling Moltres.
After cloning moltres into the ~/projects directory, and the steps that follow it, I am running the make -j8 command. I get the following output:
MOOSE Generating Header /home/robert/projects/moltres/include/base/MoltresRevision.h...MOOSE Compiling C++ (in opt mode) /home/robert/projects/moltres/squirrel/src/bcs/ChannelGradientBC.C...MOOSE Compiling C++ (in opt mode) /home/robert/projects/moose/modules/phase_field/src/auxkernels/BndsCalcAux.C...MOOSE Compiling C++ (in opt mode) /home/robert/projects/moose/modules/phase_field/src/auxkernels/EBSDReaderPointDataAux.C...MOOSE Compiling C++ (in opt mode) /home/robert/projects/moose/modules/phase_field/src/auxkernels/TotalFreeEnergy.C...MOOSE Compiling C++ (in opt mode) /home/robert/projects/moose/modules/phase_field/src/auxkernels/PFCEnergyDensity.C...MOOSE Compiling C++ (in opt mode) /home/robert/projects/moose/modules/phase_field/src/auxkernels/EBSDReaderAvgDataAux.C...MOOSE Compiling C++ (in opt mode) /home/robert/projects/moose/modules/phase_field/src/postprocessors/GrainBoundaryArea.C...MOOSE Compiling C++ (in opt mode) /home/robert/projects/moose/modules/phase_field/src/postprocessors/GrainTrackerInterface.C.../home/robert/projects/moltres/squirrel/src/bcs/ChannelGradientBC.C: In constructor ‘ChannelGradientBC::ChannelGradientBC(const InputParameters&)’:/home/robert/projects/moltres/squirrel/src/bcs/ChannelGradientBC.C:21:96: error: ‘getVectorPostprocessorValue’ was not declared in this scope_channel_gradient_axis_coordinate(getVectorPostprocessorValue("channel_gradient_pps", _axis)),^MOOSE Compiling C++ (in opt mode) /home/robert/projects/moose/modules/phase_field/src/postprocessors/PFCElementEnergyIntegral.C.../home/robert/projects/moose/framework/build.mk:86: recipe for target '/home/robert/projects/moltres/squirrel/src/bcs/ChannelGradientBC.x86_64-unknown-linux-gnu.opt.lo' failedmake: *** [/home/robert/projects/moltres/squirrel/src/bcs/ChannelGradientBC.x86_64-unknown-linux-gnu.opt.lo] Error 1make: *** Waiting for unfinished jobs....
I tried running the tests anyway from the moltres root directory just to check, but it is looking for moltres-opt which does not exist in the ~/projects/moltres directory, I assume because it has not actually compiled.
I'm not sure if you have seen this problem before, or if you know a way to fix it. I am really looking forward to using Moltres and seeing if I can work with you and the rest of the ARFC group at Illinois in the future.
Kind regards,
Robert Mardus-Hall
PhD Candidate, School of Mechanical and Manufacturing Engineering
UNSW Australia
E: r.mard...@student.unsw.edu.au
W: engineering.unsw.edu.au/mechanical-engineering
