Crash on coupled_value_coupled_flux.i

[Wesley]

When I try to execute on coupled_value_coupled_flux.i, it doesn't work, and give me the following and end up with "Crashed: Exit code: 11".

It works when I comment the Materials block in the input file (inactive = 'Materials'), is there some problems with this?

Running command: /home/moose/projects/moose/test/moose_test-opt Outputs/csv=true -i peacock_run_exe_tmp_coupled_value_coupled_flux_comment_Material.i

Working directory: /home/moose/projects/moose/test/tests/interfacekernels/1d_interface

Framework Information:

MOOSE Version:           git commit 2d594b4 on 2018-03-13

LibMesh Version:         727d0685dc96e841c5805608653410ea0cd926a6

PETSc Version:           3.7.6

Current Time:            Wed Jun 13 21:40:04 2018

Executable Timestamp:    Tue Mar 20 11:19:36 2018

Parallelism:

  Num Processors:          1

  Num Threads:             1

Mesh:

  Parallel Type:           replicated

  Mesh Dimension:          1

  Spatial Dimension:       1

  Nodes:

    Total:                 11

    Local:                 11

  Elems:

    Total:                 10

    Local:                 10

  Num Subdomains:          2

  Num Partitions:          1

Nonlinear System:

  Num DOFs:                12

  Num Local DOFs:          12

  Variables:               "u" "v"

  Finite Element Types:    "LAGRANGE" "LAGRANGE"

  Approximation Orders:    "FIRST" "FIRST"

Execution Information:

  Executioner:             Steady

  Solver Mode:             NEWTON

Crashed

Crashed: Exit code: 11

[Cody Permann]

Interesting. We never intended for the “active/inactive” parameters to be used at the top level but I suppose there’s no reason that won’t work. This should be triggering an integrity check error since the material is inactive and might be used somewhere but since the InterfaceKernels system is newer than most, it may not have as an extensive set of checks. Thanks for the report.

--
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/cffc23aa-34c3-42e3-993c-aa897212b05f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Wesley]

Thanks Cody.

I updated the libmesh and it work now.

But another question is (still in this example  coupled_value_coupled_flux.i), in [InterfaceKernels] block it tells u as variable and v as neighbor_variable, also in [Kernels] block it set up the D=4 for u and D=2 for v, why does it still need to set up the D in Materials property as below?

[Materials]

...

  [./boundary]

    type = GenericConstantMaterial

    boundary = 'master0_interface'

    prop_names = 'D D_neighbor'

    prop_values = '4 2'

  [../]

[]

[Wesley]

D in [Kernel] block is the diffusity for domain, and D at interface on the same side, they are the same or different in this example?

If they are different, then this set up make sense.

If they are the same,  I guess I need to pay attention to this.

[Wang, Yaqi]

Interface kernel is the only consumer of the two material properties. The setup is actually quite confusing. Both D and D_neighbor are defined on MASTER side of the interface. D_neighbor does not really mean neighbor diffusion coefficient. This can be seen in the source InterfaceDiffusion or this command-line argument 'Debug/show_material_props=true'. We actually can define D on both master0_interface and master1_interface. and let InterfaceDiffusion get the same property D on both sides. D in the diffusion kernels are just constant values irrelevant to the materials. It is also odd to me having MatchedValueBC on the interface since supposedly interface kernel can provide the conditions for both side. I also do not understand why not let InterfaceDiffusion to mimic DGDiffusion. It misses an important penalty term currently. My opinion is that this input is a good test for testing the capability but not good for users as an example. It can be improved for both purpose.

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/972c4668-6da5-45f3-95dd-4b003add9215%40googlegroups.com.

[Alexander Lindsay]

What do you mean it's missing an important penalty term? If you were specifying a flux for an IntegratedBC would you introduce a penalty coefficient? I could envision a penalty perhaps if you were using discontinuous shape functions, but not otherwise.

The only thing that particular interface kernel is specifying is -D1 dc1/dx = -D2 dc2/dx. That is a single condition. You need an additional condition (given by the matched value BC) in this case to specify a complete equation set (like in neutronics at an interface you might specify phi1 = phi2 and -D1 dphi1/dx = -D2 dphi2/dx + surface src).

