-
Notifications
You must be signed in to change notification settings - Fork 238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inquiry on Near-Neighbor Interpolation for StructuredDataLookup #6122
Comments
Hi @gassmoeller , I hope you are doing well. I have a question regarding StructuredDataLookup. The get_interpolation_point_coordinates method is quite useful for returning coordinates, and I have implemented a near-neighbor search based on that. However, I realized that I also need to access the value of the data directly—in my case, the index of the dominant phase. Currently, it appears that StructuredDataLookup hides the data from users and only provides a "data" object. Specifically, the data[component]->value is defined as an interpolation function for the I-th data column, rather than giving direct access to the data values. Could you advise on how I might be able to retrieve the data directly in this case? |
Could you provide more details on why you need access to the data directly and what you mean by "data"? The design of the class currently hides the data table on purpose, because it was meant to provide an interpolated approximation of that data table at arbitrary coordinates. If you query the value from the StructuredDataLookup class exactly at the pressure/temperature value that is defined in the table you should get exactly the data value that is in the table, why is that not sufficient? |
Okay, I see now. It seems I didn't get the part of "query the value from
the StructuredDataLookup class exactly at the pressure/temperature value".
Then I think this should work fine.
…On Mon, Nov 4, 2024 at 11:11 PM Rene Gassmoeller ***@***.***> wrote:
Could you provide more details on why you need access to the data directly
and what you mean by "data"? The design of the class currently hides the
data table on purpose, because it was meant to provide an interpolated
approximation of that data table at arbitrary coordinates. If you query the
value from the StructuredDataLookup class exactly at the
pressure/temperature value that is defined in the table you should get
exactly the data value that is in the table, why is that not sufficient?
—
Reply to this email directly, view it on GitHub
<#6122 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AG2WMFKIIOCNLK6RV3XH7TLZ7BVQFAVCNFSM6AAAAABRBPDH46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJWGM4TSNRVGA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Ph.D student of Geophysics
Earth & Planetary Sciences Dept., UC Davis
Davis, CA 95616
|
I think this is currently implemented in #6131 and can be closed when that PR is merged. |
Agree, it's very close to be merged, let's just close it here. |
I am currently working on implementing a StructuredDataLookup for determining the most abundant phase under specific (P, T) conditions. Since the most abundant phase is represented as an index (e.g., 0, 1, 2, etc.), interpolating to fractional values like 1.5 is not meaningful. Using linear interpolation could result in blending phase indices, which does not accurately represent the physical system.
Upon reviewing the source code in source/structured_data.cc, I observed that the available interpolation methods—Functions::InterpolatedUniformGridData and Functions::InterpolatedTensorProductGridData—are designed for linear or higher-order interpolation. However, for my application, a near-neighbor interpolation method would be more appropriate.
Would you be able to advise on the most suitable class or approach for implementing near-neighbor interpolation within this framework? Additionally, if existing options are not appropriate, do you suggest any modifications to achieve the desired behavior?
The text was updated successfully, but these errors were encountered: