Is it possible to solve different equations at different parts of a domain

[Yingjie Liu]

Dear All,

          I am solving a coupling problem. In this problem, some equations are defined on the entire 3D block,  while the others are only defined at the top surface of the block. Can anyone tell me how to solve different equations at different parts of the domain? I will appreciate it if someone can provide me a sample input file. Thanks.

Best wishes!
Yingjie

[Wang, Yaqi]

This is doable based on my experience. Typically you will need mesh modifiers to assign blocks and side sets properly. You have to have blocks and side sets local to each individual subdomain. While local blocks make sense, local for a side set means that any attaching elements of the sides of this side set needs to be within one subdomain. You may need two interior side sets containing the same sides but differ with each other by the subdomain these side sets are defined with. All variables, kernels, boundary conditions, etc. can be block or side set restricted. You could use InterfaceKernel to couple subdomains if you need to. The tests for InterfaceKernel could be useful to you.

-Yaqi

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/92975858-4881-46ed-8377-6bd8eeba34ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[john.m...@uconn.edu]

Quick question,

Do you need to use InterfaceKernel if the interface shares a variable on both subdomains? Or is that already coupled?

John

[Derek Gaston]

Just a general statement: most objects in MOOSE take a "block" option in the input file that allows you to restrict that object to a subdomain.

That includes: Variables, Kernels, Materials, InitialConditions and many more.

Using that parameter is how you tell MOOSE where in your domain certain variables and equations will live.

To create the blocks (subdomains) you use your mesh generator... or you can use some of the MeshModifiers to add blocks to your existing mesh.

Derek

--

You received this message because you are subscribed to the Google Groups "moose-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/85f1b3a6-6fdf-4f12-9f54-8c8200951c84%40googlegroups.com.

[Yingjie Liu]

Hi, John,

Thanks for your reply. Yes, you are correct. Although the equations are defined at different parts of the domain, all the variables are coupled together. Thanks.

Best wishes!

Yingjie

%%%%%%%%%%%%%%%%%%%%

Yingjie Liu

yingjie...@gmail.com

--
You received this message because you are subscribed to a topic in the Google Groups "moose-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/moose-users/6dqVHo5X3tI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to moose-users...@googlegroups.com.

[john.m...@uconn.edu]

No, what I mean, I need to know if this is needed in general. This is more of a sanity check question:

For example, let's look at this test file for InterfaceKernel (single_variable_coupled_flux.i). We have two diffusion equations, one on subdomain 0 and another on subdomain 1, with different diffusion coefficients D = 2 and D = 4. There is an interface between the two subdomains with an interface kernel that uses D = 4.  I'm assuming that means, that boundary obeys a D = 4 version of the diffusion kernel. What happens if you don't use the InterfaceKernel in this example?

Now, in tensor_mechanics, what happens if you, say, have different elastic constants in different subdomains? Do you need to have a InterfaceKernel to define C_{ijkl} on the boundary? Should there be a InterfaceTensorMechanicsAction?

John

On Monday, August 22, 2016 at 11:29:20 AM UTC-5, Yingjie Liu wrote:

[Alexander Lindsay]

Hi John, assuming you want a continuous variable (Lagrange), it would be fine just to define the variable over the whole domain, and then define two kernels, one on each subdomain, each with different diffusion coefficients. Then you could reproduce the output from the InterfaceKernel example. However, where I have found InterfaceKernel useful in my own work is when I'm coupling two different variables on different sides of the interface where those variables have different values at the interface.

--

You received this message because you are subscribed to the Google Groups "moose-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/cf3ba751-ac9b-49c0-9204-7b639590aca9%40googlegroups.com.

[Alexander Lindsay]

Or if you're getting your kernel diffusion coefficient from two different materials, you wouldn't even need two different kernels.

On 08/22/2016 12:15 PM, john.m...@uconn.edu wrote:

--

[Yingjie Liu]

Hi, Yaqi,

       Thank you for your reply. I am a little confused about your statement that I may need two interior side sets. If my understanding is correct, I think you mean that one of the two side set is attached to the block while the other is an independent subdomain on which I solve the equations. Then I use the InterfaceKerneal to add the constraint between the two set. Is it correct?

Best wishes!
Yingjie

On Monday, August 22, 2016 at 12:52:05 PM UTC-4, yaqi.wang wrote:

