Patch Size Based On Distance

[friedmud]

Right now the patch_size parameter that controls geometric search is based on the number of nodes to keep in the "patch". Instead of using number of nodes we should switch to using a distance. This will allow for more mesh size independence.

Linking a few people in here that should be interested in this: @jasondhales @bwspenc @peredani

UPDATE (01/14/2015): @roystgnr will be working with @friedmud to fix up the remaining issues with the patch size problem. As I understand it, we can now update the patch size during a simulation. There is however a new issue that arises when we do this. We get an error message from PETSc stating that there is a problem with the non-zero pattern after a certain number of steps.

Original code committed here: https://github.com/idaholab/moose/issues/3901

@gambka Can you point us to your smallest most recent example that replicates this issue? Thanks!

[RichWilliamson]

We've learned that this issue is a show stopper for our full length rod validation cases. They often will not get through contact without using constraint-based contact but are prohibitively slow with a required patch size of about 50. So we just can't run them at present.

[friedmud]

Ok - thanks for letting us know... I'll prioritize this higher...

[gambka]

I'll be committing a branch to my fork called patch_size. I have been able to recreate the same PETSc error on a much smaller problem. I have uploaded 2 input files one and 2 mesh files. One is using first order elements and the other second order elements. The files are located in modules/combined/tests/sliding_block/patch_size_testing/

Here is the status of my investigation so far in regards to this sliding block problem:

Using PETSc 3.4.3 the problem runs without using the patch_update_strategy = auto, but fails when using the patch_update_strategy.

Using PETSc 3.5 the problem runs regardless if patch_update_strategy = auto is turned on or not.

However, the original problem I had constructed a few months ago failed with the same error using PETSc 3.4.3 or PETSc 3.5. That problem contained BISON material properties and was a 2D-RZ simulation. The current simulation is 2D but not RZ. Perhaps there is something wrong when trying an RZ problem regardless of PETSc version when using the update strategy? I will try deBISONizing the original case and shrink it in size and see if I can replicate the error on both PETSc versions.

In addition @bwspenc has a very coarse deBISONized 3D simulation that was not working with the patch_update_strategy.

[friedmud]

The problem isn't anything to do with RZ. This is a PETSc issue (which is why it changes as you change your version of PETSc). PETSc is not properly dealing with the sparsity pattern changing in the preconditioning matrix (and it is supposed to).

I'm going to get this fixed (one way or another) next week.

Derek

On Thu, Jan 15, 2015 at 12:33 PM, Kyle Gamble notifications@github.com wrote:

I'll be committing a branch to my fork called patch_size. I have been able to recreate the same PETSc error on a much smaller problem. I have uploaded 2 input files one and 2 mesh files. One is using first order elements and the other second order elements. The files are located in modules/combined/tests/sliding_block/patch_size_testing/

Here is the status of my investigation so far in regards to this sliding block problem:

Using PETSc 3.4.3 the problem runs without using the patch_update_strategy = auto, but fails when using the patch_update_strategy.

Using PETSc 3.5 the problem runs regardless if patch_update_strategy = auto is turned on or not.

However, the original problem I had constructed a few months ago failed with the same error using PETSc 3.4.3 or PETSc 3.5. That problem contained BISON material properties and was a 2D-RZ simulation. The current simulation is 2D but not RZ. Perhaps there is something wrong when trying an RZ problem regardless of PETSc version when using the update strategy? I will try deBISONizing the original case and shrink it in size and see if I can replicate the error on both PETSc versions.

In addition @bwspenc https://github.com/bwspenc has a very coarse deBISONized 3D simulation that was not working with the patch_update_strategy.

— Reply to this email directly or view it on GitHub https://github.com/idaholab/moose/issues/3305#issuecomment-70146644.

[permcody]

Closing based on @bwspenc's latest status

I've been testing BISON built against the latest patch release of PETSc (3.5.2) on Kyle's problem that was previously failing when used with the automatic patch update, and so far it seems to be working.

This model is a full-length 2D axisymmetric fuel rod. He made the model really coarse to use for debugging. It has successfully run all the way through with a patch size of 10, which required 5 updates over the analysis. That case previously failed. I'm also in the middle of running it with a patch size of 3, which is requiring more updates. So far, it's done 14 updates, and it's about 75% done.

Jason Miller is building me a package with PETSC 3.5.2 to build against on Falcon, and once that's ready, I'll try running a few big problems there to make sure it works. I'll keep you posted on how that goes.

We really appreciate the help with this problem. I think we're in good shape for now -- we just need to do more testing.

[friedmud]

This ticket is actually not fixed. The patch size parameter itself is still based on number of nodes... not on distance (which is what this Issue is actually all about).