fusion_indicator

[HPL001]

Dear moose developers,
Hello, I defined a new region with the following expression. According to my logic, the region I defined should be marked as 1, but I don't know why they are all marked as 0.5.

[AuxKernels]
  [fusion_indicator]
    type = ParsedAux
    variable = fusion_region
    coupled_variables = 'gr0 gr1 bnds'
    expression = 'if(abs(gr0 - 0.5) < 0.1, if(abs(gr1 - 0.5) < 0.1, 1, 0), 0)'
    execute_on = 'TIMESTEP_END'
  []
[]

this is picture of result.

[GiudGiud]

What variable type is fusion region? Some variables have visualization artefacts in paraview.
Is this paraview or peacock or ?
And did you set the color map scale to go from 0 to 1?

[HPL001]

Thank you for your reply. For the above problem, I actually wanted to capture some areas belonging to two particles in this way, and use them as the sintered neck (or GB) area. However, when I encountered this problem, I enlarged the scale to 0-1, which is still the case. I don't know if this is correct, or if I have a better way to deal with the sintered neck.

[GiudGiud]

What variable type is fusion region? Some variables have visualization artefacts in paraview.
Is this paraview or peacock or ?

What about this?

actually wanted to capture some areas belonging to two particles in this way, and use them as the sintered neck (or GB) area

Did you use an auxiliary variable to try to find these areas?
EDIT: Ok I see below

I don't know if this is correct, or if I have a better way to deal with the sintered neck.

This looks fine to me. It's just the variable value that's weird

[HPL001]

I refer to the determination of the free surface pointed out in the paper of 18 years, and adopt the following code to set up the free surface. Normally, the value of these selected areas should be marked as 1, but here it is 0.5, and I am not sure why. Will it make any difference to my results?

[AuxVariables]
  [free_surface_region]
    order = CONSTANT
    family = MONOMIAL
  []
[]
[AuxKernels]
  [free_surface_indicator]
    type = ParsedAux
    variable = free_surface_region
    coupled_variables = 'gr0 gr1 c'
    # expression = 'if(c > 0.25, if(c < 0.75, 1, 0), 0)'
    expression = 'if(c > 0.45, if(c < 0.55, 1, 0), 0)'
    execute_on = 'initial timestep_end'
  []
[]
[Postprocessors]
  [free_surface_area]
    type = ElementIntegralVariablePostprocessor
    variable = free_surface_region
    execute_on = 'initial timestep_end'
  []
[]

[HPL001]

Do you mean reduced drawing time or simulation time? I used time step adaptive processing. Also, like this, is there a way for me to force a value to the flagged position? (For example, the value assigned here is 1 instead of 0.5)

[GiudGiud]

Use a fixed dT or at least a functionDT

If you don't make the time steps smaller you cannot know whether your results are converged.

[HPL001]

Thank you for your reply. I have adopted a fixed time step of 0.01 for calculation. The following is the result diagram.

I have a doubt. You mentioned in your last reply that it is difficult to judge whether the time step is convergent because it is not fixed. I don't understand that the adaptive time step is automatically adjusted according to the convergence. Should I turn on adaptive step size in normal calculations?
And, I want to know is there a way for me to force a value to the flagged position? (For example, the value assigned here is 1 instead of 0.5)

[GiudGiud]

. I don't understand that the adaptive time step is automatically adjusted according to the convergence.

Not the same convergence. It's set based on the convergence of the nonlinear solver. That's very different from the time discretization scheme convergence.

Should I turn on adaptive step size in normal calculations?

only if you know that the time discretization error is not too large

And, I want to know is there a way for me to force a value to the flagged position? (For example, the value assigned here is 1 instead of 0.5)

of the fusion variable? That does not seem right to be forcing it

[HPL001]

Thank you for your reply. I think there should be a sudden divergence in my first calculation. Since I used the adaptive time step, maybe I crossed this divergence point in the calculation, which caused the data anomaly.

[HPL001]

Hello, I now define variables in the following way. I have a question about how to calculate in the postprocessor(ElementIntegralVariablePostprocessor) for areas where the variable value is not equal to 1. Since I need the area of my marker area, so I want to know this.

[AuxVariables]
  [fusion_region]
    order = FIRST
    family = LAGRANGE
  []
[]

[AuxKernels]
  [fusion_indicatorAuxKernel]
    type = ParsedAux
    variable = fusion_region
    coupled_variables = 'gr0 gr1 bnds c'
    expression = 'if(gr0 > 0.45, if(gr0 < 0.55, if(gr1 > 0.45, if(gr1 < 0.55, 1, 0), 0), 0), 0)'
    execute_on = 'initial timestep_end'
  []
[]

[Postprocessors]
  [fusion_area]
    type = ElementIntegralVariablePostprocessor
    variable = fusion_region
    execute_on = 'initial timestep_end'
  []
[]

Perhaps, for me, I want to mark an area in this way, and then calculate its area, which is better? Look forward to your reply and help, thank you.

[GiudGiud]

Ok you'll need to make an object then.

I would say to try a user object that evaluated the true path of that line (in 2D) / surface (in 3D) by first placing its points in the middle of the elements with a nonzero value (or at the maximum?)

[HPL001]

I found an object, GrainBoundaryArea. Does it help me with my needs? I tried to experiment with him, and my two particles had an initial diameter of 15, but he output 47.1, which is the circumference of a particle.

  [bnd_length] 
    type = GrainBoundaryArea
    grains_per_side = 2.0
    execute_on = 'initial timestep_end'
  []

[GiudGiud]

47 could be 15 * pi
And the factor of 2 is in the grains per side

I think this is the right object

[HPL001]

Thanks for your reply, so does grains_per_side = 2.0 mean total grain boundary length divided by 2? In addition, when two particles touch, can the contact area (circled in the graph) be included by GrainBoundaryArea?

[GiudGiud]

I just checked the definition and no it's not that.
You ll want to experiment with it to compute the contact area. You might need to modify it