Enhancement to pointInterpolator

[aprilnovak]

Would the following be accepted as a pull request?

We are using the pointInterpolator, and want to protect ourselves from cases where a user could accidentally call the interpolator out-of-bounds of the mesh. We do not want to rely on console output, which is the only place that Nek reports if any points were outside the mesh. I'd like to propose capturing the counts variable as an output so that we can use it in Cardinal.

Thanks!

[stgeke]

For performance reason I suggest to add an overload for pointInterpolation_t::find returning Linf(distance squared from found mesh point to requested point). Will this work for you or do you really need the different counts (outside, inside, close to boundary)?

[fischer1]

I would think we need to at least know inside vs outside, but "close to boundary" is also important, Because that is generally interpreted as "good enough" ... Even if outside. How much of a performance hit is there?

…

________________________________ From: stgeke ***@***.***> Sent: Tuesday, January 14, 2025 4:37 AM To: Nek5000/nekRS ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [Nek5000/nekRS] Enhancement to `pointInterpolator` (Discussion #612) For performance reason I suggest to add an overload for pointInterpolation_t::find returning Linf(distance squared from found mesh point to requested point). Will this work for you or do you really need the different counts (outside, inside, outside but close to boundary)? — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/Nek5000/nekRS/discussions/612*discussioncomment-11830256__;Iw!!DZ3fjg!7VCyJTX4N3yNFfJ7FhclGT8Q_xwnTl2fvqVh_sFcYgd5YsfA3-5IXaCE4KGmOqiGs_NI94GE1_k-itphcu55fM_1NBs$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ACV35EMT5V5HSKGGYSGHNHD2KTSFJAVCNFSM6AAAAABUSNAY52VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOBTGAZDKNQ__;!!DZ3fjg!7VCyJTX4N3yNFfJ7FhclGT8Q_xwnTl2fvqVh_sFcYgd5YsfA3-5IXaCE4KGmOqiGs_NI94GE1_k-itphcu558OpJpgo$>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[stgeke]

That's why I propose returning the largest distance, allowing the user to determine whether it falls within an acceptable range. The actual counts are usually less interesting.

The cost depends on the number of points and is usually small (<20%). The check will be optional, so if you think the overhead matters you can disable it.

[fischer1]

Thanks Stefan. I would default to having the count, since one can optimize after verifying that all is OK. Sometimes you end up with a huge amount outside of the domain for user reasons, e.g., you didn't understand correctly the domain size or something, or your bcs for particle tracking are not working correctly, etc. So knowing if you have a lot or just one or two outside the domain is quite useful. If there is a control flag then, as a user, I would likely have it verbose for the first hundred steps and then go silent, unless something was wrong. April can better speak to the needs of her current application.

…

________________________________ From: stgeke ***@***.***> Sent: Tuesday, January 14, 2025 6:36 AM To: Nek5000/nekRS ***@***.***> Cc: Fischer, Paul ***@***.***>; Comment ***@***.***> Subject: Re: [Nek5000/nekRS] Enhancement to `pointInterpolator` (Discussion #612) That's why I propose returning the largest distance, allowing the user to determine whether it falls within an acceptable range. The actual counts are usually less interesting. The cost depends on the number of points and is usually small (<20%). The check will be optional, so if you think the overhead matters you can disable it. — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/Nek5000/nekRS/discussions/612*discussioncomment-11831166__;Iw!!DZ3fjg!6kHGBqAG1eqZFWeRneRigNRIce05P-qzgnpGLAr3gZw004YjOZAlCxuOtjrR0mFzRpLTTxVajBWq6C7eudgk5K8h1Ec$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ACV35EKDXZZHR26J37LT2DT2KUADHAVCNFSM6AAAAABUSNAY52VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOBTGEYTMNQ__;!!DZ3fjg!6kHGBqAG1eqZFWeRneRigNRIce05P-qzgnpGLAr3gZw004YjOZAlCxuOtjrR0mFzRpLTTxVajBWq6C7eudgkQejaH4Q$>. You are receiving this because you commented.Message ID: ***@***.***>

[stgeke]

We already print the count statistics to stdout. I guess this discussion is focused on finding a programmatic way to access the counters or explore other methods to verify whether all points have been found.

[stgeke]

May be no changes are required:

• Using pointInterpolator.data() enables the user to check internals (return code, distance norm, ...) of each interpolation point
• Statistics (e.g. total number of failed points etc.) are printed to stdout depending on the verbosity level (can be changed at runtime)

[aprilnovak]

Thanks Stefan and Paul! Yes, the objective is to capture this information programmatically so that we can have MOOSE terminate the simulation if there's points outside the domain (for the reason Paul listed -- we want our users to be aware they probably misunderstand the geometry domain somehow).

I'm proposing we simply return the statistics in the function signature -- I don't think there would be any performance penalty in NekRS, just a signature change?

[stgeke]

Why don't you simply use pointInterpolator.data() and compute the statistics you want?

[aprilnovak]

I wasn't aware of that as an option until this thread, so I will try it.