Message: 3
Date: Wed, 15 Mar 2006 14:45:59 +0100
From: Michael Schindler < m-schindler@users.sourceforge.net>
To: libmesh-users@lists.sourceforge.net
Subject: Re: [Libmesh-users] constraint function

Hello Wout,

On 15.03.06, Wout Ruijter wrote:
> This is not so much about the actual constraint function as it is
> about the library facilitating user defined constraints.
> Do you agree with the suggested modified system.C ? Or do you apply the
> constraints in another phase of the analysis?
>
> By the way, Ben, I answered your mail presuming that AMR was steered
> to give periodic meshes as well, which is something I do but it is not
> general at all.
> This means that I agree with your suggestion of having
> un-overwriteable AMR related constraints.
> I guess the options are broadly:
> 1 - First apply AMR constraints, then user constraints -> user
> checks/decides whether to overwrite AMR constraints
> 2 - First user constraints, then AMR constraints -> AMR always
> overwrites any other constraints
> 3 - First AMR constraints, then user -> constraints are
> un-overwriteable, so AMR constraints prevail.
> 4 - There is another option, where a dofconstraintrow can have a type
> variable, and constraints are overwritten/ignored depending on their
> type.
>
> I think the third is the best option, if there are no cases in which
> AMR constraints need to be able to overwrite each other.

I have done it with option 1. This requires the user to be cautious
with the existing constraints from AMR (!).
Options 2 and 3 made no sense in my case. I have quite a general
implementation of periodic boundaries. I do not map nodes onto nodes
but find for the ``eliminated'' nodes the weights on the "kept" side.
The picture looks something like this:

      * x *  x * x * x  *   x  *    x   * x *  "eliminated"
                    ^
                    |  mapping
                    |
      *  x  *    x    *    x     *    x     *  "kept"

* are vertices, x are second-order nodes.
Thus, the AMR constraints at the "eliminated" side must be broken in
order to keep the solution as continuous as possible. It would also be
possible to keep the AMR constraints, but then only the vertices of
the "eliminated" side can be constrained in terms of the "kept" side.

Another problem is caused by your option 3: The nodes which reside
both on a periodic boundary and on some other boundary, a wall or
something. I implemented the boundary condition also at the wall with
constraints. If I cannot overwrite the AMR constraint which may happen
to be also at such a node, then I am in trouble with the other
constraints.

Therefore, I think that option 1 is the best choice, although it is
not foolproof, and users may do strange things here.

Hello,Michael, I think the best choice  should not generate strange things. Libmesh must be easily to use for general users. I don't understant what you do with option 1. Could you give an example.

Michael.

--
"A mathematician is a device for turning coffee into theorems"
  Paul Erd�s.



--__--__--

_______________________________________________
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users


End of Libmesh-users Digest