Skip to content

feat: support non-scalar valued field specifications - #4034

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

feat: support non-scalar valued field specifications #4034
kdrienCG wants to merge 58 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 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
@kdrienCG kdrienCG added the ci: run code coverage enables running of the code coverage CI jobs label Jul 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci: run code coverage enables running of the code coverage CI jobs 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