Skip to content

feat: support non-scalar valued field specifications #4034

Open
kdrienCG wants to merge 57 commits into
developfrom
feature/kdrienCG/nonScalarFieldSpecification
Open

feat: support non-scalar valued field specifications #4034
kdrienCG wants to merge 57 commits into
developfrom
feature/kdrienCG/nonScalarFieldSpecification

Conversation

@kdrienCG

@kdrienCG kdrienCG commented Apr 22, 2026

Copy link
Copy Markdown
Contributor

This PR generalizes field specifications to support non-scalar values, notably scales (and so function names).

The following interface is proposed:

<FieldSpecification
   name="perm_wall"
   initialCondition="1"
   setNames="{ wall1, wall2 }"
   objectPath="ElementRegions/Region1/block1"
   fieldName="rockPerm_permeability"
   scale="{ 2.0e-22, 2.0e-22, 2.0e-22 }"
/>

// or for a single value
<FieldSpecification
   name="..."
   ...
   scale="42"
/>

Instead of:

<FieldSpecification
   name="permx_wall"
   component="0"
   initialCondition="1"
   setNames="{ wall1, wall2 }"
   objectPath="ElementRegions/Region1/block1"
   fieldName="rockPerm_permeability"
   scale="2.0e-22"
/>

<FieldSpecification
   name="permy_wall"
   component="1"
   initialCondition="1"
   setNames="{ wall1, wall2 }"
   objectPath="ElementRegions/Region1/block1"
   fieldName="rockPerm_permeability"
   scale="2.0e-22"
/>

<FieldSpecification
   name="permz_wall"
   component="2"
   initialCondition="1"
   setNames="{ wall1, wall2 }"
   objectPath="ElementRegions/Region1/block1"
   fieldName="rockPerm_permeability"
   scale="2.0e-22"
/>

This PR also add a regionNames array to make it easier to specify multiple regions.

@kdrienCG kdrienCG self-assigned this Apr 22, 2026
@kdrienCG kdrienCG added the type: feature New feature or request label Apr 22, 2026
@kdrienCG kdrienCG marked this pull request as ready for review May 4, 2026 08:38
@kdrienCG kdrienCG marked this pull request as ready for review May 15, 2026 10:13
@kdrienCG kdrienCG requested review from tjb-ltk and wrtobin as code owners May 15, 2026 10:13
@kdrienCG kdrienCG marked this pull request as draft May 15, 2026 15:27
@kdrienCG

Copy link
Copy Markdown
Contributor Author

I've removed the regionNames attribute, I'll open a separate PR for the objectPath

@MelReyCG

Copy link
Copy Markdown
Contributor

@kdrienCG can you look if you can add a check on the user input vector dimension in relation to the field tensorial dimensions?

kdrienCG added 9 commits May 20, 2026 11:27
Potential solution was:
```cpp
#ifndef NDEBUG
  GEOS_WARNING_IF( m_functionName.size() > 1,
                     "getFunctionName() used while m_functionName has multiple values. Consider using getFunctionNames()" );
#endif
```
It may not be worth bringing the whole Logger header for this check...
* Accessor
* @return const m_scales
*/
arrayView1d< real64 const > getScales() const

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Be consistent (plural) with scaleString() { return "scale"; }

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(same for setter)

Comment on lines +318 to +319
bool usesNonScalarValues() const
{ return m_scale.size() > 1 || m_functionName.size() > 1; }

@MelReyCG MelReyCG Jun 22, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems quite complicated to maintain. To avoid having 4 ways branching ( scale scalar or not, functionNames scalar or not ), I suggest to, for scale and functionNames:

  • control that if we have >1-dim vectors, it has the the same dimensions as the field (numArrayComp()?) in postProcessInput();
  • still in postProcessInput(), duplicate any 1-dim vector so it has the same dimensions as the field;
  • then we are able to remove this method, and any downstream branching.

@kdrienCG kdrienCG marked this pull request as ready for review July 16, 2026 13:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci: run integrated tests Allows to run the integrated tests in GEOS CI flag: requires rebaseline Requires rebaseline branch in integratedTests type: feature New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants