As for restricting to subdomains, let's just make something up as far as API an start from there. 

We can create a simple example showing incompNS decoupled from heat transfer where flow is in domain A and heat transfer is in A and B, but with different material properties and obviously no convection in B.

Thoughts?

-Ben


----- Original Message -----
From: libmesh-devel-bounces@lists.sourceforge.net <libmesh-devel-bounces@lists.sourceforge.net>
To: Roy Stogner <roy@stogners.org>
Cc: libmesh-users@lists.sourceforge.net <libmesh-users@lists.sourceforge.net>; libmesh-devel@lists.sourceforge.net <libmesh-devel@lists.sourceforge.net>
Sent: Mon Sep 15 14:06:10 2008
Subject: Re: [Libmesh-devel] Moving mesh problems

This is really great stuff.  We're still not using FEMSystem (maybe 
someday I'll merge my stuff with yours...), but it sounds like we'll 
be able to do this external to FEMSystem as well... right?  Right now 
we're solving everything Lagrangian... but we're probably going to end 
up with an ALE approach... especially when we get to Fluid Structure 
Interaction... and then we'll definitely need this capability.

As long as you're adding stuff that people have been looking for for a 
while... how about restricting variables to subdomains? ;-)

Derek

On Sep 15, 2008, at 12:59 PM, Roy Stogner wrote:

>
> I've just committed some FEMSystem changes to SVN that will allow
> users to let the library handle some of the implementation of moving
> mesh problems for us.  YourSystem->mesh_x_position(B, N) tells it "the
> mesh x coordinate is variable N in System number B", and then the
> FEMSystem base class of YourSystem takes care of moving element nodes
> to the correct positions before requesting any element residuals.
>
> The problem I'm solving right now is fully coupled, which is also
> easier to code for at the moment, so if (B != YourSystem->number()) I
> just throw libmesh_not_implemented().  Perhaps we shouldn't have made
> an official macro that sanctions developer laziness.
>
> The pseudo-convection term is also not yet in the library, just
> because I've been struggling to decide what to do about it.  (Assume
> the user's PDE is expressed in Eulerian terms and add it?  Assume
> Lagrangian terms and add nothing?  Anticipate coupled fluid/solid
> subdomains and give up?)  I've decided to include the term in a
> separate virtual method - like mass_residual, the hope is that most*
> users will be able to use the library default, whereas even weird**
> users will be able to successfully override it.
>
> The pseudoconvection (does anyone have a good idea for a name?) term
> will be going in shortly; anyone curious about the first changeset can
> check SVN now.  Ideas and feedback appreciated.
> ---
> Roy
>
>
> * - "most users": "users most like Roy"
> ** - "weird": "not like Roy"
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's 
> challenge
> Build the coolest Linux based applications with Moblin SDK & win 
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in 
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Libmesh-devel mailing list
> Libmesh-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel