Potential Modification to PhaseFunction Interface Regarding Composition Fields

[lhy11009]

Hi All

I’ve been using the introspection().get_composition_names function for handling composition fields. Recently, I learned that entropy and compositional entropies are also being utilized in some models. In light of this, I was wondering if it would make sense to modify the function to introspection().chemical_composition_field_names() to better reflect these additions.

Specifically, I’m interested in exploring whether the interface of PhaseFunction could be modified in this way. This change might allow us to leverage some utilities even when using the entropy method and lookup table. @gassmoeller , Do you think this approach would be beneficial, and is it feasible to implement?

[gassmoeller]

Hi @lhy11009, I do not quite follow. There is a function called introspection.chemical_composition_field_names, would that do what you want to do?

Specifically, I’m interested in exploring whether the interface of PhaseFunction could be modified in this way

Can you describe in a bit more details how you want to modify the interface, and what would be the new/improved functionality?

[lhy11009]

As I’ve been working with multiple compositions using the entropy method, I realized that additional fields are required for entropies and prescribed densities.

subsection Compositional fields
  set Number of fields = 6
  set Names of fields = entropy, entropy_sp_crust, entropy_sp_harz, density_field, sp_crust, sp_harz
  set Types of fields = entropy, entropy, entropy, density, unspecified, unspecified
  set Compositional field methods = field, field, field, prescribed field, field, field
end

In an effort to combine this with compositional rheology, I’ve merged the interface for compositional rheology from the visco_plastic module and intend to apply the same approach in the parameter file.

With these additional fields, I’ve managed to make it work by simply adding the required terms to the parameter file.

    (in the material model) 
    set Prefactors for diffusion creep = 8.1787e-17, 8.1787e-17, 8.1787e-17, 8.1787e-17, 8.1787e-17, 5e-21, 8.1787e-17
    set Grain size exponents for diffusion creep = 3.0, 3.0, 3.0, 3.0, 3.0, 0.0, 3.0
...

However, I believe there might be a more streamlined approach by modifying the phase function interface. Currently, we are initializing the phase functions with all the fields. Perhaps, instead, we could initialize them using only the compositional fields. This would allow me to remove redundant entries from the interface.

Additionally, I’m considering using this modified interface to assign different rheologies for various phases. By looking up the dominant phase in a table, we could specify, within the parameter file, the additional phases we want to include for each composition, which would then be used for rheology. Conceptually, this interface should function similarly to how it operates in the visco_plastic model.

set Phases for rheology = background: wd | brg, sp_crust: none, sp_harz: wd | brg
set Prefactors for diffusion creep =  background: 1.0 | 0.01, sp_crust: none, sp_harz: 1.0 | 0.01

I haven’t yet fully implemented the final step, but I thought it would be helpful to lay out these ideas now to make future work easier.

[gassmoeller]

I see. I have not looked into this code in a while, so we may have to iterate a bit here. But at first glance, what I see in the parse_parameters() of the visco_plastic rheology is that only values for the chemical compositional fields are required (

aspect/source/material_model/rheology/visco_plastic.cc

Line 677 in e4fad72

Utilities::MapParsing::Options options(chemical_field_names, "Minimum viscosity");

). It is allowed to provide values for all compositional fields, but that is optional. However, I think this is only the case if you input the values in the map structure, as in set Prefactors for diffusion creep = chemical_composition_1: number1, chemical_composition_2: number2|number3, .... If you input it as a list of values without keys (like you do) then you need to provide as many entries as there are chemical fields. Does this already help with your first suggestion?

To your future plan: Let me see if I understand your goal correctly (I mostly write this down to understand it myself): You want to use a lookup table that specifies which is the dominant phase for a given pressure-temperature, and want that information to replace the analytic phase function, which is then either 1 (dominant phase) or 0 (not dominant phase) (so far so clear). You want to specify in the input file which phase should be considered for which chemical composition (also clear). However, what happens if you have different phases for different compositional fields, say you have the ol-wd-rw-brg system for peridotite and the cpx-gt-pv system for basalt. If your table states rw is the dominant phase what are the phase function values for basalt? Oh, I see you have one table per each composition, so each table is responsible for its composition.

Can you explain how your idea compares to this open PR: #5296? Would that be a good starting point for your implementation?

[lhy11009]

Thank you for your previous comments on the phase function interface. I believe they’ve already addressed my question. After reviewing your suggestions, I see that by adding the name of the composition, I can get the utilities I need.

Regarding the phase-dependent viscosity, I am aligned with your approach. As you mentioned, we could assign dominant phases to look up for each composition. At the phase level, the viscosity will be categorized based on the dominant phase, while at the compositional level, we can still average them using their volume fractions.

I will take some time to review the PR and figure out what has already been implemented. Hopefully, Ryan and I can find some middle ground and collaboratively make progress on this front.

[gassmoeller]

Sounds great. #5296 has been open for a while without activity, so if you want to take over the PR (or open your own, but base it on that branch) then that would work for me as well.

[lhy11009]

(Sorry for the long reply) I’ve gone through the PR, and it looks like it offers the implementation I need. However, I do have a few comments regarding the method and its implementation. In terms of the method, using the dominant phase and assigning a value of 1.0 in the phase function for the dominant phase may generate very sharp rheological boundaries between phases, which could cause some issues with convergence. Regarding the implementation, it seems to modify quite a bit in visco_plastic.cc, particularly by masking the previously computed value of the phase function based on the dominant phases. Additionally, the introduction of the PhaseFunctionLookup class adds another layer of complexity. As the discussion in the PR progresses, it seems to be growing sophisticated, which might make it challenging for non-experts to follow. That said, I believe it might work better to decompose the PR into smaller ones. Here’s a potential approach: 1. *PhaseFunction Utility*: We could start by adding a utility in the PhaseFunction class to compute the dominant phase. At this stage, we could stick to the current interface using Clapeyron slopes, pressures, and temperatures to compute, leaving a future option for lookup tables. 2. *PhaseFunction Compute Option*: In the PhaseFunction.compute_value function, we could add an option to compute by the dominant phase, assigning a value of 1.0 if it’s the dominant phase and 0.0 otherwise. This step would allow us to validate the method by testing how the solver behaves with some of our existing test cases. 3. *Material Table Lookup*: As a next step, we could introduce material table lookup in the ViscoPlastic model, handing over their pointers to the PhaseFunction interface so that it can look up the dominant phases in the table. This would require little variation in the evaluate function. In summary, I suggest propagating the changes into PhaseFunction, as many of the utilities could be reused there. Meanwhile, This would likely require minimal changes to the existing code while still achieving the desired functionality. Let me know your thoughts on this approach! Best regards,

…

On Mon, Oct 14, 2024 at 6:09 AM Rene Gassmoeller ***@***.***> wrote: Sounds great. #5296 <#5296> has been open for a while without activity, so if you want to take over the PR (or open your own, but base it on that branch) then that would work for me as well. — Reply to this email directly, view it on GitHub <#6053 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG2WMFJCLSGGOE2NXS5OIADZ3O67VAVCNFSM6AAAAABPK4BZOCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJRGIYTKMBTGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Ph.D student of Geophysics Earth & Planetary Sciences Dept., UC Davis Davis, CA 95616