This is doable based on my experience. Typically you will need mesh modifiers to assign blocks and side sets properly. You have to have blocks and side sets local to each individual subdomain. While local blocks make sense, local for a side set means that any attaching elements of the sides of this side set needs to be within one subdomain. You may need two interior side sets containing the same sides but differ with each other by the subdomain these side sets are defined with. All variables, kernels, boundary conditions, etc. can be block or side set restricted. You could use InterfaceKernel to couple subdomains if you need to. The tests for InterfaceKernel could be useful to you.

-Yaqi

On Mon, Aug 22, 2016 at 10:29 AM, Yingjie Liu <yingjie...@gmail.com> wrote:

Dear All,

          I am solving a coupling problem. In this problem, some equations are defined on the entire 3D block,  while the others are only defined at the top surface of the block. Can anyone tell me how to solve different equations at different parts of the domain? I will appreciate it if someone can provide me a sample input file. Thanks.

Best wishes!
Yingjie

--
You received this message because you are subscribed to the Google Groups "moose-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.

[Wang, Yaqi]

Sorry for the confusion. No. To use InterfaceKernel, you only need one interior side set. You will need to be careful on which subdomain is the master for this side set, i.e. the side set is defined with respect to (a collect of sides with their attaching elements and local side numbers). The variable and neighbor variable need to be switched in the InterfaceKernel if you choose one subdomain as the master or the other. If on the other hand you just want to solve an equation only on part of domain, you will have to make sure the subdomain is master for the interior side set, otherwise the boundary condition (IntergratedBC) on it will not be handled correctly by MOOSE. It is noted that the input mesh must be conforming with InterfaceKernel, i.e. there are no hanging nodes on the interface of two adjacent subdomains.

-Yaqi

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/c549bd78-22be-40da-8e8c-263e00f97c47%40googlegroups.com.

[Yingjie Liu]

Hi, Yaqi,

          Thank you very much. I have one further question. For my equationn defined on the bulk domain, the element is 3D element, e.g., Brick8. However, for the equations defined  on the surface, the element will become 2D, e.g., QUAD4. Are there any issues MOOSE could face in dealing with this kind of problem? Thanks.

Best wishes!
Yingjie

[Cody Permann]

We don't have the ability to limit a variable to only a surface but that doesn't really matter. You could calculate the variable only on the surface and just leave the rest of the field as zero if you'd like. You could potentially restrict a variable to the domain made up of just the outer layer of elements (of the mesh dimension) to minimize the unused DOFs in the domain. We do have plans to add surface variables at some point in the future. There are a lot of applications that need that capability.

Cody

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/c803f73f-095c-4db2-939f-0b0495763ae3%40googlegroups.com.

[Derek Gaston]

Just "solving on the surface" doesn't quite work Cody.  The reason why is that there is currently no way to run a _Kernel_ on a surface.  You would have to use a BoundaryCondition... but then all of your gradients, etc. would be messed up (they would be the 3D gradient from the interior... which is wrong).

The closest you can get right now is to create a block of lower dimensional elements (i.e. QUAD4 in this case) that sits right on the surface of your 3D mesh and shares the nodes.  You can then add a variable that only exists on that block and assign Kernels to that block that will do the right thing.

The problem is: we don't have a way to do this automatically currently.  Usually you would use Cubit to actually do this.  It's definitely possible to be able to do it automatically using a MeshModifier... but no one has tried yet...

Derek

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAK06EuXxQcST8we2feOXuR7Ywt%3D3_2SXfz7HDrfq4DTVPnehHw%40mail.gmail.com.

[Cody Permann]

This capability will come...  

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAFfxPjoavc%3D%3DA6skkAHhTX25EDDzfRpkCiAVCuzd6Rs56aMd%3Dw%40mail.gmail.com.

[Yingjie Liu]

Hi, Derek,

 Thanks for your reply. It is very helpful. Now let me rephrase your words to make sure my understanding is correct.

 (1) First of all, I use a preprocessor software to draw a mesh. In the mesh, there will be two blocks. One is the 3D block, the other is 2D block. One surface of the 3D block will share the same node number with the 2D block.

(2) Define block variables for the 3D block and define the "face variable" for the 2D block. I can also define the kernels for each block.

(3) Use the InterfaceKernel to couple the shared variable between the 2 blocks.

Best wishes!
Yingjie

在 2016年8月23日星期二 UTC-4下午12:57:52，Derek Gaston写道：

[Derek Gaston]

The only part I don't know about is (3): I haven't used an InterfaceKernel for that myself... yet.

Other than that - it sounds right.

Derek

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/a7ef7cc1-6008-468d-898a-50afb228c72b%40googlegroups.com.