From: Michael SCHINDLER <mschindler@us...>  20070508 22:04:20

Hello, it is fine that you are rewriting the constraint system. I remember to have done this quite some time ago because I happened to need user constraints and did not understand the recursive constraints. I propose to include inhomogeneous constraints. Up to now, only constraint equations of the type sum_i weight_i * dof_i = 0 are allowed. This will not even permit the implementation of a simple Dirichlet boundary condition using constraints. An inhomogeneous constraint would have a righthand side here, sum_i weight_i * dof_i = f The way to implement this is, of course, to build the constraints for the matrix and the righthandside vector at the same time. Best Michael. On 08.05.07, John Peterson wrote: > Kirk, Benjamin (JSCEG) writes: > > I'm relying on y'all to help me make sense of these ideas and to post > > them to the list. All of the sudden I cannot send anything to the > > lists: > > > > < ndjsbar02.ndc.nasa.gov #5.0.0 XSpamFirewall; host > > mail.sourceforge.net[66.35.250.206] said: 550Postmaster verification > > failed while checking <benjamin.kirk1@...> 550Called: > > 198.120.25.85 550Sent: RCPT TO:<postmaster@...> > > 550Response: 550 <postmaster@...>: Recipient address rejected: > > local mail delivery is disabled 550Several RFCs state that you are > > required to have a postmaster 550mailbox for each mail domain. This > > host does not accept mail 550from domains whose servers reject the > > postmaster address. 550 Sender verify failed (in reply to RCPT TO > > command)> > > > > > > > > In any case, after talking with John I think that the easiest fix for > > all this nonsense it to remove the recursion out of the constraint > > matrix construction. The idea I have is as follows: > > > > (1) build up the _dof_constraints in the standard way. As implemented, > > this produces a whole series of level1 constraints. > > > > (2) process the _dof_constraints such that there are no implicit > > constraints. That is, if a=f(b,c) and b=g(c,d) > > then perform the function composition such that a=f(g(c,d),c) direcely. > > More clearly, modify all dof constraints as to be written in terms of > > active DOFS only. > > > > (3) build the constraint matrix, there will be no need for recursion. > > > > > > Now the complication gets shifted to step (2), but it should be much > > more clear. Note that all the level1 constraints must be constructed > > first. Then I envision something like this > > > > for each row of _dof_constraints > > for each entry in the row > > if the constraining dof is itself constrained > > replace the dof with its constraints scaled by the weight > > end > > until there are no constrained dofs in the row > > end > > > > > > > > So return to the case that was mentioned yesterday: > > abcd > > > > After step (1) > > > > _dof_constraints[b] = .5*a + .5*c > > _dof_constraints[c] = .5*a + .5*d > > > > Now, in step 2, since c is constrained we need to modify the first row: > > > > _dof_constraints[b] = .5*a + .5*(.5*a + .5*d) > > = .75*a + .25*d > > > > (and now we are done since neither a nor d are constrained.) > > > > > > This should avoid the issue that was occuring before. The problem was > > stopping the recursion when the size of an object did not change, when > > in fact it should terminate when the constraint is formed only in terms > > of active dofs. > > > > > > Is this clear? I think implementing this as a step at the end of > > DofMap::create_dof_constraints() should be fairly straightforward. > > > > Thoughts?? > > > > Ben > > > > > > > > > > > > > >  > This SF.net email is sponsored by DB2 Express > Download DB2 Express C  the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers  Michael Schindler Laboratoire de PhysicoChimie Théorique. ESPCI. 10 rue Vauquelin, 75231 Paris cedex 05, France. Tel: +33 (0)1 40 79 58 41 Fax: +33 (0)1 40 79 47 31 http: http://www.pct.espci.fr/~michael 