Hi Thomas, Yes, I agree in that the online documentation (like in many other Trilinos packages) is not up to scratch. Have you had a look at the user guide <https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwjTrPDz4LvQAhVKDsAKHWwKB3cQFggiMAA&url=https%3A%2F%2Fsoftware.sandia.gov%2Fmesquite%2Fdoc-2.99%2Fusers-guide.pdf&usg=AFQjCNF1cZ7sPzlsVr2yZGC9CO7pbwiRlQ&sig2=TsHuv3RRITyRzsAW0PeSNQ&cad=rja>? I think that chapter 6 is particularly relevant to your application. This is much better than the online docs, and gives some worked through examples. However, I think we can both agree that we're spoiled by deal.II's level of detail in the documentation, so its still a little harder to digest and perhaps not all of the driver routines are well demonstrated or discussed in depth.
In truth, I've never used Mesquite programmatically before, but I've found myself using it many times indirectly through Cubit. This, and the fact that the primary author is clearly a very big name in mesh optimisation, was (and still is) my driver for wanting to include it into deal.II. It also has a lot of functionality that would be very tedious to reproduce individually. If its useable in the context of mesh optimisation of CAD applications (i.e. through Cubit), I reckon it should be good for most applications. I don't have a new version of Cubit/Trellis, but if a more recent version still ships with Mesquite then, in my opinion, that speaks towards the quality of the toolbox, regardless of whether its mature and stagnated or not. But maybe some other folk would disagree with this assessment. Its certainly a risk that one might hit an issue that is unresolvable; but then again, Mesquite is open-source <https://github.com/trilinos/mesquite> along with the Trilinos suite, so one could always write a patch for it. As a side point, this also gives you access to some worked examples <https://github.com/trilinos/mesquite/tree/master/testSuite>. Ultimately I can't tell you what path is best to go down for your particular application because (a) I have no real familiarity with the problem you're solving and (b) I'm certainly no expert in mesh optimisation (I've implemented one suite of routines plus extensions to perform such an operation; see Jasak "Automatic mesh motion for the unstructured Finite Volume Method" <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.126.6838&rep=rep1&type=pdf>). So I can't say for certain that this will [be also to] solve your particular problem. I also can't weigh up the effort it takes to implement a set of wrappers for it versus solving the problem some other way. I went the "other way" route, solved my mesh optimisation problem and was left with the impression that (for my application) it would have been better to bite the bullet and have used Mesquite or some other focussed mesh optimisation toolkit. If you decide against using it then *one day* I'll get around to writing my wrappers myself because I am of the opinion that the power of the toolkit for traditional applications outweighs is stagnation. However, I just won't be doing this myself in the immediate future. J-P -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
