Compositional viscosity prefactors interface

[lhy11009]

Pull Request Checklist. Please read and check each box with an X. Delete any part not applicable. Ask on the forum if you need help with any step.

I change the interface of the CompositionalViscosityPrefactors to be more consistent with the calculate_isostrain_viscosities function.

Before your first pull request:

• I have read the guidelines in our CONTRIBUTING.md document.

For all pull requests:

• I have followed the instructions for indenting my code.

For new features/models or changes of existing features:

• I have tested my new feature locally to ensure it is correct.
• I have created a testcase for the new feature/benchmark in the tests/ directory.
• I have added a changelog entry in the doc/modules/changes directory that will inform other users of my change.

[lhy11009]

@danieldouglas92 Please take a look at this PR.

This update makes several adjustments to better align the new rheology implementation with the structure used in other material model modules:

I modified the compute_viscosity function so that it now explicitly takes temperature, pressure, fluid_fraction, etc., as input arguments. This brings the interface in line with the approach used by the other rheology modules.

I reordered where this function is called within calculate_isostrain_viscosities. With this change, it is now clearer that the previously computed diffusion and dislocation viscosities are treated as the base viscosity for this module.

Water fugacity is currently first introduced as a variable in calculate_isostrain_viscosities. Following this adjust, we can now also allow users to pass in a constant water fugacity value directly in visco_plastic.cc. This is likely to be broadly useful, and I can implement that extension in a follow-up PR.

@mibillen
Daniel previously implemented this excellent rheology module that includes water fugacity, which is something we have wanted for a long time. This PR only makes a small adjustment to the interface, and one more such PR might follow.

[lhy11009]

The commit catalog seems to be messed up a little for a reason I don't know (I just rebased on the main branch), but it seems to contain this previous commit already in the main branch.

[lhy11009]

Yes, I rebased, and now the commit list is right.

[danieldouglas92]

Thanks for cleaning up this code Haoyuan, I think that this looks great! Only one minor comment to remove todo line.

[lhy11009]

Yes, removed

[gassmoeller]

I like the code simplification you did in visco_plastic.cc, but I dont quite understand your change to the interface of compositional_viscosity_prefactors. We usually try to avoid interface changes. Can you summarize what you are trying to achieve? Maybe we can find a way that does not break compatibility with the old code.

[gassmoeller]

Not your fault, but can you change this to a proper doxygen comment:
/**

• The flow law ...
• ...
  */

[gassmoeller]

I dont really like the existence of this function, because it exposes information from inside the plugin to the outside world. The same functionality could be put to the beginning of the compute_viscosity() function and then you just return the base_viscosity without multiplying anything. Is there another reason this information is needed outside of this plugin?

[lhy11009]

I don't know what happens to this file, my CMakeLists.txt in this branch is the same as origin/main

[gassmoeller]

This is better, but I still dont like the change to the CompositionalViscosityPrefactors interface. This plugin was intended to offer several different prefactors to viscosity based on values of the compositional fields. It so happens that the fugacity multiplication is the only one that is currently implemented. However, your modified interface limits the plugin to exactly this one case, because it adds the fluid_fraction as additional parameter.
Can you explain more what you intend to do with the bound_fluid_fraction in the future? If you want to be able to set a constant value instead of using the compositional field value, this could be an input parameter of CompositionalViscosityPrefactors and would not require changes outside of the class. I would prefer to contain the change inside CompositionalViscosityPrefactors if possible.

[lhy11009]

Okay, I see your point.

My main goals with this change are:

(1) To make temperature and pressure explicit inputs to the interface.

(2) To allow bound_fluid_fraction to be defined as a constant.

I agree that point (2) can be handled without modifying the interface.

However, for point (1), in all other rheology modules temperature and pressure are passed from the upper-level calculate_..._viscosity functions. That leads to two broader questions that I think are worth considering:

a. Interface consistency with other rheology modules
Currently this module behaves differently from the others. Aligning the interface would make the overall structure more uniform and easier to maintain.

b. Flexibility of passing P and T from the top level
Passing pressure and temperature from the top level could be useful in future extensions. For example, a user might want to use adiabatic pressure instead of full dynamic pressure. If that option were implemented, it would ideally be handled consistently across all rheology modules, which is easier if P and T are passed explicitly.

Given these considerations, I see two reasonable paths forward:

1. For this module, accept temperature and pressure from the upper level, but still keep MaterialInputs as an argument so that additional variables can be queried when needed.

2. Alternatively, we could consider a more general refactoring of the interfaces of other modules. Instead of passing P and T directly, they could take MaterialInputs as input. Then, at the upper level, we could make a modified copy of MaterialInputs (for example replacing pressure with adiabatic pressure) and pass it consistently to all rheology modules.

[gassmoeller]

Hi Haoyuan,
I understand your goals, but I would still prefer to keep the current interface untouched, and instead do this a different way (I describe that below). Here is my reasoning:

a. Interface consistency with other rheology modules

It is correct that the rheology modules currently use different interfaces. This is also the main reason they are not derived from a common Interface class. When we introduced the rheology modules we couldnt come up with a consistent interface that would work for all modules, so we decided that since these modules are so different, they should also be allowed to implement their own interfaces. Of course it is useful if they are still as similar as possible, but I do not think what you need for your application requires a change of the interface. Additionally, personally I prefer the interface that CompositionalViscosityPrefactors uses at the moment compared to the other rheology modules (because it provides access to all the material model inputs that may be relevant for other implementation of prefactors).

b. Flexibility of passing P and T from the top level

Two thoughts: 1. It is already possible to pass in P and T from the top level (like you say you could create a modified MaterialModelInputs with a different P and T and pass that in). And 2. you write it could be useful in future extensions. As long as you dont need it at the moment I would default to keeping the status quo. The example you mention for example replacing pressure with adiabatic pressure is also something I would solve differently, namely like in the ViscoPlastic rheology module you could have an input parameter for the module that determines whether to use adiabatic or full pressure (or temperature). This is fundamentally a conflict between consistency (using one input parameter to control all parts of a material model) and self-containment (making modules/plugins self-contained units that bundle all necessary input parameters and functions). It is not clear there is one superior solution, but I would prefer to keep things self-contained in the rheology modules.

Does this sound reasonable, or did I miss something important?

[lhy11009]

Yes, this looks great to me. I think the next steps could be:

We define an option within this module to allow using the adiabatic pressure instead. Then I can use the same option in the .prm file for the ViscoPlastic model — does that sound reasonable?

After reading your explanation, I agree that this interface is indeed better than the older plugin-style approach. Passing the full input set and letting the rheology module extract only the variables it needs is cleaner and more flexible. I think we should keep this design.

When using adiabatic pressure and looking at the evaluate() function, I sometimes wonder whether this option is consistently applied across all rheology modules. If not, it seems we would need to define a similar option in each module to ensure consistent behavior.