Skip to content

feat: add PermeabilitySpecification as an high-level FieldSpecification#4019

Draft
kdrienCG wants to merge 8 commits intodevelopfrom
feature/kdrienCG/permeabilitySpecification
Draft

feat: add PermeabilitySpecification as an high-level FieldSpecification#4019
kdrienCG wants to merge 8 commits intodevelopfrom
feature/kdrienCG/permeabilitySpecification

Conversation

@kdrienCG
Copy link
Copy Markdown

@kdrienCG kdrienCG commented Apr 7, 2026

(Previously #4012)

This PR proposes to add an easy way to add higher-level components that create FieldSpecifications without the boilerplate.


As an example, to define the permeability you have to specify 3 differents FieldSpecifications.
One for the x-axis, a second for the y-axis, and a last one for the z-axis.
There is also some implementation details that could be hidden, like the component XML attribute for example.

<FieldSpecifications>
  <FieldSpecification
      name="permx"
      component="0"
      initialCondition="1"
      setNames="{ all }"
      objectPath="ElementRegions/reservoir"
      fieldName="rockPerm_permeability"
      functionName="permxFunc"
      scale="9.869233e-16"/>

  <FieldSpecification
      name="permy"
      component="1"
      initialCondition="1"
      setNames="{ all }"
      objectPath="ElementRegions/reservoir"
      fieldName="rockPerm_permeability"
      functionName="permyFunc"
      scale="9.869233e-16"/>

  <FieldSpecification
      name="permz"
      component="2"
      initialCondition="1"
      setNames="{ all }"
      objectPath="ElementRegions/reservoir"
      fieldName="rockPerm_permeability"
      functionName="permzFunc"
      scale="9.869233e-16"/>
</FieldSpecifications>

With this PR, their would be a PermeabilitySpecification component that would create behind the scene those three FieldSpecifications to keep full compatibility with other parts that rely on FieldSpecificationBase. One could think of PermeabilitySpecification as a blueprint or recipe to create FieldSpecificationBase objects.

Here is how it looks like for PermeabilitySpecification:

<FieldSpecifications>
    <PermeabilitySpecification
      name="perm"
      setNames="{ all }"
      regionNames="{ reservoir }"
      fieldName="rockPerm_permeability"
      functionName="permFunc"
      scales="{9.869233e-16, 9.869233e-16, 9.869233e-16}"/>
</FieldSpecifications>

The following architecture is proposed:

image

This way, similar components could be added by providing a data class (like PermeabilitySpecification) and a factory with a generate method to describe how to transform the high-level components into one or multiple "low-level" FieldSpecificationBase.

@kdrienCG kdrienCG self-assigned this Apr 7, 2026
@kdrienCG kdrienCG added type: feature New feature or request type: new A new issue has been created and requires attention labels Apr 7, 2026
@rrsettgast
Copy link
Copy Markdown
Member

Hi @kdrienCG
This is something we have been meaning to get to for a while. But not just for perm. Can you implement a generalization to allow for processing and application of arbitrary tensor inputs? There are many things that this would be useful for besides permeability. I think we could read in a "scale" as any array type, and apply appropriately. Then this could be used for stresses, displacements, or any other non-scalar field without multiple FieldSpecificaiton blocks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

type: feature New feature or request type: new A new issue has been created and requires attention

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants