Dennis & Schnabel algorithm for computing the differencing parameter

[andrsd]

Add this PETSc options as default: -mat_mffd_type ds
maybe even create an option in the input file...

[friedmud]

I think we should make this the default.

In my testing this never adds extra time... but always results in better convergence behavior.

[permcody]

This is hilarious reading this several years in the future. I'm sure we'll only have to diff a few hundred tests.

[friedmud]

Can't be that many tests using FD Jacobian...

[lindsayad]

So changing the default from wp to ds leads to 54 test failures in our current suite

[permcody]

How about modules? 54 is not too bad and we could just set the fd type explicitly for those. If there are a ton in modules though, we might just have to boot on this.

[andrsd]

We could still add the input file parameter for switching it, like we have solve_type.

[lindsayad]

126 failures in module tests. Would having an input file parameter be much better than just specifying it in the petsc options?

[permcody]

I'm not terribly picky about PETSc specific options. Having an input parameter is nice, but PETSc guys like to just use petsc options directly so I can go either way.

One downside to just switching the default and updating all existing test is that MOOSE+modules is only the beginning. We are likely to run into even more problems in applications. Before you do anything else, push a PR and let CIVET show you just how bad the damage is for switching the default.

[lindsayad]

Booting sounds good to me :-) But yea, I'll push a PR

[permcody]

Well one things for sure, we'll make a decision on whether or not we are going to close this issue rather than just leave it open. If this is going to be difficult, we'll document that and close this issue. We can't just let these sit open for years and years.

[andrsd]

Would having an input file parameter be much better than just specifying it in the petsc options?

If we do an input file parameter and the PETSc options change, we fix the code and all input files work as before. If you keep it in petsc_options parameter and they change, then you need to go update all input files.

[fdkong]

I am not a big fan to change the default PETSc setting in moose. There is the reason that WP is set as the default scheme in PETSc. WP is cheaper than DS because DS involves more collective operations.
http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MATMFFD_DS.html#MATMFFD_DS

This is not significant when the number of processes is small, but it does matter when we are going to run a large number of processes (more than ten thousands).

Users can change this through a petsc option for the particular case, if the want.

[friedmud]

However: most (99.9%) of all MOOSE runs are done on less than 100 processors... so changing the default for MOOSE makes sense. BUT: we do have a huge history of having wp be the default... and changing it now could be incredibly painful. So... I'm fine with leaving it as is.

…

On Thu, Sep 7, 2017 at 1:53 PM Fande Kong ***@***.***> wrote: I am not a big fan to change the default PETSc setting in moose. There is the reason that WP is set as the default scheme in PETSc. WP is cheaper than DS because DS involves more collective operations. http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/MATMFFD_DS.html#MATMFFD_DS This is not significant when the number of processes is small, but it does matter when we are going to run a large number of processes (more than ten thousands). Users can change this through a petsc option for the particular case, if the want. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#584 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA1JMUsNJKwLDJTndLNi0ME_8DhOo_aJks5sgCVegaJpZM4G3pTP> .

[fdkong]

However: most (99.9%) of all MOOSE runs are done on less than 100
processors... so changing the default for MOOSE makes sense.

Potentially, I hope moose also runs smoothly with a large number of cores. And I guess WP fails for 1% of moose runs? If WP fails for a small number of moose runs, we can fix these individually.

BUT: we do have a huge history of having wp be the default... and changing
it now could be incredibly painful. So... I'm fine with leaving it as is.

[permcody]

It's not that it fails, it's that it can give you a different answer potentially outside of the gold file tolerances.

…

On Thu, Sep 7, 2017 at 1:51 PM Fande Kong ***@***.***> wrote: However: most (99.9%) of all MOOSE runs are done on less than 100 processors... so changing the default for MOOSE makes sense. Potentially, I hope moose also runs smoothly with a large number of cores. And I guess WP fails for 1% of moose runs? If WP fails for a small number of moose runs, we can fix these individually. BUT: we do have a huge history of having wp be the default... and changing it now could be incredibly painful. So... I'm fine with leaving it as is. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#584 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC5XIDsHPSYlf0hl_dKHd--IQhN5Lu-Uks5sgEk4gaJpZM4G3pTP> .

[lindsayad]

Ok, we'll punt on making ds the default. But I'm going to work on making mffd_type an Executioner input parameter since I believe at least @andrsd would like this. Sound ok?

[andrsd]

Sounds good to me.

[lindsayad]

Closed by #9808