>>> 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.
OK, that approach doesn't sound too nasty...
>
>> 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.
OK. I do like the sound of compound constraints, so I'm happy to work on
this too. Sounds like your "move the constraint" approach could work well.
Do you have a first item on the to-do list here? Maybe getting it to
work in the case where we don't have any "conflicting constraints" first?
As I said, I'm happy to work on this (though I'm not too familiar with
the guts of the constraint code...)
> 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.
If I do use Lagrange multipliers for Dirichlet BCs, then I'll be sure to
have a look at this.
Thanks,
David
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
