Re: [Libmesh-users] dynamically add/remove dofs

[Roy Stogner]

On Fri, 27 Jan 2017, Manav Bhatia wrote:

> If I create multiple elements that occupy the same (exact) spatial
> domain, but with distinct nodes (multiple nodes defined at the same
> spatial point), would there be any negative implication for
> ReplicatedMesh or ParallelMesh data structures?

If you want to be able to do restarts with nodes which are
topologically distinct but spatially coincident, you have to configure
libMesh with --enable-unique-id, which adds another 8 bytes to every
node and element.
---
Roy

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] dynamically add/remove dofs

[Manav Bhatia]

If I create multiple elements that occupy the same (exact) spatial domain, but 
with distinct nodes (multiple nodes defined at the same spatial point), would 
there be any negative implication for ReplicatedMesh or ParallelMesh data 
structures? 

This is in relation to the implementation of XFEM where sometimes duplicate 
entities are defined for multiple levels of enrichment functions. 

Thanks,
Manav



> On Jan 27, 2017, at 10:26 AM, Roy Stogner  wrote:
> 
> 
> On Fri, 27 Jan 2017, Manav Bhatia wrote:
> 
>> The subdomain approach sounds promising.  I will look into this and
>> the SCALAR variable.
> 
> SCALAR you want to avoid for locally supported variables in fully
> implicit solves.  We generate dense rows and columns for each SCALAR
> dof, which is not what you want for efficiency when you know a priori
> that nearly all that coupling isn't really there.
> 
>> Another question:  the application in mind is topology optimization
>> with XFEM, where voids can form/disappear in a continuum during the
>> course of optimization. I don’t want to modify the mesh during this
>> procedure. So, if a certain portion of the domain becomes a void,
>> what would be the best approach to make the dofs inactive in that
>> void?
>> 
>> Can I simply iterate on the node/elem dofs and flag them as
>> active/inactive so that I don’t have to worry about
>> solving/specifying Dirichlet conditions for them?
> 
> I'd add a user constraint equation for each dof.
> ---
> Roy


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] dynamically add/remove dofs

[Roy Stogner]

On Fri, 27 Jan 2017, Manav Bhatia wrote:


The subdomain approach sounds promising.  I will look into this and
the SCALAR variable.


SCALAR you want to avoid for locally supported variables in fully
implicit solves.  We generate dense rows and columns for each SCALAR
dof, which is not what you want for efficiency when you know a priori
that nearly all that coupling isn't really there.


Another question:  the application in mind is topology optimization
with XFEM, where voids can form/disappear in a continuum during the
course of optimization. I don’t want to modify the mesh during this
procedure. So, if a certain portion of the domain becomes a void,
what would be the best approach to make the dofs inactive in that
void?

Can I simply iterate on the node/elem dofs and flag them as
active/inactive so that I don’t have to worry about
solving/specifying Dirichlet conditions for them?


I'd add a user constraint equation for each dof.
---
Roy--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] dynamically add/remove dofs

[John Peterson]

On Fri, Jan 27, 2017 at 9:02 AM, Manav Bhatia  wrote:

> Thanks for the clarification, John.
>
> Do you know if there have been XFEM implementations using libMesh in your
> group or elsewhere in the research community?
>

Yes, there is an XFEM module in MOOSE,
https://github.com/idaholab/moose/tree/devel/modules/xfem

It's fairly new and does not seem to be well-documented yet, but the people
who worked on it will answer questions about it over on
moose-us...@googlegroups.com.

-- 
John
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] dynamically add/remove dofs

[Roy Stogner]

On Fri, 27 Jan 2017, John Peterson wrote:

> On Fri, Jan 27, 2017 at 8:34 AM, Manav Bhatia  wrote:
>
>>What I have in mind is a two-phase fluid problem with some interface
>> boundary that is evolving with time. Then, if I choose to use XFEM or
>> Lagrange multipliers at the interface, then the nodes/elements where these
>> extra dofs will be defined will change with time.

