New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v1.3.0 branch started #1593
Comments
jwpeterson
added a commit
that referenced
this issue
Feb 16, 2018
jwpeterson
added a commit
that referenced
this issue
Feb 16, 2018
jwpeterson
pushed a commit
that referenced
this issue
Feb 17, 2018
There doesn't seem to be any way to get this behavior back in reinit() without creating a performance regression: most applications simply never need to move data in that direction. Refs #1593.
jwpeterson
pushed a commit
that referenced
this issue
Feb 17, 2018
Now that it's no longer relying on our old reinit() behavior, it passes "make check" fine again. Refs #1593.
jwpeterson
added a commit
to jwpeterson/libmesh
that referenced
this issue
Feb 19, 2018
jwpeterson
added a commit
to jwpeterson/libmesh
that referenced
this issue
Feb 19, 2018
When included alone, you apparently can't get away with just forward declarations of TypeVector and TypeTensor. The error messages I was getting were along the lines of: In file included from /Users/petejw/projects/libmesh_git/installed/include/libmesh/exact_error_estimator.h:25: /Users/petejw/projects/libmesh_git/installed/include/libmesh/function_base.h:136:18: error: implicit instantiation of undefined template 'libMesh::VectorValue<double>' virtual Output component(unsigned int i, ^ /Users/petejw/projects/libmesh_git/installed/include/libmesh/function_base.h:77:11: note: in instantiation of member function 'libMesh::FunctionBase<libMesh::VectorValue<double> >::component' requested here virtual ~FunctionBase (); ^ /opt/moose/llvm-3.9.0/bin/../include/c++/v1/memory:2541:13: note: in instantiation of member function 'libMesh::FunctionBase<libMesh::VectorValue<double> >::~FunctionBase' requested here delete __ptr; ^ Refs libMesh#1593.
jwpeterson
added a commit
to jwpeterson/libmesh
that referenced
this issue
Feb 19, 2018
We use std::unique_ptr in this header, but it was only being included by accident on the main compilers we test with. Compiling with GCC 5.4.0 on Linux Mint 18 uncovered this issue. Refs libMesh#1594. Refs libMesh#1593.
jwpeterson
added a commit
that referenced
this issue
Feb 19, 2018
jwpeterson
added a commit
that referenced
this issue
Feb 19, 2018
When included alone, you apparently can't get away with just forward declarations of TypeVector and TypeTensor. The error messages I was getting were along the lines of: In file included from /Users/petejw/projects/libmesh_git/installed/include/libmesh/exact_error_estimator.h:25: /Users/petejw/projects/libmesh_git/installed/include/libmesh/function_base.h:136:18: error: implicit instantiation of undefined template 'libMesh::VectorValue<double>' virtual Output component(unsigned int i, ^ /Users/petejw/projects/libmesh_git/installed/include/libmesh/function_base.h:77:11: note: in instantiation of member function 'libMesh::FunctionBase<libMesh::VectorValue<double> >::component' requested here virtual ~FunctionBase (); ^ /opt/moose/llvm-3.9.0/bin/../include/c++/v1/memory:2541:13: note: in instantiation of member function 'libMesh::FunctionBase<libMesh::VectorValue<double> >::~FunctionBase' requested here delete __ptr; ^ Refs #1593.
jwpeterson
pushed a commit
that referenced
this issue
Feb 26, 2018
jwpeterson
pushed a commit
that referenced
this issue
Feb 28, 2018
jwpeterson
added a commit
that referenced
this issue
Mar 5, 2018
For some reason in c3659b1 I thought this type was defined in petscblaslapack.h, but it seems to have been in petscsys.h for some time. This should help fix an issue raised over in xikaij/koala#3 where conflicting BLAS functions were being defined in both scalfmm and PETSc. Refs #1593.
jwpeterson
pushed a commit
that referenced
this issue
Mar 7, 2018
jwpeterson
pushed a commit
that referenced
this issue
Mar 8, 2018
This commit was created by running: git cherry-pick f2fb9fc f1a0aba c3c1ff7 8a89159 ae730e7 and squashing. * Comment out broken code in vexcl case too I really need to figure out if it's possible to fix roystgnr/MetaPhysicL#4 in a C++-standards-compatible way or if APIs need to be redone entirely. * Avoid "set but not used" warnings w/o MASA * boost.m4 shouldn't die on link failures This incorporates the PR tsuna/boost.m4#86 so that we can recover on systems where headers are found but libraries are not. * Double-check VexCL has all Boost prereqs Just because we have one Boost header doesn't mean we have every header and library we need. * Re-bootstrap Refs #1593.
jwpeterson
added a commit
that referenced
this issue
Mar 8, 2018
jwpeterson
added a commit
that referenced
this issue
Mar 12, 2018
jwpeterson
added a commit
that referenced
this issue
Mar 12, 2018
jwpeterson
pushed a commit
that referenced
this issue
Mar 15, 2018
Thanks to Vasileios Vavourakis for politely hinting that our documentation here was lacking. Refs #1593.
jwpeterson
added a commit
that referenced
this issue
Mar 16, 2018
This #define only applied to really old versions of GCC (2.95 and 2.96) which we no longer support. Refs #1593.
jwpeterson
added a commit
that referenced
this issue
Mar 16, 2018
These are used when Exodus is not available. Refs #1593.
jwpeterson
added a commit
that referenced
this issue
Mar 16, 2018
jwpeterson
pushed a commit
that referenced
this issue
Apr 9, 2018
It turns out that PETSc debug mode is our friend. Refs #1593.
jwpeterson
pushed a commit
that referenced
this issue
Apr 9, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tag this issue in the commit message of any commits you'd like cherry-picked over.
As usual, let's try to restrict the cherry-picked commits to bugfixes as much as possible and fight the urge to sneak in new features at the last minute.
The text was updated successfully, but these errors were encountered: