(I'm copying this to the -devel list, feel free to take -users off any reply
to keep its traffic down)
> Okay, so dxyz seems to be appropriate for storing the metric - that
> problem is solved then. Now, one last thing: All DOFs are at the
> vertices (and we have only one DOF per vertex). Ie the g
Okay, so dxyz seems to be appropriate for storing the metric - that
problem is solved then. Now, one last thing: All DOFs are at the
vertices (and we have only one DOF per vertex). Ie the global vector and
matrices have dimension M or MxM if M is the number of mesh vertices.
However, each DOF is no
This is from my phone, sorry for any typos.
--
Norbert Stoop
http://tsonny.ch/
On 18.11.2008, at 19:06, Roy Stogner <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 18 Nov 2008, Norbert Stoop wrote:
>
>> Roy Stogner wrote:
>>
>>> Does this have to be stored as a vector? Or stored at all?
>>> Patch::add
On Tue, 18 Nov 2008, Norbert Stoop wrote:
> Roy Stogner wrote:
>
>> Does this have to be stored as a vector? Or stored at all?
>> Patch::add_point_neighbors() should do what you want on the fly. If
>> it's worthwhile a caching version of that could be created.
>
> Hm, the patch needs a special
Roy Stogner wrote:
>
> On Tue, 18 Nov 2008, Norbert Stoop wrote:
>
>> Okay, the basic functionality for subdivision surface FEM should be
>> implemented now, but I have a question regarding proper integration into
>> libmesh:
>
>> These elements need some additional variables to store
>> subdivi
On Tue, 18 Nov 2008, Norbert Stoop wrote:
> Okay, the basic functionality for subdivision surface FEM should be
> implemented now, but I have a question regarding proper integration into
> libmesh:
> These elements need some additional variables to store
> subdivision surface properties. For exa
Hi again,
Okay, the basic functionality for subdivision surface FEM should be
implemented now, but I have a question regarding proper integration into
libmesh:
These elements need some additional variables to store
subdivision surface properties. For example, a vector of the 1-ring of
neighbors is
Derek Gaston wrote:
> On Nov 11, 2008, at 10:02 AM, Roy Stogner wrote:
>
>> On Tue, 11 Nov 2008, Norbert Stoop wrote:
>>
>>> To summarize, we abuse the traditional mesh as a control mesh. We define
>>> a parametrization of the limit surface which naturally gives us the
>>> needed mathematical obje
On Tue, 11 Nov 2008, Benjamin Kirk wrote:
> So why not compute instead
>
> phi(Xc) = phi(Xc(X)) = phi(Xc(X(xi))) and
> (dphi/dXc)(Xc) = [(dphi/dxi)(dxi/dX)(dX/dXc)](Xc(X(xi)))
>
> Where Xc(X) is the C1 geometry representation provided by the "geometry
> system" described previously.
This is what
>> Declare a 'geometry system' which uses some C1 fe basis (clough-tocher
>> does come to mind...).
>
> Clough-Tocher may not be ideal. Since they're not h-hierarchic, you
> can't refine without (very slightly) changing the result. That's not
> a problem for my applications but it may be for thi
On Tue, 11 Nov 2008, Kirk, Benjamin (JSC-EG) wrote:
> Pass in a standard 6-noded quadratic triangulation which discretuzes the
> manifold.
>
> Declare a 'geometry system' which uses some C1 fe basis (clough-tocher
> does come to mind...).
Clough-Tocher may not be ideal. Since they're not h-hie
, the memory used is probably acceptable...
Is there a show-stopper I am overlooking?
-Ben
- Original Message -
From: Derek Gaston <[EMAIL PROTECTED]>
To: Roy Stogner <[EMAIL PROTECTED]>
Cc: Libmesh-users@lists.sourceforge.net
Sent: Tue Nov 11 11:25:22 2008
Subject: Re: [Li
On Nov 11, 2008, at 10:02 AM, Roy Stogner wrote:
> On Tue, 11 Nov 2008, Norbert Stoop wrote:
>
>> To summarize, we abuse the traditional mesh as a control mesh. We
>> define
>> a parametrization of the limit surface which naturally gives us the
>> needed mathematical objects such as derivatives,
On Tue, 11 Nov 2008, Norbert Stoop wrote:
> To summarize, we abuse the traditional mesh as a control mesh. We define
> a parametrization of the limit surface which naturally gives us the
> needed mathematical objects such as derivatives, surface patches etc.
> Since we *know* where each control
Roy Stogner wrote:
>>> Interesting. I've heard of subdivision elements being used for
>>> surface mesh refinement, but in a context where the subdivision
>>> surface was only C1 in the limiting sense; each discrete mesh was
>>> still faceted. We could do something like that relatively easily, bu
(Note... I started this email earlier this morning... but just now
finished it and there are like 10 new emails in this thread so forgive
me if I'm off-topic now)
On Nov 11, 2008, at 7:42 AM, Benjamin Kirk wrote:
> If we had a C1 mapping element I'd think we could project the C0
> subdivisio
(Roy, obviously we were *both* thinking of the 3D volume case...)
So we should be able to proceed with element refinement as usual, but then
afterward process all the boundary faces with a defined geometry and snap
points to it... The final step then would need to do something like
'enforce_co
On Tue, 11 Nov 2008, Kirk, Benjamin (JSC-EG) wrote:
> Well, I was just thinking about the various places we use the inverse
> map... If they are affine the newton iteration would be fast, but setting
> up the map would be be (some unquantified amount) more expensive than in
> the lagrange case.
On Tue, 11 Nov 2008, Norbert Stoop wrote:
> Roy Stogner wrote:
>>
>> On Tue, 11 Nov 2008, Norbert Stoop wrote:
>>
>>> Recently, subdivision surfaces were suggested as an alternative way to
>>> construct C1 (and higher) conforming surface meshes for finite element
>>> simulations.
>>
>> Interesti
d the higher-order (0
valued) coefficients for the affine elements in the volume.
-Ben
- Original Message -
From: Roy Stogner <[EMAIL PROTECTED]>
To: Kirk, Benjamin (JSC-EG)
Cc: Libmesh-users@lists.sourceforge.net
Sent: Tue Nov 11 09:09:05 2008
Subject: Re: [Libmesh-users]
Kirk, Benjamin (JSC-EG) wrote:
> No, I'm not suggesting anything I'm particular, I was just speculating about
> how we wound define a C1 surface...
>
> If anyone is interested I think I have some subdivision surface code I got
> from Bob Haimes at MIT. I'll see if I can dig it up...
Yes, I am,
On Tue, 11 Nov 2008, Benjamin Kirk wrote:
> To keep the code anything resembling efficient, we'd need to make sure
> multiple mapping types are supported at the same time... I'd think we want
> to use the C1 map *only* on elements with a face or edge trace on the
> boundary of interest.
Are the
Kirk, Benjamin (JSC-EG) wrote:
> Phi_ etc... Are the basis functions of the fe discretication, psi are the
> mapping functions.
>
> Btw, you are using shells and only solving on the manifold(?), or is there an
> interior volume problem too?
No, it's only solved on the manifold. You would sugges
Roy Stogner wrote:
>
> On Tue, 11 Nov 2008, Norbert Stoop wrote:
>
>> Recently, subdivision surfaces were suggested as an alternative way to
>> construct C1 (and higher) conforming surface meshes for finite element
>> simulations.
>
> Interesting. I've heard of subdivision elements being used f
>> Recently, subdivision surfaces were suggested as an alternative way to
>> construct C1 (and higher) conforming surface meshes for finite element
>> simulations.
>
> Interesting. I've heard of subdivision elements being used for
> surface mesh refinement, but in a context where the subdivisio
On Tue, 11 Nov 2008, Norbert Stoop wrote:
> Recently, subdivision surfaces were suggested as an alternative way to
> construct C1 (and higher) conforming surface meshes for finite element
> simulations.
Interesting. I've heard of subdivision elements being used for
surface mesh refinement, but
Hi,
Recently, subdivision surfaces were suggested as an alternative way to
construct C1 (and higher) conforming surface meshes for finite element
simulations. Now, I'm wondering how hard it would be to implement such
elements in libmesh:
Assuming triangular elements, the subdivision surface approa
27 matches
Mail list logo
