OPM/opm-upscaling — pull request #19 by akva2 (2013-01-02 13:41:03+00:00)
Title: Elasticity upscaling - autumn update

hi,

this pull request includes most of the work i have done this autumn.

1) adds higher order multipliers (arbitrary order).
this allow enforcing periodicities on the multipliers, which give us a consistent (dual) function space. thus, we end up with a saddle point problem, with SPD subblocks, exactly as we should.

2) significantly improves the linear algebra
- switch to a proper iterative scheme (minres or gmres)
- adds a schur-based preconditioner for the multipliers
- fix some bugs, code cleanups, cosmetic improvements
- adds a bunch of tuning parameters (mostly related to the AMG), with (hopefully) sane defaults.

3) i have remove the LLM code. it was only of use for research purposes, and since it is available in git history no matter, i opted to remove it to simplify the code and get rid of a source of confusion.

4) some of the new classes are better suited upstream. i have started the processes, some are already included, some are still pending on the flyspray. but since it will take some time for dune 2.3 to be released, and then some additional time for opm to do the change, i include them here for now.

5) while i have the multithreading working, it required me to hack the AMG in dune to pieces. i have been in contact with @blattms and he said he will do the necessary restructuring in dune (in a clean way). i opted to keep this code out for now, since it will be a bit of a nightmare with the hacked classes in-tree, a very bad situation to be in.

6) memory optimizations. the code is now optimal in memory use (as in the single copy of the elasticity operator dominates).

@alfbr, the code will still struggle with millions of DOFs. it can chew through O(10^5) in acceptable time. this is for meshes dominated by irregularities and with large material jumps (parameters span approximately 5 orders of magnitude). for 'simpler' problems, millons should be doable as well. these are cuts from the mesh i got from olivier.

tuning of the AMG might help, but either i do something completely wrong or the graph traversals in the AMG implementation is not the most efficient. this severely limits the aggregation parameters that can be employed, and the AMG is thus not as efficient as it could be. i have yet to unravel this mystery. i suspect this might have a big impact, as i can see that even with a rather large coarse solver, the AMG is still not extremely efficient. then again, if i throw any other preconditioner at this problem, the problem isn't even close to solvable.. @blattms any insights / spine reactions / flames to throw my way?