Prescribe IC with Phase Field Fracture

[selarem]

Hi all,
I am trying to prescribe some Initial Conditions on the variable c within the phase field fracture framework.

I have tried the random, the functionIC and the boundingbox and could not have the IC imposed.

At t=0, I can see that my IC was correctly imposed, but at the first increment moose puts c to zero.

It used to work with the old version of moose; before febrary 2018.

Has anyone faced this problem ?

Regards,

Saber

[Cody Permann]

Well this sounds serious, but I think most of MOOSE would be broken if we were just dropping initial conditions. This must be limited to some other lesser used feature, but we can help figure it out. Can you put together an input file that shows the problem? We could take a look.

On Thu, Apr 19, 2018 at 7:42 AM selarem <saber...@gmail.com> wrote:

Hi all,
I am trying to prescribe some Initial Conditions on the variable c within the phase field fracture framework.

I have tried the random, the functionIC and the boundingbox and could not have the IC imposed.

At t=0, I can see that my IC was correctly imposed, but at the first increment moose puts c to zero.

It used to work with the old version of moose; before febrary 2018.

This is actually really helpful too. We can do a "git bisect" where we setup a script that uses a test like the one you have as a "passing" criterion and just keep building the framework at various versions before Februrary through today to find the offending commit that changed this behavior. It should be easy to track down.

 

Has anyone faced this problem ?

Regards,

Saber

--
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/464041f7-5f9f-49f3-9289-4181659ec92e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aagesen, Larry K]

This change in behavior may be related to recent changes in the the PF Fracture model. There should be a restriction in the model preventing crack healing, so that c shouldn't be able to decrease. Maybe Wen Jiang could weigh in on this?

On Thu, Apr 19, 2018 at 7:52 AM, Cody Permann <codyp...@gmail.com> wrote:

Well this sounds serious, but I think most of MOOSE would be broken if we were just dropping initial conditions. This must be limited to some other lesser used feature, but we can help figure it out. Can you put together an input file that shows the problem? We could take a look.

On Thu, Apr 19, 2018 at 7:42 AM selarem <saber...@gmail.com> wrote:

Hi all,
I am trying to prescribe some Initial Conditions on the variable c within the phase field fracture framework.

I have tried the random, the functionIC and the boundingbox and could not have the IC imposed.

At t=0, I can see that my IC was correctly imposed, but at the first increment moose puts c to zero.

It used to work with the old version of moose; before febrary 2018.

This is actually really helpful too. We can do a "git bisect" where we setup a script that uses a test like the one you have as a "passing" criterion and just keep building the framework at various versions before Februrary through today to find the offending commit that changed this behavior. It should be easy to track down.

Has anyone faced this problem ?

Regards,

Saber

--
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/464041f7-5f9f-49f3-9289-4181659ec92e%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+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/CAK06EuUreZ_y9zLEurGhBo4znuUN7-fbYAnnTONJMrrrMd-rtg%40mail.gmail.com.

[S. EL AREM]

An input file based on the examples in :
~/projects/moose/modules/combined/test/tests/phase_field_fracture

2018-04-19 15:52 GMT+02:00 Cody Permann <codyp...@gmail.com>:

Well this sounds serious, but I think most of MOOSE would be broken if we were just dropping initial conditions. This must be limited to some other lesser used feature, but we can help figure it out. Can you put together an input file that shows the problem? We could take a look.

On Thu, Apr 19, 2018 at 7:42 AM selarem <saber...@gmail.com> wrote:

Hi all,
I am trying to prescribe some Initial Conditions on the variable c within the phase field fracture framework.

I have tried the random, the functionIC and the boundingbox and could not have the IC imposed.

At t=0, I can see that my IC was correctly imposed, but at the first increment moose puts c to zero.

It used to work with the old version of moose; before febrary 2018.

This is actually really helpful too. We can do a "git bisect" where we setup a script that uses a test like the one you have as a "passing" criterion and just keep building the framework at various versions before Februrary through today to find the offending commit that changed this behavior. It should be easy to track down.

 

Has anyone faced this problem ?

Regards,

Saber

--
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/464041f7-5f9f-49f3-9289-4181659ec92e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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/Bf_nkvs-j3k/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAK06EuUreZ_y9zLEurGhBo4znuUN7-fbYAnnTONJMrrrMd-rtg%40mail.gmail.com.

[Wen Jiang]

Your random initial condition is applied correctly. The reason you thought initial condition disappeared is that after the first solve, the randomized phase field damage parameter c quickly diffuses out with such a high mobility number (L = 1.0e7). 

On Thursday, April 19, 2018 at 8:55:19 AM UTC-6, selarem wrote:

An input file based on the examples in :
~/projects/moose/modules/combined/test/tests/phase_field_fracture

2018-04-19 15:52 GMT+02:00 Cody Permann <codyp...@gmail.com>:

Well this sounds serious, but I think most of MOOSE would be broken if we were just dropping initial conditions. This must be limited to some other lesser used feature, but we can help figure it out. Can you put together an input file that shows the problem? We could take a look.

On Thu, Apr 19, 2018 at 7:42 AM selarem <saber...@gmail.com> wrote:

Hi all,
I am trying to prescribe some Initial Conditions on the variable c within the phase field fracture framework.

I have tried the random, the functionIC and the boundingbox and could not have the IC imposed.

At t=0, I can see that my IC was correctly imposed, but at the first increment moose puts c to zero.

It used to work with the old version of moose; before febrary 2018.

This is actually really helpful too. We can do a "git bisect" where we setup a script that uses a test like the one you have as a "passing" criterion and just keep building the framework at various versions before Februrary through today to find the offending commit that changed this behavior. It should be easy to track down.

 

Has anyone faced this problem ?

Regards,

Saber

--
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/464041f7-5f9f-49f3-9289-4181659ec92e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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/Bf_nkvs-j3k/unsubscribe.

To unsubscribe from this group and all its topics, send an email to moose-users...@googlegroups.com.

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

[Aagesen, Larry K]

Wen, shouldn't there be a restriction that dc/dt > 0 ? Or is this not enforced since we are using the history variable approach?

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/fd88ef9a-fb08-4839-af91-9edcc92da385%40googlegroups.com.

[Wen Jiang]

In the new phase field fracture model, the mobility for the AC kernel should be defined as L = 1.0/visco. In the regression tests, we mistakenly used L = 1.0/ visco / gc. I will correct those tests. Thanks for pointing out this issue.  

[Wen Jiang]

Larry, 

In this new formulation, we do not explicitly enforce dc/dt > 0 and we enforce it by using the history variable. So if we would like to prescribe a pre-exsiting damage zone, we need to initialize the history variable instead of giving ic to c. The method to initialize history variable can be found in Appendix A of this paper (https://www.sciencedirect.com/science/article/pii/S0045782512000199)

[Aagesen, Larry K]

Makes sense-thanks.

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/fd17367f-49f7-4898-9760-0776a3898c21%40googlegroups.com.

[S. EL AREM]

Does it mean that applying IC like I did will not work ? Because the crack is healing and I have seen it for many tesrs.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/fd17367f-49f7-4898-9760-0776a3898c21%40googlegroups.com.

[Wen Jiang]

Yes, Like I said, you should initialize history variable instead of damage variable c. 

[walkand...@gmail.com]

You should try to give the initial value to _hist, instead of c.

void

53 ComputeIsotropicLinearElasticPFFractureStress::initQpStatefulProperties()

54 {

55  _hist[_qp] = 0.0;

56 }

So here if some point is in 'cracked' phase, you should set _hist to the distance related function, the Eq.(104) described in Borden's paper

as Wen Jiang mentioned.

Best regards

在 2018年4月19日星期四 UTC+2下午3:42:06，selarem写道：

[Camilo Duarte]

Dear Dr. Wen Jiang,

I am trying to define a pre-crack as an initial condition. I tried initializing the aux variable _hist as you suggested, in this way:

  [./histIC]

    type = FunctionIC

    variable = hist

    function ='min(1.0*exp(-abs(y-0.5)/l)*if((x-0.5)/0.4,0,1.0),1.0)'

  [../]

However after the first time step  _hist goes to zero. What I should do to keep the hist variable different from zero? I checked Borden's paper and I think the phase evolution equation they used is different from the model in moose. It looks like a rate independent formulation.

[Wen Jiang]

I am trying to define a pre-crack as an initial condition. I tried initializing the aux variable _hist as you suggested, in this way:

  [./histIC]

    type = FunctionIC

    variable = hist

    function ='min(1.0*exp(-abs(y-0.5)/l)*if((x-0.5)/0.4,0,1.0),1.0)'

  [../]

The current code cannot set _hist material property from a aux variable, like what you did. At this moment, you can either use Cubit to mesh a crack or hard code ComputeIsotropicLinearElasticPFFractureStress::initQpStatefulProperties() function. And I will find a better way to allow users to define an initial crack.   

 

However after the first time step  _hist goes to zero. What I should do to keep the hist variable different from zero? I checked Borden's paper and I think the phase evolution equation they used is different from the model in moose. It looks like a rate independent formulation.

The only difference is the time derivative term. If you want to use Borden's model, you can just add ACBulk and ACinterface kernels instead of using Non-conserved action that adds additional time derivative kernel.