So each dof would have support only on a single element or at most a
patch of element around a node?

>>How easy/difficult would it be to do this with libMesh?
>
> Addition/deletion of dofs happens all the time during adaptive
> refinement/coarsening, so in principle I think this should be possible.

Indeed.  If you don't want to modify the mesh by actually splitting
interface elements, you could try adding a per-subdomain variable and
then adding or removing elements from that subdomain as the interface
passes into or out of them.

> One thing that isn't really possible is adding/removing _variables_ to a
> system once it has been initialized,

This is true, and it's only halfway easy to change.  We could probably
support *adding* variables midsimulation without too many bugfixes,
but I suspect that *removing* variables midsimulation would trash
assumptions in a number of places.

> so e.g. representing the Lagrange multipliers as SCALAR variables
> and changing the number of said variables frequently would not work
> well.

In the case of SCALAR variables there's a workaround, I believe: you
can change the *order* of a SCALAR variable on the fly, and as the
order changes so does the number of scalar dofs it involves.  I don't
think we have this in test coverage so I wouldn't swear it's not
broken, but I bet it would be easy to fix.
---
Roy

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] dynamically add/remove dofs

[Manav Bhatia]

Thanks for the clarification, John. 

Do you know if there have been XFEM implementations using libMesh in your group 
or elsewhere in the research community? 

Regards,
Manav


> On Jan 27, 2017, at 9:54 AM, John Peterson  wrote:
> 
> 
> 
> On Fri, Jan 27, 2017 at 8:34 AM, Manav Bhatia  > wrote:
> Hi,
> 
>I am curious if libMesh allows frequent addition/deletion of dofs to a 
> system.
> 
>What I have in mind is a two-phase fluid problem with some interface 
> boundary that is evolving with time. Then, if I choose to use XFEM or 
> Lagrange multipliers at the interface, then the nodes/elements where these 
> extra dofs will be defined will change with time.
> 
>How easy/difficult would it be to do this with libMesh?
> 
> Addition/deletion of dofs happens all the time during adaptive 
> refinement/coarsening, so in principle I think this should be possible.
> 
> One thing that isn't really possible is adding/removing _variables_ to a 
> system once it has been initialized, so e.g. representing the Lagrange 
> multipliers as SCALAR variables and changing the number of said variables 
> frequently would not work well. 
> 
> -- 
> John

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

Re: [Libmesh-users] dynamically add/remove dofs

[John Peterson]

On Fri, Jan 27, 2017 at 8:34 AM, Manav Bhatia  wrote:

> Hi,
>
>I am curious if libMesh allows frequent addition/deletion of dofs to a
> system.
>
>What I have in mind is a two-phase fluid problem with some interface
> boundary that is evolving with time. Then, if I choose to use XFEM or
> Lagrange multipliers at the interface, then the nodes/elements where these
> extra dofs will be defined will change with time.
>
>How easy/difficult would it be to do this with libMesh?
>

Addition/deletion of dofs happens all the time during adaptive
refinement/coarsening, so in principle I think this should be possible.

One thing that isn't really possible is adding/removing _variables_ to a
system once it has been initialized, so e.g. representing the Lagrange
multipliers as SCALAR variables and changing the number of said variables
frequently would not work well.

-- 
John
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users

[Libmesh-users] dynamically add/remove dofs

[Manav Bhatia]

Hi, 

   I am curious if libMesh allows frequent addition/deletion of dofs to a 
system. 

   What I have in mind is a two-phase fluid problem with some interface 
boundary that is evolving with time. Then, if I choose to use XFEM or Lagrange 
multipliers at the interface, then the nodes/elements where these extra dofs 
will be defined will change with time.

   How easy/difficult would it be to do this with libMesh? 

   I would appreciate any comments. 

Regards,
Manav
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Libmesh-users mailing list
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users