Hi Nikolai, in the header dune/istl/io.hh there is a function matrixToMatlab (or similar) which writes the matrix in sparse format. For MultitypeBlockMatrices you have to convert the matrix to a BCRS matrix before. You can use the convert function in dumux/linear/matrixconverter.hh for that. So it's two lines in total.
Viele Grüße, Timo > Am 03.09.2018 um 08:36 schrieb Nikolai Andrianov <[email protected]>: > > Hi Dennis, > > Thanks for your feedback! > > Is there a method available to output the matrix to a text file so that the > matrix structure can be further explored e.g. in Matlab? Or maybe you could > point out the portion of the code which I could use for inspiration to write > such output myself.. > > Also, have you explored whether the linear solver crash is related to the > numerical differentiation used? > > Thanks, > Nikolai > > > From: Dumux <[email protected]> On Behalf Of Dennis > Glaser > Sent: Friday, August 31, 2018 20:27 > To: [email protected] > Subject: Re: [DuMuX] Linear solver crash > > Hi Nikolai, > > I think the solver chosen in the exercise is not optimal for the matrix > structures you have in the coupled fracture problem. We are still trying to > find better solution strategies, however, in dumux/linear/seqsolverbackend.hh > you can find two solvers that are designed for matrix structures like the one > you have: > > BlockDiagILU0BiCGSTABSolver > > BlockDiagAMGBiCGSTABSolver > > You can try these although I wouldn't put too much hope in it solving your > problem. You can always use a direct solver if your system is not too big, > i.e. the UMFPackBackend or the SuperLUBackend. These should always work but > might need a lot of memory and much more cpu time. You need to have umfpack > and/or superlu installed though. > > I hope this helps! > > Best wishes, > Dennis > > > > > On 31.08.2018 16:13, Nikolai Andrianov wrote: > Dear DuMuX experts, > > While working on a modification of the > dumux-course/exercises/exercise-fractures test case I observed that the > linear solver crashes if the mesh is too fine. This results in cutting the > Newton’s time step, which in my case however does not help either.. > > This behavior is illustrated on the > https://git.iws.uni-stuttgart.de/andrian/rate-sensitivity project on github: > depending on the mesh density specified in the .geo files grids/fracs_bad.geo > or grids/fracs_ok.geo, the linear solver either crashes, or the simulation > proceeds as expected. > > Your feedback is greatly appreciated. > > Many thanks, > Nikolai > > > > > _______________________________________________ > Dumux mailing list > [email protected] > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > > _______________________________________________ > Dumux mailing list > [email protected] > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
_______________________________________________ Dumux mailing list [email protected] https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
