On Mon, 7 Apr 2014, David Knezevic wrote:
>> Nope. The solver should easily handle multiple constraints
>> *affecting* a dof, but since we write each constraint row into the
>> matrix in place of the row corresponding to some dof's test function,
>> we need to have a way of choosing which dof gets used for which
>> constraint.
>
> Ah, OK. Yes, I can see that makes things trickier since it doesn't seem like
> there's a general way to choose which dof to overwrite with the constraint
> row.
Right. As long as there's just one constraint per dof things should
work out fine, but once you get legitimate overlap you've got to have
a way to resolve it.
>> The first nasty case I can think of is the combination of a simple
>> constraint on a vertical or horizontal wall (deltax = 0 or deltay = 0,
>> obviously gets applied to the deltax dof or the deltay dof
>> respectively) with a previously applied compound constraint on a
>> neighboring diagonal wall. Do we try to make sure that the compound
>> constraint gets set on the dof which won't be subsequently
>> constrained? Do we try to "move" compound constraints automatically
>> when we're overwriting them?
>
> This does sound nasty... Do you see a good general solution here?
I think it should always be safe to "move" a constraint onto a
not-yet-constrained dof. The only remaining catch is the interaction
with PeriodicBoundary constraints, where the constraints can involve
more than one processor at once.
> This makes me wonder if I should use Lagrange multipliers (via SCALAR
> variables) to impose the type of constraint I have in mind instead. That way
> we add the extra constraint rows to the system rather than modifying existing
> rows, which seems like it would avoid some complications. Though the downside
> of Lagrange multipliers is that it adds dofs to the system and turns it into
> a saddle-point problem, so certainly not a free lunch!
I'd prefer to try to get the compound constraints working, but I'll
understand if you want to back out. If you do want to futz with the
Lagrange multiplier formulation, try playing around with the PETSc
fieldsplit stuff I recently hooked us up to? I was never able to make
it more efficient than tuned block Jacobi + ILU on incompressible flow
problems, but it might do much better with a Schur block that only
needs O((1/h)^{d-1}) instead of O((1/h)^d) dofs.
---
Roy
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
