PyMKS fails to predict strain for a seperated binary material

[wd15]

For a separated binary microstructure with the following configuration

PyMKS doesn't appear to work correctly. It predicts a strain with stripes when rescaled. If there is no rescaling PyMKS works.

The code to reproduce this is https://gist.github.com/wd15/4b5e7f836bd4ec9383e2

This was run against c44468d7ddad

[wd15]

PyMKS works perfectly without scaling. It is also clear that the coefficients do not go to zero in the far field and so the zero padding breaks things (I will add some images to show this). Also the nominal zero channel is not zero. One thought

• can we formulate the convolution such that the constant channel is zero? and does that guarentee that the other non-constant channels are zero in the far field? the idea of using something other than zero to pad seems gross

[suryakalidindi]

Are the simulations (for both calibration and validation run with periodic boundary conditions? I would like to see the periodic boundary conditions. Is there a document describing the periodic boundary conditions used in the simulations.

[wd15]

I believe/hope that the periodic boundary conditions are exactly as laid out in this PDF.

https://idea.library.drexel.edu/bitstream/handle/1860/3491/Landi_Giacomo.pdf?sequence=1

Unfortunately the link no longer works. I have also failed to update the boundary conditions in the PyMKS docs.

Basically, the top and bottom surfaces are periodic with respect to the x and y displacements. The left and right surfaces are offset periodic in the x-direction and have regular periodicity in the y-direction. Furthermore the top and bottom points are fixed on the left side.

Of course this could be broken, but I've done quite a lot of testing especially in 2D.

[wd15]

Can this still be an issue with the boundary conditions if the unscaled version works perfectly well? Here is the image without scaling.

[suryakalidindi]

I am little surprised by these plots as I am expecting some disturbance near the boundary. May be the contrast is small and the disturbance is too small.

If this is the case, then we should focus on the scaling.

What is the size of the RVE before scaling and after scaling? Also we should look for the values of the influence kernel before and after scaling. Is there a way to reviews the functions easily?

Surya

From: Daniel Wheeler [mailto:notifications@github.com] Sent: Thursday, September 11, 2014 11:45 AM To: openmaterials/pymks Cc: Surya Kalidindi Subject: Re: [pymks] PyMKS fails to predict strain for a seperated binary material (#108)

Can this still be an issue with the boundary conditions if the unscaled version works perfectly well? Here is the image without scaling. https://cloud.githubusercontent.com/assets/1986844/4236900/921da37c-39ca-11e4-9030-ea778239292b.pngindex—Reply to this email directly or view it on GitHubhttps://github.com/openmaterials/pymks/issues/108#issuecomment-55283632 .https://github.com/notifications/beacon/6601815__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcyNjA2OTQ5MywiZGF0YSI6eyJpZCI6NDIxMjc4MjF9fQ==--48946e81bc5b9c3b3abfeebcae2b8c9c72f7cf88.gif

[wd15]

On Thu, Sep 11, 2014 at 12:02 PM, Surya Kalidindi notifications@github.com wrote:

I am little surprised by these plots as I am expecting some disturbance near the boundary. May be the contrast is small and the disturbance is too small.

If this is the case, then we should focus on the scaling.

That was my thought as the MKS is doing such a good job without scaling.

See https://gist.github.com/wd15/4b5e7f836bd4ec9383e2 for more details on sizes and properties.

The contrast is small elastic modulus is 80 and 100. The calibration delta microstructures are 21x21 and the scaled up size is 41x41 (I've tried 63x63).

What is the size of the RVE before scaling and after scaling? Also we should look for the values of the influence kernel before and after scaling. Is there a way to reviews the functions easily?

I'll post the images and values for the coefficients in the next comment, give me 20 minutes.

Daniel Wheeler

[wd15]

Influence Coefficients

The channel 0 coefficients are

  [  4.02920352e-05   4.03824445e-05   4.06129850e-05   4.11034965e-05
    4.21052730e-05   4.41816572e-05   4.88464092e-05   6.17310951e-05
    1.18197232e-04   6.67998275e-04   2.90787933e-03   6.67998275e-04
    1.18197232e-04   6.17310951e-05   4.88464092e-05   4.41816572e-05
    4.21052730e-05   4.11034965e-05   4.06129850e-05   4.03824445e-05
   4.02920352e-05]

going from left to right in the center plane and the channel 1 coeffs

[  4.53514739e-05   4.53514739e-05   4.53514739e-05   4.53514739e-05
   4.53514739e-05   4.53514739e-05   4.53514739e-05   4.53514739e-05
   4.53514739e-05   4.53514739e-05   4.53514739e-05   4.53514739e-05
   4.53514739e-05   4.53514739e-05   4.53514739e-05   4.53514739e-05
   4.53514739e-05   4.53514739e-05   4.53514739e-05   4.53514739e-05
   4.53514739e-05]

I guess looking at these values, it is fairly obvious that the coefficients can't be zero padded.

BTW, after scaling the influence coefficients look exactly the same, but just with zero padding around the edges.

[suryakalidindi]

In our original paper on MKS (with Landi) , we preferred to set the k=0 values to predefined values for this exact reason. We only did the calibration for the rest of the terms. Please see Eqs. (8) and (9) in the enclosed paper. Hope this helps sort this out.

Surya

From: Daniel Wheeler [mailto:notifications@github.com] Sent: Thursday, September 11, 2014 12:30 PM To: openmaterials/pymks Cc: Surya Kalidindi Subject: Re: [pymks] PyMKS fails to predict strain for a seperated binary material (#108)

Influence Coefficients

https://cloud.githubusercontent.com/assets/1986844/4237559/0f6979aa-39d0-11e4-9399-4f6484fdcfad.pngindexThe channel 0 coefficients are [ 4.02920352e-05 4.03824445e-05 4.06129850e-05 4.11034965e-05 4.21052730e-05 4.41816572e-05 4.88464092e-05 6.17310951e-05 1.18197232e-04 6.67998275e-04 2.90787933e-03 6.67998275e-04 1.18197232e-04 6.17310951e-05 4.88464092e-05 4.41816572e-05 4.21052730e-05 4.11034965e-05 4.06129850e-05 4.03824445e-05 4.02920352e-05]going from left to right in the center plane and the channel 1 coeffs[ 4.53514739e-05 4.53514739e-05 4.53514739e-05 4.53514739e-05 4.53514739e-05 4.53514739e-05 4.53514739e-05 4.53514739e-05 4.53514739e-05 4.53514739e-05 4.53514739e-05 4.53514739e-05 4.53514739e-05 4.53514739e-05 4.53514739e-05 4.53514739e-05 4.53514739e-05 4.53514739e-05 4.53514739e-05 4.53514739e-05 4.53514739e-05]I guess looking at these values, it is fairly obvious that the coefficientscan't be zero padded.—Reply to this email directly or view it on GitHubhttps://github.com/openmaterials/pymks/issues/108#issuecomment-55290419 .https://github.com/notifications/beacon/6601815__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcyNjA3MjE4MiwiZGF0YSI6eyJpZCI6NDIxMjc4MjF9fQ==--5cb45615beb9456e5a0cc24e880c8a981d4c755f.gif

[wd15]

On Thu, Sep 11, 2014 at 2:22 PM, Surya Kalidindi notifications@github.com wrote:

In our original paper on MKS (with Landi) , we preferred to set the k=0 values to predefined values for this exact reason.

Awesome. Thanks. Will try and understand this.

We only did the calibration for the rest of the terms. Please see Eqs. (8) and (9) in the enclosed paper. Hope this helps sort this out.

Didn't see the attachment. Link will be fine though.

Daniel Wheeler

[davidbrough1]

Dr. Kalidindi,

I didn't see an attachment either. Are you referring to the equations 10 and 11 on page 29 in the link below?

https://idea.library.drexel.edu/islandora/object/idea%3A3491/datastream/OBJ/A_novel_spectral_approach_to_multi-scale_modeling.pdf

[wd15]

For completeness, here is the link

http://dx.doi.org/10.1016/j.actamat.2010.01.007

We are concerned with Equations (1), (8) and (9). We certainly are not applying any volume constraints at present if that's important. Will try and figure this out.

[suryakalidindi]

Happy to discuss with both of you in more detail to make sure I am communicating properly. I do not know for sure if this is the problem. But it is definitely worth looking into and fixing anyway….

SK

From: Daniel Wheeler [mailto:notifications@github.com] Sent: Thursday, September 11, 2014 4:10 PM To: openmaterials/pymks Cc: Surya Kalidindi Subject: Re: [pymks] PyMKS fails to predict strain for a seperated binary material (#108)

For completeness, here is the link

http://dx.doi.org/10.1016/j.actamat.2010.01.007

We are concerned with Equations (1), (8) and (9). We certainly are not applying any volume constraints at present if that's important. Will try and figure this out.

— Reply to this email directly or view it on GitHub https://github.com/openmaterials/pymks/issues/108#issuecomment-55320633 . https://github.com/notifications/beacon/6601815__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcyNjA4NTM3OSwiZGF0YSI6eyJpZCI6NDIxMjc4MjF9fQ==--52444b1669e49508b5a8d9f1138ca358e8a53740.gif

[wd15]

On Fri, Sep 12, 2014 at 8:38 AM, Surya Kalidindi notifications@github.com wrote:

Happy to discuss with both of you in more detail to make sure I am communicating properly.

David and I (and whoever is interested) are going to have a discussion at 3 on Google hangouts so that might be a good time to discuss or we could arrange another hangout at time of your choosing.

I do not know for sure if this is the problem. But it is definitely worth looking into and fixing anyway….

For sure. Clearly, there is a volume constraint which we are not observing.

Daniel Wheeler

[suryakalidindi]

Are you calling Eq. (1) a volume constraint?

SK

From: Daniel Wheeler [mailto:notifications@github.com] Sent: Friday, September 12, 2014 9:55 AM To: openmaterials/pymks Cc: Surya Kalidindi Subject: Re: [pymks] PyMKS fails to predict strain for a seperated binary material (#108)

On Fri, Sep 12, 2014 at 8:38 AM, Surya Kalidindi notifications@github.com wrote:

Happy to discuss with both of you in more detail to make sure I am communicating properly.

David and I (and whoever is interested) are going to have a discussion at 3 on Google hangouts so that might be a good time to discuss or we could arrange another hangout at time of your choosing.

I do not know for sure if this is the problem. But it is definitely worth looking into and fixing anyway….

For sure. Clearly, there is a volume constraint which we are not observing.

Daniel Wheeler

— Reply to this email directly or view it on GitHub https://github.com/openmaterials/pymks/issues/108#issuecomment-55406417 . https://github.com/notifications/beacon/6601815__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcyNjE0OTMxMCwiZGF0YSI6eyJpZCI6NDIxMjc4MjF9fQ==--36f5f7ebfa0c95a8147b34d8327fd77814459fb7.gif

[davidbrough1]

In equation 6 in the link below there is a similar constraint.

doi://10.1016/j.actamat.2010.10.008 http://dx.doi.org//10.1016/j.actamat.2010.10.008

We will have to think about how to make a general form of the constraint that works for hopefully all applications.

On Fri, Sep 12, 2014 at 9:55 AM, Daniel Wheeler notifications@github.com wrote:

On Fri, Sep 12, 2014 at 8:38 AM, Surya Kalidindi notifications@github.com

wrote:

Happy to discuss with both of you in more detail to make sure I am communicating properly.

David and I (and whoever is interested) are going to have a discussion at 3 on Google hangouts so that might be a good time to discuss or we could arrange another hangout at time of your choosing.

I do not know for sure if this is the problem. But it is definitely worth looking into and fixing anyway….

For sure. Clearly, there is a volume constraint which we are not observing.

Daniel Wheeler

— Reply to this email directly or view it on GitHub https://github.com/openmaterials/pymks/issues/108#issuecomment-55406417.

[suryakalidindi]

The two constraints being discussed are exactly the same. One is expressed in real space and the other is expressed in DFT space.

From my perspective, the simply way to impose the constraint is to simply assign the value to the corresponding variables (these are very simple assignments) and not include them in the calibration process. In some sense, this represents prior information from the physics of the problem that cannot be violated.

Having said that if we do what you have been doing, you are not violating the physics, but you are indirectly accounting for it as this is implicit in the datasets you used in the calibration. So you are indeed imposing this constraint in your calibration process, but it is entering as a “soft” (indirect) constraint.

SK

From: David Brough [mailto:notifications@github.com] Sent: Friday, September 12, 2014 10:17 AM To: openmaterials/pymks Cc: Surya Kalidindi Subject: Re: [pymks] PyMKS fails to predict strain for a seperated binary material (#108)

In equation 6 in the link below there is a similar constraint.

doi://10.1016/j.actamat.2010.10.008 <http://dx.doi.org//10.1016/j.actamat.2010.10.008 http://dx.doi.org/10.1016/j.actamat.2010.10.008 >

We will have to think about how to make a general form of the constraint that works for hopefully all applications.

On Fri, Sep 12, 2014 at 9:55 AM, Daniel Wheeler notifications@github.com wrote:

On Fri, Sep 12, 2014 at 8:38 AM, Surya Kalidindi notifications@github.com

wrote:

Happy to discuss with both of you in more detail to make sure I am communicating properly.

David and I (and whoever is interested) are going to have a discussion at 3 on Google hangouts so that might be a good time to discuss or we could arrange another hangout at time of your choosing.

I do not know for sure if this is the problem. But it is definitely worth looking into and fixing anyway….

For sure. Clearly, there is a volume constraint which we are not observing.

Daniel Wheeler

— Reply to this email directly or view it on GitHub https://github.com/openmaterials/pymks/issues/108#issuecomment-55406417.

— Reply to this email directly or view it on GitHub https://github.com/openmaterials/pymks/issues/108#issuecomment-55409184 . https://github.com/notifications/beacon/6601815__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcyNjE1MDYzMSwiZGF0YSI6eyJpZCI6NDIxMjc4MjF9fQ==--7ec8fdd33778d1e2e1abf356a71ffa43823e89d1.gif

[wd15]

On Fri, Sep 12, 2014 at 10:11 AM, Surya Kalidindi notifications@github.com wrote:

Are you calling Eq. (1) a volume constraint?

Equation 1 is actually two equations. I'm talking about the second part. The constraint that is a sum over the spatial index. We are not using that constraint currently (at least I don't think so).

The code for that implements the constraints is the following

https://github.com/openmaterials/pymks/blob/master/pymks/mks_regression_model.py#L109

We have to rethink this.

Daniel Wheeler

[davidbrough1]

I think we need to apply equation 6 http://dx.doi.org//10.1016/j.actamat.2010.10.008 into this section https://github.com/openmaterials/pymks/blob/master/pymks/mks_regression_model.py#L111 section of the code.

On Fri, Sep 12, 2014 at 11:15 AM, Daniel Wheeler notifications@github.com wrote:

On Fri, Sep 12, 2014 at 10:11 AM, Surya Kalidindi < notifications@github.com> wrote:

Are you calling Eq. (1) a volume constraint?

Equation 1 is actually two equations. I'm talking about the second part. The constraint that is a sum over the spatial index. We are not using that constraint currently (at least I don't think so).

The code for that implements the constraints is the following

https://github.com/openmaterials/pymks/blob/master/pymks/mks_regression_model.py#L109

We have to rethink this.

Daniel Wheeler

— Reply to this email directly or view it on GitHub https://github.com/openmaterials/pymks/issues/108#issuecomment-55417176.

[davidbrough1]

It looks like the current version of the code is maintaining the values for the k = 0 frequencies after scaling to a larger size. The value for k=0 frequency for both the initial calibration datasets and the larger datasets is equal to the macroscopic strain applied to the material for all the influence coefficients.

In the image below the middle section of the binary microstructure (93 x 93) has a strain value that matches the value of the macroscopic strain (0.02).

It's as if the local state is not affecting itself after the coefficients have been scaled up.

Any additional thoughts?

[davidbrough1]

Below is a plot of three sets of influence coefficients. The coefficients labeled as "small" were calibrated with 31 x 31 delta microstructures. The coefficients labeled as "rescaled" are the small coefficients that are zero padded to 93 x 93. The coefficients labeled as "large" were calibrated using 93 x 93 delta microstructures.

It looks like the small influence coefficient approach a value that is too large. Could this be an issue with the calibration method used to get the coefficients as opposed to their resizing?

[wd15]

I think this is more of a research topic than an issue with PyMKS so closing this issue.