There are certainly cases where you could specify two unique conditions in a single interface kernel. An example from heat conduction would be:

q1 = h * (T2 - T1)

q2 = h * (T2 - T1)

where you're effectively specifying the gradient of the temperature on both sides to be proportional to the temperature difference at the interface.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CABk6%3D%2BYr9dQ1TbJT9aZE_x%3Djxn2zK%3DKnA%3D%3Drv0OOZrpdjwi%2B%3Dg%40mail.gmail.com.

[Wesley]

Thanks Yaqi.

I am a little bit confuse now, what D_neighbour is if it's not neighbor diffusion coefficient? I thought it was like the diffusity in neighbor domain.

So in this case, I can just use Diffusion kernel rather than CoeffParamDiffusion for the variable in [Kernels]?

Alex's explanation about the equation set make sense to me, thanks!

[Wesley]

For the second question, I guess not....I reproduce this using Diffusion kernel, gives me the wrong result.

[Wang, Yaqi]

The term I am referring is (k[phi], [phi_test]), which is exactly what you are saying at the end, with h = k. But typically we have current defined as the subtraction of partial currents (combination of phi and grad phi dot n) evaluated on both sides, which results into incomplete penalty method (check DGDiffusion). I am not sure if the first way you mentioned or in the input and the code is ok though.

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

[Alexander Lindsay]

On Thu, Jun 14, 2018 at 9:22 AM, Wang, Yaqi <yaqi...@inl.gov> wrote:

Interface kernel is the only consumer of the two material properties. The setup is actually quite confusing. Both D and D_neighbor are defined on MASTER side of the interface. D_neighbor does not really mean neighbor diffusion coefficient.

D_neighbor does refer conceptually to the neighboring diffusion coefficient. The material property is being supplied from a material of BOUNDARY_MATERIAL_DATA type. The boundary name is coming from a sideset construction mesh modifier, sure, but it's not a FACE material.

This can be seen in the source InterfaceDiffusion or this command-line argument 'Debug/show_material_props=true'. We actually can define D on both master0_interface and master1_interface. and let InterfaceDiffusion get the same property D on both sides.

Have you tried this? This would indeed be the ideal set-up. However, I tried with two separate boundary restricted materials, one on master0 and one on master1, and called getMaterialProperty and getNeighborMaterialProperty respectively. The retrieved neighbor property appears to just be zeros. This is likely because getNeighborMaterialProperty is looking into _neighbor_material_data but construction of a material on master1_interface only creates a boundary material type and not a neighbor material type. Might have to dig deeper into this if we want this to work.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CABk6%3D%2BYr9dQ1TbJT9aZE_x%3Djxn2zK%3DKnA%3D%3Drv0OOZrpdjwi%2B%3Dg%40mail.gmail.com.

[Wang, Yaqi]

Typically the material property is evaluated by materials defined on blocks. In that case, property needs to be obtained by getMaterialProperty and getNeighborMaterialProperty, which is not the case in InterfaceDiffusion.C. We we call getNeighborMaterialProperty, then D_neighbor needs to be added on master1_interface or a material defined on block 1.

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/bdcc6e70-7551-4bfb-916e-989a58f53977%40googlegroups.com.

[Wang, Yaqi]

Not tried before. Then the neighboring properties have to be supplied by face materials. The problem for InterfaceDiffusion is that we have to use two different properties, while the same property can not be used if it is both defined on two neighboring blocks.

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

[Alexander Lindsay]

It's definitely ok :-) I've used a flux continuity interface kernel paired with a matched value bc for all my plasma physics simulations. The matched value bc strongly sets one variable, let's call it 'u', equal to the value of the other, let's call it 'v', and then the flux of v is weakly set equal to the flux of u at the interface (without any penalty, linear lagrange for both variables). The latter can be thought of as an integrated bc for v; it just uses data coming from a neighboring subdomain.

I'm sure you're doing what makes sense for your physics Yaqi.

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

