Skip to content

Add indicator field - #886

Open
lhy11009 wants to merge 1 commit into
GeodynamicWorldBuilder:mainfrom
lhy11009:indicator_field
Open

Add indicator field#886
lhy11009 wants to merge 1 commit into
GeodynamicWorldBuilder:mainfrom
lhy11009:indicator_field

Conversation

@lhy11009

@lhy11009 lhy11009 commented Mar 26, 2026

Copy link
Copy Markdown
Contributor

In the PR, I introduce a new field "indicator". In the example, an indicator field is derived from the depth of points in a feature of an oceanic plate.

@mibillen Here is how I am going to connect the prescribed solution to GWB.

@lhy11009

lhy11009 commented Mar 26, 2026

Copy link
Copy Markdown
Contributor Author

I include a test of this new field.

Here is the test layout:
There are two oceanic plates of 250 km depth on the surface of the model domain (they have slightly different T).
image

The indicator field is assigned to the plate to the left, and between depths of 50 and 100 km:
image

Comment thread tests/gwb-grid/oceanic_plate_indicator.wb
@lhy11009

Copy link
Copy Markdown
Contributor Author

Currently, this is only added to the oceanic plate, so a lot of the tests will fail, because this field is required in the main function of gwb-grid.

Comment thread source/gwb-grid/main.cc Outdated
@lhy11009

lhy11009 commented Mar 26, 2026

Copy link
Copy Markdown
Contributor Author

I also haven't modified the gwb-dat function yet.

@MFraters, please let me know if this is the right way to move forward.

I think in order to make this work, we essentially need to add this field and models to every feature.

@lhy11009

Copy link
Copy Markdown
Contributor Author

Following @MFraters's suggestion. I modelled this like the composition field to have a list of entry.
Currently, I hard-code the length of the list to 3. The index 0, 1, 2 would correlate to "temperature", "velocity", "composition", respectively.

In usage, they don't specify which component of velocity or which component of composition I am going to prescribe, but only indicate I am going to prescribe these fields in general. I would incorporate this additional information as inputs to ASPECT instead.

I also decided to move the number of the entry later (i.e. 7 to 8), after Derek's PR with another new field is merged. This way, it would be easier to test the feature for now.

@lhy11009

Copy link
Copy Markdown
Contributor Author

This is the layout of the test after I modified the indicator to a list of entries. Indicators 0 and 1 are assigned, while indicator 2 is not.

image image image

@alarshi alarshi left a comment

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.

@lhy11009 : Thank you for the contribution! I just looked at your changes in the features folder and added my comments. I will take another look after I understand your goal more clearly. I have two comments that might help me in this process:

  1. Have you tested your path with multiple indicator models? For example, if you include another indicator model in "second oceanic plate" that only defines indicator for velocity and have some overlap in the geometries of the two, are the indicators for temperature and velocity as what you would expect? I don't fully understand how the operation works in your case.

  2. Since your goal is to identify regions within your wb feature geometries that can then use some prescribed values from ASPECT, would it be possible to achieve this by assigning some nonphysical values at those locations (say, nan) and then checking for them in ASPECT ? I guess nan is not an option because that might trigger several assertions, but you get the idea. My comment is arising from not being able to fully understand how to use this property, so feel free to ignore it if it doesn't make sense.

Comment thread source/world_builder/features/oceanic_plate_models/indicator/interface.cc Outdated
Comment thread source/world_builder/world.cc Outdated
Comment thread source/world_builder/features/oceanic_plate_models/indicator/depth_range.cc Outdated
Comment thread source/world_builder/features/oceanic_plate_models/indicator/depth_range.cc Outdated
Comment thread source/world_builder/features/oceanic_plate_models/indicator/depth_range.cc Outdated

@tjhei tjhei left a comment

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.

I am not sure I understand what this does and how this is different than a composition. Can you explain what you are trying to achieve?

