no convergence and rule of thumbs for dic settings

[talledodiego]

Hi, first of all thanks for this awesome library. I found this library after reading your paper of 2020.

I have a couple of questions that I hope can be answered:

• A good guess for initial mesh is 40x40 pixels. if We have a big specimen this is a very fine mesh and could take long time for computation of correlation. I suppose that of course this number actually depends on the size of the speckle pattern and the size of the specimen. I have the feeling that somehow in a finite element there should be some points of the speck, am I correct?
• What is an indicative rule for how many images are needed? Specifically I have a movie, so I was just try to understand if I need to process one every 10 frames, 30 frames, each frame or other. I'm afraid that using lots of frames doesn't improve the accuracy of the results. Do you have any indication about that?
• What is the general rule-of-thumb for definition of frames for reference update?
• Is it possible to build non rectangular meshes? For instance my ROI is L shaped, up to know I am selecting one rectangle where my phenomena happens.
• In the example I'm trying to do I never reach convergence. Each frame is computed up to the maximum number of iteration... I tried processing a huge amount of images (one frame of the movie every 5 frames, so basically 6 frames each second).
• Is it possible to think about a parallelization of parts of the process? as far as I understand each frame is correlated with the same reference. By default this reference changes once in a while, unless update after no convergence is considered. Except for this last case a think the process can be parallelized to improve speed of computation. Do you think it may be possible?

Bests Diego

[PolymerGuy]

Hi! Thanks for your interest in this DIC toolkit.

• You are correct regarding mesh size. As we here use finite elements to discretize the deformation fields, the same kind of reasoning as for FEA is valid. By that, I mean that sharp gradients in the displacement field call for small elements etc. However, when using DIC, one needs a sufficient number of pixels within each element to keep the noise level within reasonable limits. So, personally, I go for as large elements as possible to minimize the noise level but ensure that all details within the displacement field are captured. A lower bound for element size is usually around 20x20 pixels.
• The number of images depends on the kind of deformation you are measuring. If the deformations increase too much between two frames, the correlation will fail and the analysis will probably yield erroneous results. I don't think there is a good rule of thumb here, but you will quickly notice when you use too few frames.
• Updating the reference image makes sense when the texture or lighting of the specimen has changed.
• The correlation routine supports non-rectangular meshes but I have not made any routines for generating such meshes. When I have needed special meshes, I have generated the mesh in Abaqus and imported it into muDIC. This is not a feature yet, but might be worth implementing as a part of the toolkit.
• Convergence issues are very difficult to solve without having seen the data. Feel free to contact me by mail if you want me to have a look at it.
• This tool is not written fully parallelized as the solution from one frame is used as initial conditions for the next one. However, routines like tensor products, interpolation etc. are parallel. I'm convinced that the solver can be written in a much more efficient way, but I think the increased complexity might be a problem when people wish to modify the code.

Best regards Sindre

[talledodiego]

Thank you so much for your valuable comments. I have seen indeed that in dev branch there is the abaqus mesh, and I am using it in order to create my mesh. I have a question, though. I noticed that in my data it is sometimes easier to achieve convergence when using spline instead of q4 that is only a bilinear element. I have seen that the element supports also higher order, but the mesher creates only linear elements. Do you think in my data bilinear q4 can be effective?

I send you the data link (https://www.dropbox.com/sh/um2vd311fsxpugb/AAAc64FY4t7WgevdcZldhIywa?dl=0) where you can see the input images and the movies from where I took those images. When I use only the first part (up to a visible crack, but not too much open) I can achieve convergence, but when I add the second part it is very hard to achieve convergence. The reason is that there is a too big displacement and anyway a poor possibility of correlating the images successfully due to excessive damage. I think the updating of the frames consent big strains, but the missing parts make virtually impossible to correlate the images unless maybe changing the region of interest (the meshed portion) during analysis removing the parts where excessive spalling and damaging occurs? What do you think?

[PolymerGuy]

The choice of element type is very dependent on what you want to measure. In your case, I would suggest sticking to Q4. Also, the B-spline elements are limited to rectangular meshes.

Regarding the images, what are you aiming to measure? If you want to resolve the deformation field around the crack, I don't think the speckle is fine enough?

[talledodiego]

I will try to stick with Q4 elements. Now I will create the mesh for all the L-shaped region of interest and try to change the element size to test how it performs. A colleague of mine noticed that ncorr with subsets method seemed to achieve some results, although in a step we compared before the opening of the big crack, the results where somehow different between mudic and ncorr, and ncorr results appeared more correct from first rought calculations. We will for shure dig a bit more on that.

We wanted to measure first in elastic regime the principal strains distribution in order to see if the typical distribution with an inclined strut is visible. Then after the crack formation we wanted to se if different mechanisms arise. I was afraid too that the speckle is fine enough. This was just a first attempt. From what I found in literature it appears that the size of the "dots" should be on the order of 3-5 pixels (Here I think we are more in the 10-15 pixels for an average size). Do you agree?

[PolymerGuy]

The displacement fields determined by ncorr and mudic should be identical. Note however about the definition of the coordinate systems when dealing with displacements.

The dots are pretty large and the speckle pattern is not very dense, so you will be limited to relatively large elements. So for resolving fine details around the crack tip, it's for sure too coarse.

---

Fra: talledodiego @.***> Sendt: torsdag 10. februar 2022 11:29:16 Til: PolymerGuy/muDIC Kopi: Sindre Nordmark Olufsen; Comment Emne: Re: [PolymerGuy/muDIC] no convergence and rule of thumbs for dic settings (Issue #34)

I will try to stick with Q4 elements. Now I will create the mesh for all the L-shaped region of interest and try to change the element size to test how it performs. A colleague of mine noticed that ncorr with subsets method seemed to achieve some results, although in a step we compared before the opening of the big crack, the results where somehow different between mudic and ncorr, and ncorr results appeared more correct from first rought calculations. We will for shure dig a bit more on that.

We wanted to measure first in elastic regime the principal strains distribution in order to see if the typical distribution with an inclined strut is visible. Then after the crack formation we wanted to se if different mechanisms arise. I was afraid too that the speckle is fine enough. This was just a first attempt. From what I found in literature it appears that the size of the "dots" should be on the order of 3-5 pixels (Here I think we are more in the 10-15 pixels for an average size). Do you agree?

— Reply to this email directly, view it on GitHubhttps://github.com/PolymerGuy/muDIC/issues/34#issuecomment-1034749911, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADI34VJNGMVIL4DRELXSVKDU2OHPZANCNFSM5NUE4MUA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you commented.Message ID: @.***>

[talledodiego]

thanks for your comments. I will try again. Yes, I know that when dealing with displacements the units (pixels or mm) can be set in ncorr. We compared only the strain (eps_xx) obtaining results for the same frame quite different (maximum strain was in the order of 2-3 times larger in mudic compared with ncorr), I will dig more about that specific point.

diego