[Wang, Yaqi]

I can be convinced only this will produce consistent solutions meaning that refining the mesh will make the solution limit to the analytical solution. If there is a math proof, it will be even better.

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

[Wesley]

Hi Alex,

I have done a simple calculation based on InterfaceDiffusion kernel, it seems at the interface (x=1) it is not that smooth (if fluxes from both side have set to be equal, it should be smooth). Is that what you mean by saying "the flux of v is weakly set equal to the flux of u at the interface" ?

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/972c4668-6da5-45f3-95dd-4b003add9215%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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/CABk6%3D%2BYr9dQ1TbJT9aZE_x%3Djxn2zK%3DKnA%3D%3Drv0OOZrpdjwi%2B%3Dg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
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/CANFcJrGueoZBQA1mevycmWgc6HXxcy8sNZ7A-mtT043Gvf47yA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
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.

[Alexander Lindsay]

Are the diffusion coefficients the same on both sides? If they're not, then it certainly should not be smooth

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/64ca3411-6acc-4337-ab70-2388594624b3%40googlegroups.com.

[Wesley]

Yes I made a mistake, you are right, thanks!

[Alexander Lindsay]

I am ready to admit defeat on the validity of the penalty method versus using a matched value bc :-) For the attached input file, one can determine the analytic solution. The convergence rates for the two methods are shown below:

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/0d331344-9852-40ba-8276-56b905675033%40googlegroups.com.

[Wang, Yaqi]

Nice plot! I am always amazed there are so much behind a numerical scheme even in such a simple setup. It can be seen that not only the rate is higher but also the coefficient is smaller with penalty method. 

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

[Alexander Lindsay]

So some 2D results using MMS:

For a slowly varying function:

convergence plots (note that fit is done for finest two meshes):

For a rapidly varying function:

convergence plots (note that fit is done for finest two meshes):

This preliminary experimentation suggests to me that for a function with small second derivatives, the convergence rate with the matched bcs may be ideal (e.g. second order), but that as the function curvature increases, the convergence rate degrades to first order. [This with first order LAGRANGE basis functions]

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CABk6%3D%2Ba87jMF4nF2hrFsTDDCHDenRdcVBEW-YikeYPBQoyVsLA%40mail.gmail.com.

[Wang, Yaqi]

Alex,

Nice and quick investigations! Looks like match-value method is converging.

I think the takeaway is: MOOSE can do calculations with interface conditions connecting multiple schemes and the interface conditions need to be designed carefully for better accuracy. We did some work for radiation transport in the past, which can be found at https://www.sciencedirect.com/science/article/pii/S0149197017300653 if interested.

Best,

Yaqi

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

[Alexander Lindsay]

This is a great reference Yaqi. Thanks for sharing

[Wesley]

Hi Alex,I still have a question here.

On Thursday, June 14, 2018 at 7:13:34 PM UTC-4, Alexander Lindsay wrote:

On Thu, Jun 14, 2018 at 9:22 AM, Wang, Yaqi <yaqi...@inl.gov> wrote:

Interface kernel is the only consumer of the two material properties. The setup is actually quite confusing. Both D and D_neighbor are defined on MASTER side of the interface. D_neighbor does not really mean neighbor diffusion coefficient.

D_neighbor does refer conceptually to the neighboring diffusion coefficient. The material property is being supplied from a material of BOUNDARY_MATERIAL_DATA type. The boundary name is coming from a sideset construction mesh modifier, sure, but it's not a FACE material.

D_neighbor refers to the neighboring diffusion coefficient and it's been defined in [Materials] block, but we still need to define the diffusion coefficient (D) when using type =  CoeffParamDiffusion in [Kernels] for the variables, to make it consistent with the Material property, right?

[Kernels]

  [./diff_u]

    type = CoeffParamDiffusion

    variable = u

    D = 4

    block = 0

  [../]

  [./diff_v]

    type = CoeffParamDiffusion

    variable = v

    D = 2

    block = 1

  [../]

[]

