Fixes for BDDC#5152
Conversation
e11e7da to
2f8b06c
Compare
804646e to
1bc6e36
Compare
default values for options should guarantee robustness wrt H1,Hdiv and Hcurl problems
| @@ -34,9 +34,12 @@ class BDDCPC(PCBase): | |||
| the options: | |||
| - ``'bddc_cellwise'`` to set up a MatIS on cellwise subdomains if P.type == python, | |||
| - ``'bddc_matfree'`` to set up a matrix-free MatIS if A.type == python, | |||
There was a problem hiding this comment.
Can you do matrix-free MatIS? Then the divergence matrix can be passed that way, I only need the action of its local part (in MATIS sense) on a given vector
There was a problem hiding this comment.
I think we need to fix support for matfree A in BDDC
|
@connorjward BDDC is younger than Submesh. Can this go into release? It does not break API. |
| num_entities = len(active_entities) | ||
|
|
||
| kernel_code = f""" | ||
| void compute_entity_coordinates(PetscScalar *coords, PetscScalar *cg1_coords) {{ |
There was a problem hiding this comment.
Sorry about the parloop. There is no better way of computing entity coordinates on extruded meshes.
There was a problem hiding this comment.
It's not an issue. Moving this to pyop3 is easy.
| cg1_offsets, cg1_flatmap = flatten_entity_ids(active_entities, cg1_closure_ids) | ||
| v_offsets, v_flatmap = flatten_entity_ids(active_entities, V_entity_ids) |
There was a problem hiding this comment.
These data structures wouldn't be required if we use an op2.PermutedMap
There was a problem hiding this comment.
It only occured to me just now. Only v_flatmap is permutation, cg1_flatmap will have repeated indices because it defines the dofs supported on the closure of an entity (and edge will include its vertices), so this case is not covered by a permutation. We would still need to flatten_entity_ids at least for the CG1 element, so it is better to keep the code as is.
There was a problem hiding this comment.
Ideally we should be running a parloop on the mesh entities. I know, wait for pyop3...
connorjward
left a comment
There was a problem hiding this comment.
Seems more or less fine. I think release is OK because this is a sufficiently new feature and you're only touching code in one file.
| # On MacOSX the distributed right-hand side is bugged! | ||
| if DEFAULT_DIRECT_SOLVER == "mumps": |
There was a problem hiding this comment.
This comment does not explain the code changes. There's nothing here that's obviously specific to macOS
There was a problem hiding this comment.
there's no way this can be reported officially to MUMPS people. It is a known issue on only some osx configurations
There was a problem hiding this comment.
The comment would lead me to expect a check like: if os.system == "darwin" or similar.
| # "ksp_view": None, | ||
| # "ksp_monitor_singular_value": None, |
There was a problem hiding this comment.
| # "ksp_view": None, | |
| # "ksp_monitor_singular_value": None, |
There was a problem hiding this comment.
Why? it is a quick way to check if something goes wrong instead of having to retype the options
| num_entities = len(active_entities) | ||
|
|
||
| kernel_code = f""" | ||
| void compute_entity_coordinates(PetscScalar *coords, PetscScalar *cg1_coords) {{ |
There was a problem hiding this comment.
It's not an issue. Moving this to pyop3 is easy.
| # On MacOSX the distributed right-hand side is bugged! | ||
| if DEFAULT_DIRECT_SOLVER == "mumps": | ||
| sp.update({"bddc_pc_bddc_coarse_mat_mumps_icntl_20": 0}) | ||
|
|
There was a problem hiding this comment.
I think we can simply remove this from here
| # On MacOSX the distributed right-hand side is bugged! | |
| if DEFAULT_DIRECT_SOLVER == "mumps": | |
| sp.update({"bddc_pc_bddc_coarse_mat_mumps_icntl_20": 0}) |
There was a problem hiding this comment.
But shouldn't this be the default?
There was a problem hiding this comment.
What is the problem of leaving the option in? A test should just work, and this is a known MUMPS bug
There was a problem hiding this comment.
But shouldn't this be the default?
No, the default is distributed right-hand side, which means no need to gather the rhs on the master process
Co-authored-by: Pablo Brubeck <brubeck@protonmail.com>
Description
Internal fixes required for BDDCPC to work on primal elasticity problems.
Adds new options
-pc_bddc_use_divergence_matand-pc_bddc_use_discrete_gradient. Their defaults are the correct ones for the Riesz map in the de Rham complex, H(curl) needs the gradient, while H(div) needs the divergence. The H1 Riesz map does not need an extra operator. However, elasiticity problems are posed on H1, but BDDC would need to be aware of the divergence, so in this case the user must prescribe it.