few minor changes to run example code in FAIRFEM

[hariagr]

1. ‘yn’ is not defined when wc is empty. Therefore, xn should be updated by yRef.

2. Addpath for add-ons folders during FAIR startup.

3. solver is defined as a char, not string. Probably, this issue has recently arises because of structural changes in R2017a.

[lruthotto]

thanks for this excellent job. Can you please resolve the conflict and clean up the .m~ files?

[lruthotto]

Hey Hari, I resolved the conflicts and added three problems. The one concerning the documentation are critical. See if you also want to address the one regarding the performance.

[hariagr]

Hi Lars,

I was busy with my work. Sorry for delay.

Now, I have modified the matrixfree implementation. Please have a look. Let me know if something else needs to be done.

Thanks, Hari

[lruthotto]

Hi Hari,

I have one comment before we can merge this (already did two minor changes to this). My goal is to finish this soon, but it's important to get things right, I think.

I noticed that your code for computing the diagonal of the Hessian is only for 2D problems. It would be great if we could extend this to 3D, where matrix-free methods are most attractive. I believe that our mesh classes provide the necessary functionality already. See one change I did to average quantities from the nodes to the barycenters of the elements. Can you help me modify the remainder of this code accordingly and write a small test file for 3D? I have push access to your repo so we can work on this together.

Thanks a lot, Lars

[lruthotto]

Hi Hari!

Thanks for your hard work and patience. It's getting close I think. One final thing that I see is to make the function getDiag in FEMPIREobjFctn work for 3D problems. If you take a look at EFEM_FEMPIRE_Mice3D the code runs until the Hessian solve. I think we need a switch statement here and implement the 2D and 3D separately.

Best, Lars

[lruthotto]

Thanks, Hari. This works for me! Great job !

[lruthotto]

Do you want me to merge this right now, or should I wait for performance improvements? I've also noticed that the matrix free code does not run for non mass-preserving problems since there is no tailored solver.

On a different note: Did you compare your code for computing the diagonal of the distance term with getDiagVolume in hyperElasticFEM.m ? Therein, I think we do not recompute things that are not needed. Might help in improving the efficiency for the objective function as well. One idea could be to pull this code out of the regularizer and call it from both functions. What do you think?

[hariagr]

Hi Lars,

1. One of the major change could be to store gradient of basis functions, i.e., variable "dphi" from the function getBasisGradient, in the MESH structure. These calculations does not depends on the current estimate "yc", therefore we can compute gradient once and store them in the MESH structure.

2. We can pull out cofactor3D function from both regularizer and distance/objective function, and call it wherever required.

I can mainly see these changes right now to improve efficiency.

I didn't check the code for non mass-preserving problems. I will try to look at it asap. There is no hurry from my side for merging the code. Probably, these changes should not take too much time. We can wait and merge once we are done with our changes.

Hari

[lruthotto]

Hi Hari,

1. storing the dphi in the mesh structure is a good idea I think. There is a way in MATLAB to have dependent fields (i.e., that are computed once and then stored). If we can get this to work, this is the way to go I think. I'm not sure if this actually works in our setup or we have to return the mesh object in every function call.
2. Do you mean extracting the getDiagVolume part or really the cofactor3D? In any case, collecting code that does the same thing will be beneficial in the long run. So we should do it.

[hariagr]

Hi Lars,

I have changed the code. dphi is now stored in the mesh structure. cofactor3D code is separated out.

In the last comment I wrote that the Matrixfree code (MF) and non-matrifree (MB) code results are not matching. But, that is not right. They are matching!! By mistake, I used different regularization parameter for MB and MF code during verification.

Hari

[hariagr]

Hi Lars,

In the MLIRFEM script, image pixel values on a coarse grid are computed at two steps, i.e.,

1. In the first step, the pixel values are defined on the cell-centered points of a finer grid ( i.e. a rectangular grid) and then restricted to a coarser grid by averaging adjacent cells (see getMultilevel.m).

2. Now, computed pixel values are estimated on barycentre points of triangular elements of FEM mesh.

Instead of this, we can probably define pixels values directly on the FEM triangular mesh and compute approximation on a coarse FEM mesh. Probably, this may results in a more accurate approximation.

I am not sure how much beneficial it would be in view of registration accuracy. Probably, you can comment on it.

Thanks, Hari

[herrinj]

Checked out Hari's branch today. I have some updates to hyperElasticFEM.m to add. Specifically, I will push code that has matrix-based and matrix-free implementations with support for 2D and 3D problems. This includes function calls to extract the diagonal of the Hessian in the matrix case for both 2D and 3D. Will upload as soon as I have everything compatible with the branch.

[lruthotto]

Perfect. Thank you both for your help!

On Mon, Jul 16, 2018 at 3:47 PM, James Herring [email protected] wrote:

Checked out Hari's branch today. I have some updates to hyperElasticFEM.m to add. Specifically, I will push code that has matrix-based and matrix-free implementations with support for 2D and 3D problems. This includes function calls to extract the diagonal of the Hessian in the matrix case for both 2D and 3D. Will upload as soon as I have everything compatible with the branch.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/C4IR/FAIR.m/pull/5#issuecomment-405359631, or mute the thread https://github.com/notifications/unsubscribe-auth/AEDYB75JIQ01wz3_CdeV7odVmnapEBjbks5uHO24gaJpZM4OTrbw .