Because the diffusion coefficients from the two domains are different, we can not just simply use Diffusion kernel. 

The Diffusion kernel only computes $-\\nabla \\cdot \\nabla u$ Which means D=1.

Right?

Thanks!

[Wesley]

Also, are there any particular reasons to set up the interface_again in [MeshModifiers] ? It seems that without this it works too.

[MeshModifiers]

....

  [./interface_again]

    type = SideSetsBetweenSubdomains

    depends_on = subdomain1

    master_block = '1'

    paired_block = '0'

    new_boundary = 'master1_interface'

  [../]

[]

[Alexander Lindsay]

On Mon, Jun 18, 2018 at 8:38 AM, Wesley <zuzup...@gmail.com> wrote:

Hi Alex,I still have a question here.

On Thursday, June 14, 2018 at 7:13:34 PM UTC-4, Alexander Lindsay wrote:

On Thu, Jun 14, 2018 at 9:22 AM, Wang, Yaqi <yaqi...@inl.gov> wrote:

Interface kernel is the only consumer of the two material properties. The setup is actually quite confusing. Both D and D_neighbor are defined on MASTER side of the interface. D_neighbor does not really mean neighbor diffusion coefficient.

D_neighbor does refer conceptually to the neighboring diffusion coefficient. The material property is being supplied from a material of BOUNDARY_MATERIAL_DATA type. The boundary name is coming from a sideset construction mesh modifier, sure, but it's not a FACE material.

D_neighbor refers to the neighboring diffusion coefficient and it's been defined in [Materials] block, but we still need to define the diffusion coefficient (D) when using type =  CoeffParamDiffusion in [Kernels] for the variables, to make it consistent with the Material property, right?

[Kernels]

  [./diff_u]

    type = CoeffParamDiffusion

    variable = u

    D = 4

    block = 0

  [../]

  [./diff_v]

    type = CoeffParamDiffusion

    variable = v

    D = 2

    block = 1

  [../]

[]

Right, that kernel doesn't take material properties, only user supplied reals.

 

Because the diffusion coefficients from the two domains are different, we can not just simply use Diffusion kernel. 

The Diffusion kernel only computes $-\\nabla \\cdot \\nabla u$ Which means D=1.

Correct

 

Right?

Thanks!

--
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/39524ae2-b76f-4366-b840-f189549d818c%40googlegroups.com.

[Alexander Lindsay]

Right in that problem, we don't actually make any use of the sideset defined on subdomain1 

--
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/7edaeb02-df59-4cdd-a2a4-6338c111bf93%40googlegroups.com.

[Wesley]

I see, thanks for your quick reply.

On Monday, June 18, 2018 at 11:04:10 AM UTC-4, Alexander Lindsay wrote:

On Mon, Jun 18, 2018 at 8:52 AM, Wesley <zuzup...@gmail.com> wrote:

Also, are there any particular reasons to set up the interface_again in [MeshModifiers] ? It seems that without this it works too.

[MeshModifiers]

....

  [./interface_again]

    type = SideSetsBetweenSubdomains

    depends_on = subdomain1

    master_block = '1'

    paired_block = '0'

    new_boundary = 'master1_interface'

  [../]

[]

Right in that problem, we don't actually make any use of the sideset defined on subdomain1 

--
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.

[Wesley]

Hi Alex,

Can we use MatDiffusion kernel as below to substitute the CoeffParamDiffusion? So that we don't need to set 'D' twice (in Kernel block and Material block).

I just tried it and it gives the same result. Is there any other concerns I might miss here?

[Kernels]

  [diff_u]

    type = MatDiffusion

    prop_name = D

    variable = u

    block = '0'

  []

  [diff_v]

    type = MatDiffusion

    prop_name = D

    variable = v

    block = '1'

  []

[]

On Thursday, June 14, 2018 at 7:13:34 PM UTC-4, Alexander Lindsay wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/972c4668-6da5-45f3-95dd-4b003add9215%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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.

[Alexander Lindsay]

That's fine

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/a5b91f44-e2e0-4ead-b55e-825b1ac2ed78%40googlegroups.com.