{
class ObjectFactory;

class Interface

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.

Document

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Documents are before the "namespace" in this part. I think this seems to be the convention of WB file as in other places.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Added comments before "Interaface"

Comment thread source/gwb-grid/main.cc Outdated
@lhy11009

Copy link
Copy Markdown
Contributor Author

I am not sure I understand what this does and how this is different than a composition. Can you explain what you are trying to achieve?

This is to have a separate indicator field that can indicate, say, a region in ASPECT that I could prescribe the solution of temperature, velocity, and composition from the WorldBuilder.

@lhy11009

Copy link
Copy Markdown
Contributor Author

@lhy11009 : Thank you for the contribution! I just looked at your changes in the features folder and added my comments. I will take another look after I understand your goal more clearly. I have two comments that might help me in this process:

  1. Have you tested your path with multiple indicator models? For example, if you include another indicator model in "second oceanic plate" that only defines indicator for velocity and have some overlap in the geometries of the two, are the indicators for temperature and velocity as what you would expect? I don't fully understand how the operation works in your case.
  2. Since your goal is to identify regions within your wb feature geometries that can then use some prescribed values from ASPECT, would it be possible to achieve this by assigning some nonphysical values at those locations (say, nan) and then checking for them in ASPECT ? I guess nan is not an option because that might trigger several assertions, but you get the idea. My comment is arising from not being able to fully understand how to use this property, so feel free to ignore it if it doesn't make sense.

Here I made this new test with two plate overlapping. The first plate spans 0 - 500 km in x, while the second plate spans 300 - 1000 km in x. So the second plate should replace the first plate in the range of 300 - 500 km. And for the second plate I assigned indicator 2. And the results are listed:

image

Indicator 0
image

Indicator 1
image

Indicator 2
image

Comment thread source/world_builder/features/oceanic_plate_models/indicator/depth_range.cc Outdated
@lhy11009

lhy11009 commented Mar 30, 2026

Copy link
Copy Markdown
Contributor Author

@MFraters, can you take a look at this piece and some of the unresolved conversations before I duplicate it to other features?

@lhy11009

lhy11009 commented Mar 31, 2026

Copy link
Copy Markdown
Contributor Author

As @MFraters recommended, I added "indicator properties" to the parameters and used names of "temperature", "velocity", and "composition" to represent entries in the wb file.
I added a unit-test for this feature.
The two gwb-grid tests show usage cases of this new implementation. There are also leftover questions in conversations as well. Feel free to take a look.

@alarshi Feel free to take a second look. I really appreciate the time you guys spent.

Comment thread include/world_builder/world.h
@coveralls

coveralls commented Mar 31, 2026

Copy link
Copy Markdown

Coverage Report for CI Build 33357243627

Coverage decreased (-0.07%) to 98.235%

Details

  • Coverage decreased (-0.07%) from the base build.
  • Patch coverage: 16 uncovered changes across 5 files (172 of 188 lines covered, 91.49%).
  • No coverage regressions found.

Uncovered Changes

File Changed Covered %
source/world_builder/parameters.cc 56 48 85.71%
source/world_builder/world.cc 18 14 77.78%
source/world_builder/features/oceanic_plate_models/indicator/uniform.cc 44 42 95.45%
source/gwb-grid/main.cc 14 13 92.86%
source/world_builder/types/indicator_property.cc 23 22 95.65%
Total (7 files) 188 172 91.49%

Coverage Regressions

No coverage regressions found.


Coverage Stats

Coverage Status
Relevant Lines: 12124
Covered Lines: 11910
Line Coverage: 98.23%
Coverage Strength: 807384.23 hits per line

💛 - Coveralls

@github-actions

github-actions Bot commented Mar 31, 2026

Copy link
Copy Markdown
Benchmark Main Feature Difference (99.9% CI)
Slab interpolation simple none 1.188 ± 0.011 (s=379) 1.192 ± 0.009 (s=380) +0.1% .. +0.6%
Slab interpolation curved simple none 1.184 ± 0.009 (s=345) 1.191 ± 0.010 (s=415) +0.3% .. +0.7%
Spherical slab interpolation simple none 1.178 ± 0.025 (s=378) 1.176 ± 0.023 (s=389) -0.7% .. +0.3%
Slab interpolation simple curved CMS 1.359 ± 0.009 (s=321) 1.350 ± 0.012 (s=346) -0.9% .. -0.5%
Spherical slab interpolation simple CMS 1.641 ± 0.011 (s=306) 1.634 ± 0.010 (s=246) -0.6% .. -0.2%
Spherical fault interpolation simple none 1.300 ± 0.010 (s=345) 1.292 ± 0.007 (s=352) -0.7% .. -0.4%
Cartesian min max surface 2.758 ± 0.094 (s=155) 2.749 ± 0.094 (s=174) -1.6% .. +0.9%
Spherical min max surface 8.685 ± 0.103 (s=45) 8.580 ± 0.080 (s=62) -1.9% .. -0.5%

template<>
std::vector<unsigned int>
Parameters::get_vector(const std::string &name,
const std::map<unsigned int, Parameters::indicator_property> &indicator_properties)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Related to the last question, this get_vector function is a little bit complex. I tried to model from the unmerged PR and get it to work. But I am not sure whether my implementation is good enough.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I think we can come back to this after #926 is merged.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

#926 is now #934

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Okay, regarding the progress of this PR, my plan is to leave this as it is now to merge this one, then get back to the new function after 934 is merged.

@MFraters MFraters left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think @alarshi make a good point here:

Since your goal is to identify regions within your wb feature geometries that can then use some prescribed values from ASPECT, would it be possible to achieve this by assigning some nonphysical values at those locations (say, nan) and then checking for them in ASPECT ? I guess nan is not an option because that might trigger several assertions, but you get the idea. My comment is arising from not being able to fully understand how to use this property, so feel free to ignore it if it doesn't make sense.

You could also prescribe NaN in the world builder file (I think the json reader can convert that properly). Then ASPECT (or any other program would just need to check whether is is not a NaN. Would this also work for you, or would there be specific things you would not be able to do with that approach?

Other then that I have left a few comments on discussions in the pull request.

Comment thread source/world_builder/features/oceanic_plate_models/indicator/depth_range.cc Outdated
Comment thread source/world_builder/features/oceanic_plate_models/indicator/depth_range.cc Outdated
Comment thread source/world_builder/features/oceanic_plate_models/indicator/interface.cc Outdated
template<>
std::vector<unsigned int>
Parameters::get_vector(const std::string &name,
const std::map<unsigned int, Parameters::indicator_property> &indicator_properties)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

#926 is now #934

@lhy11009

Copy link
Copy Markdown
Contributor Author

@MFraters Related to your comments, I am not sure that setting values to NaN would be the cleanest solution. I am also not quite sure which field we would set to NaN in practice — the temperature field or one of the compositional fields.

If we are looking for an intermediate solution, I keep coming back to a slightly different question: could we assign a region to both composition "a" and composition "b" at the same time?

If that is possible, we could use one compositional field to represent the region's actual composition and another as an indicator field. This would avoid having to encode the distinction through NaN values and might make the intent more explicit.

Do you think this would be possible within the current setup?

@lhy11009
lhy11009 force-pushed the indicator_field branch 2 times, most recently from 2101698 to 1336391 Compare August 26, 2026 19:04
@lhy11009
lhy11009 force-pushed the indicator_field branch 2 times, most recently from 998fd26 to 6dd0bfa Compare August 31, 2026 03:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants