On Thu, Feb 13, 2020 at 4:59 AM Bailey Curzadd <bcurza...@gmail.com> wrote:
> I developed a code based on libMesh to optimize components subjected to > extreme thermal loads. I use a gradient-based optimizer, and the > optimization problem has lots of constraint functions, so I have to perform > a direct sensitivity analysis where the two systems (thermal and static) > both have to be solved once for each design variable. There are many design > variables, so, for the sake of efficiency, I solve the system with all of > the RHS vectors packed into a matrix. Previously, I did this using PETSc > and SuperLU_DIST. For the sake of maintainability and efficiency, I am > replacing PETSc with Eigen at the moment, and have run into an issue that I > can't understand. > > The systems are evaluated using 4 separate functions (this is relevant > later): > 1) Solve temperatures > 2) Solve displacements > 3) Differentiate temperatures > 4) Differentiate displacements > > The solve steps use libMesh's interface and internal Eigen solver. Since > this can't be used to solve multiple RHS vectors at once, in each of the > differentiation functions I make a copy or const reference of the system > matrix using a mat() method I added to EigenSparseMatrix. I then create my > own Eigen solver, pack the RHS vectors for the sensitivity analysis into a > matrix and solve. I'm testing different variants; some of them work just > fine, but some of them crash, and I see no logical reason why. > > - If I use an Eigen::BiCGSTAB<EigenSM> solver for steps #3 and #4, > everything works as expected, even if I use the matrix copy, which has a > column-major storage order. > - If I change the solver in step #4 to Eigen::SparseLU, there is a > significant efficiency improvement, and everything works fine. > - However, if I change the solver in step #3 to Eigen::SparseLU, or even > just to Eigen::BiCGSTAB<Eigen::SparseMatrix<Number>>, I get the following > error message and the code crashes: > [snipped] > Valgrind confirms the confusing part: the choice of solver in the function > for step #3 (even the choice of the matrix type template parameter), causes > a memory error in the solver used in step #1. If I understand correctly what you are saying, a change to a later stage (#3) in the code somehow triggered a memory error in an earlier stage (#1) of the code. This likely means that there was a memory error in stage #1 all along, but it was just by random chance that you were not triggering it. Then, the change you made to stage #3 appeared to cause the error, but actually it was just uncovering something that was there all along. -- John _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
