Add InterfaceDerivativeMatrix for conforming meshes by PaulineVidal · Pull Request #498 · gyselax/gyselalibxx

PaulineVidal · 2026-01-12T15:01:02Z

Operator to compute the coupled interface derivatives along a direction with the approximation formula.

Waiting for #499, better to wait for #500.

Please complete the checklist to ensure that all tasks are completed before marking your pull request as ready for review.

All Submissions

Have you ensured that all lines changed in this PR are justified by a comment found in the description ?
Have you updated the CHANGELOG.md ?
Have you linked any issues that should be closed when this PR is merged (using closing keywords) ?
Have you checked that the AUTHORS file is up to date ?
Have you checked that the copyright information in the LICENCE file is up to date (including dates) ?
Do you follow the conventions specified in our coding standards ?

New Feature Submissions

Have you added tests for the new functionalities ?
Have you documented the new functionalities:
- API documentation describing the available methods, when each should be used and how to use them ?
- User-friendly documentation in README files (which may link to the API documentation).
- If the new functionality is non-trivial to use, provide a tutorial or example ? (optional)

Changes to Existing Features

Have you checked that existing tests cover all code after the changes ?
Have you checked that existing tests are still passing ?
Have you checked that the existing documentation is still accurate (API and README files) ?

Changes to the CI

Have you made the same changes to both the GitHub CI and the GitLab CI (for the private fork) ?

Add `SingleInterfaceDerivativesCalculator` operator and tests to compute an interface derivative with the different cases: - Interpolation type: Hermite boundary conditions ; additional interpolation points - Mesh type: uniform ; non-uniform - Formula type: exact ; approximation. - Patch connections: E|E ; E|W ; W|E ; W|W ; E|S See merge request gysela-developpers/gyselalibxx!869 -------------------------------------------- Co-authored-by: Emily Bourne <emily.bourne@epfl.ch>

Add a `SingleInterfaceDerivativeCalculatorCollection` to store a collection of `SingleInterfaceDerivativeCalculator`. Change the template parameters of `SingleInterfaceDerivativeCalculator`. The boundary conditions are now inputs in the constructor. Move useful operators in the test files `single_interface_derivatives_calculator_test.cpp` in a `interface_derivatives_utils.hpp` file. See merge request gysela-developpers/gyselalibxx!874 -------------------------------------------- Co-authored-by: Pauline Vidal <142578924+PaulineVidal@users.noreply.github.com> Co-authored-by: Emily Bourne <emily.bourne@epfl.ch>

Add `SingleInterfaceDerivativesCalculator` operator and tests to compute an interface derivative with the different cases: - Interpolation type: Hermite boundary conditions ; additional interpolation points - Mesh type: uniform ; non-uniform - Formula type: exact ; approximation. - Patch connections: E|E ; E|W ; W|E ; W|W ; E|S See merge request gysela-developpers/gyselalibxx!869 -------------------------------------------- Co-authored-by: Emily Bourne <emily.bourne@epfl.ch>

Add a `SingleInterfaceDerivativeCalculatorCollection` to store a collection of `SingleInterfaceDerivativeCalculator`. Change the template parameters of `SingleInterfaceDerivativeCalculator`. The boundary conditions are now inputs in the constructor. Move useful operators in the test files `single_interface_derivatives_calculator_test.cpp` in a `interface_derivatives_utils.hpp` file. See merge request gysela-developpers/gyselalibxx!874 -------------------------------------------- Co-authored-by: Pauline Vidal <142578924+PaulineVidal@users.noreply.github.com> Co-authored-by: Emily Bourne <emily.bourne@epfl.ch>

…ce_approx_derivative_matrix

Add `SingleInterfaceDerivativesCalculator` operator and tests to compute an interface derivative with the different cases: - Interpolation type: Hermite boundary conditions ; additional interpolation points - Mesh type: uniform ; non-uniform - Formula type: exact ; approximation. - Patch connections: E|E ; E|W ; W|E ; W|W ; E|S See merge request gysela-developpers/gyselalibxx!869 -------------------------------------------- Co-authored-by: Emily Bourne <emily.bourne@epfl.ch>

Add a `SingleInterfaceDerivativeCalculatorCollection` to store a collection of `SingleInterfaceDerivativeCalculator`. Change the template parameters of `SingleInterfaceDerivativeCalculator`. The boundary conditions are now inputs in the constructor. Move useful operators in the test files `single_interface_derivatives_calculator_test.cpp` in a `interface_derivatives_utils.hpp` file. See merge request gysela-developpers/gyselalibxx!874 -------------------------------------------- Co-authored-by: Pauline Vidal <142578924+PaulineVidal@users.noreply.github.com> Co-authored-by: Emily Bourne <emily.bourne@epfl.ch>

…ce_approx_derivative_matrix

Update the `main_pvidal` branch after merge including DDC changes. See merge request gysela-developpers/gyselalibxx!882 --------------------------------------------

…trix

…rox_derivative_matrix

github-actions · 2026-01-12T15:12:16Z

This PR is failing tests so it has been put back into draft. Please remove the draft status when the tests pass.

PaulineVidal · 2026-01-13T10:59:28Z

+        // Update the derivatives.
+        // Change the sign of the derivative on Patch1, if the grid directions desagreed.
+        function_and_derivs_1(idx_slice_deriv_1, idx_slice_1) = interface_deriv * sign_1;
+        function_and_derivs_2(idx_slice_deriv_2, idx_slice_2) = interface_deriv * sign_2;


@EmilyBourne
There is these CI test errors:

Variable 'function_and_derivs_1(idx_slice_deriv_1,idx_slice_1)' is assigned a value that is never used. [unreadVariable]

see https://github.com/gyselax/gyselalibxx/actions/runs/20954118794/job/60214406603?pr=498

However, these lines modify the values pointed by the Field given as input.

…rox_derivative_matrix

EmilyBourne · 2026-01-20T07:58:59Z

+template <class DimOut, class DimIn>
+std::vector<Coord<DimOut>> const convert_dim(std::vector<Coord<DimIn>> const& input_vec)
+{


Doesn't this function do the same thing as fill_in?

It is true they are similar 🤔
Actually I use fill_in to fill in the vectors of global coordinates. The idea is more like an .append(). I use it in the test files to fill in the global vectors with values of the different patches.
E.g.

fill_in(global_points, patch1_points); fill_in(global_points, patch2_points); fill_in(global_points, patch3_points);

Which in python could be equivalent to

global_points = patch1_points global_points.append(patch2_points) global_points.append(patch3_points)

It also convert the points to from local coordinates to global coordinates.
Do you think I should rename the operator? I choose fill_in with the idea of filling in a bottle of water.

On the other hand, convert_dim cannot be apply to .append() the vectors.
As it directly returns a vector, I use it to avoid to instantiate a vector.
E.g. (see interface_derivative_matrix_Greville_periodic_test.cpp)

// Patch 2 ............................................................................... ddc::init_discrete_space<BSplinesX<2>>(break_points_x258); ddc::init_discrete_space<BSplinesY<2>>(convert_dim<Y<2>, Y<1>>(break_points_y123)); ddc::init_discrete_space<GridX<2>>(interpolation_points_x258); ddc::init_discrete_space<GridY<2>>(convert_dim<Y<2>, Y<1>>(interpolation_points_y123)); // Patch 3 ............................................................................... ddc::init_discrete_space<BSplinesX<3>>(break_points_x369); ddc::init_discrete_space<BSplinesY<3>>(convert_dim<Y<3>, Y<1>>(break_points_y123)); ddc::init_discrete_space<GridX<3>>(interpolation_points_x369); ddc::init_discrete_space<GridY<3>>(convert_dim<Y<3>, Y<1>>(interpolation_points_y123)); // ...

EmilyBourne · 2026-02-04T10:30:35Z

+        // The patches are conforming between each other.
+        std::vector<Coord<X<1>>> break_points_x147
+                = build_random_non_uniform_break_points(x1_min, x1_max, x1_ncells);
+        std::vector<Coord<X<2>>> break_points_x258
+                = build_random_non_uniform_break_points(x2_min, x2_max, x2_ncells);
+        std::vector<Coord<X<3>>> break_points_x369
+                = build_random_non_uniform_break_points(x3_min, x3_max, x3_ncells);
+
+        std::vector<Coord<Y<1>>> break_points_y123
+                = build_random_non_uniform_break_points(y1_min, y1_max, y1_ncells);
+        std::vector<Coord<Y<4>>> break_points_y456
+                = build_random_non_uniform_break_points(y4_min, y4_max, y4_ncells);
+        std::vector<Coord<Y<7>>> break_points_y789
+                = build_random_non_uniform_break_points(y7_min, y7_max, y7_ncells);


If the patches use similar coordinate systems is it possible to have:

using Patch3 = Patch<GridX<3>, GridY<1>, BSplinesX<3>, BSplinesY<1>>

?

In the source file, there is

// Sequence of 1D grids in the direction of Grid1D over the patches. using Grid1DSeq = collect_grids_on_dim_t< find_patch_t<Grid1D, all_patches>, Grid1D, interface_sorted_collection>;

I am not sure about the result with all_patches = (Patch1, Patch2, ..., Patch9) and Grid1D = GridY<1>.
Does it work?

Maybe it could work. I am not sure. To be tested.

I think we should check this at some point

EmilyBourne · 2026-02-09T10:01:45Z

+        return get_function_coefficients_with_sign(function_1, function_2, 1);
+    }
+
+    /**
+     * @brief Get the linear combination of the function values (c).
+     * See @ref get_function_coefficients.
+     * @param function_1 Function values at the interpolation points on patch 1. 
+     * @param function_2 Function values at the interpolation points on patch 2. 
+     * @return the linear combination of the function values (c).
+     */
+    template <class Layout1, class Layout2>
+    inline double get_function_coefficients(
+            DConstField<IdxRange1DPerp_2, Kokkos::HostSpace, Layout2> const& function_2,
+            DConstField<IdxRange1DPerp_1, Kokkos::HostSpace, Layout1> const& function_1) const
+    {
+        return get_function_coefficients_with_sign(function_1, function_2, 1);


Why is sign hard-coded to 1 in these 2 functions?

To get an interface derivatives, I compute
$\partial_x f = \sum_{k \text{ on Patch1}} \omega_k f_k + \sum_{k \text{ on Patch2}} \omega_k f_k $

To get an interface cross-derivatives, I compute
$\partial_{xy} f = \sum_{k \text{ on Patch1}} \omega_k \partial_y f_k + \sum_{k \text{ on Patch2}} \omega_k \partial_y f_k $

The computed derivatives correspond to the derivatives of an equivalent global spline on the two patches.
In the case of cross-derivatives, we have to be careful that the sign of the $\partial_y f$ agree and correspond to a same equivalent global spline.
For example,

^^^^^^^^|^^^^^^^^ Patch1 Patch2

can be represented by

^^^^^^^^^^^^^^^^ Global

However, we have a problem with

^^^^^^^^|vvvvvvvv Patch1 Patch2

because GridY1 and GridY2 do not have the same orientation. By flipping the sign of the derivative on Patch2, this correspond to orientate GridY2 to the same orientation of GridY1 and bring us to the situation1 the problem.

Of course, the change of sign is not needed for the computation of the first derivative, because the function values are not oriented.

Tell me if this part is not enough https://github.com/gyselax/gyselalibxx/tree/pvidal_interface_approx_derivative_matrix/src/multipatch/interface_derivatives

Of course, the change of sign is not needed for the computation of the first derivative, because the function values are not oriented.

Do you mean 0-th derivative?

The first derivatives are computed from the "0th derivatives" = function values -> no need of sign flip.
The cross-derivatives are computed from the 1rst derivatives -> need to flip sign if the grid orientations desagree.

Maybe the name of the operator is confusing?

The exact value of the derivative (of a global spline) is
deriv = a x previous_deriv + b x next_deriv + c
with
$c = \sum_{k \text{ on Patch1}} \omega_k f_k + \sum_{k \text{ on Patch2}} \omega_k f_k $
or
$c \sum_{k \text{ on Patch1}} \omega_k \partial_y f_k + \sum_{k \text{ on Patch2}} \omega_k \partial_y f_k $

The coefficient c I called it get_function_coefficient in the first case and get_derivatives_coefficient in the second case, because it is a coefficient computed from the function values or the derivatives in the second case.

EmilyBourne · 2026-02-09T13:22:07Z

+using Interface_1_2 = Interface<EastEdge<1>, WestEdge<2>, true>;
+using Interface_2_3 = Interface<EastEdge<2>, SouthEdge<3>, false>;
+
+using OutsideInterface1 = Interface<OutsideEdge, WestEdge<1>, true>;
+using OutsideInterface3 = Interface<NorthEdge<3>, OutsideEdge, true>;


I don't understand why you have:
using Interface_2_3 = Interface<EastEdge<2>, SouthEdge<3>, false>;

Doesn't this interface connect $x_2$ to $y_3$? Those grids are aligned in the same direction

The boolean refers to the orientation of the parallel grid to the interface.
Here, $y_2$ and $x_3$ dont have the same orientation.

I added a comment here: 81f26af

Reorganise the InterfaceDerivative tests in order to: - reduce code duplication (reduce overall code quantity) - group decisions (i.e. all choices related to a given patch configuration should be found together)

…_matrix_Greville_periodic_test.cpp

…rox_derivative_matrix

EmilyBourne · 2026-02-18T08:16:41Z

Is this PR ready for review again?

PaulineVidal and others added 16 commits December 10, 2025 11:30

Add InterfaceDerivativeMatrix

8d16eee

get some files from the pvidal_interface_derivative_matrix branch

34a29be

modify doc

72c3ac2

Merge remote-tracking branch 'origin/main_pvidal' into pvidal_interfa…

727f41f

…ce_approx_derivative_matrix

Add the Hermite test

c0725be

Remove BoundCond in templatex

e431b1a

Merge remote-tracking branch 'origin/main_pvidal' into pvidal_interfa…

9cb0ad3

…ce_approx_derivative_matrix

Update after DDC merge + add greville test

26ca15b

Update the main_pvidal after DDC merge

4c52b27

Update the `main_pvidal` branch after merge including DDC changes. See merge request gysela-developpers/gyselalibxx!882 --------------------------------------------

Change author and changelog files.

2c7cc38

PaulineVidal changed the title ~~Add InterfaceExactDerivativeMatrix~~ Add InterfaceDerivativeMatrix Jan 12, 2026

PaulineVidal added 2 commits January 12, 2026 16:05

Merge branch 'main_pvidal' into pvidal_interface_approx_derivative_ma…

2b00b59

…trix

Merge remote-tracking branch 'origin/devel' into pvidal_interface_app…

abe5aa0

…rox_derivative_matrix

github-actions Bot marked this pull request as draft January 12, 2026 15:12

PaulineVidal added 7 commits January 13, 2026 10:58

Fix error + update readme

2301846

readme + small changes on function initialisation

3d3d313

ci readme

bd1f761

fix typo

75f6ed0

explicit constructor

61b967f

Ci markdown

f44a5bb

CI Test

77b23ca

PaulineVidal commented Jan 13, 2026

View reviewed changes

Merge remote-tracking branch 'origin/devel' into pvidal_interface_app…

5250036

…rox_derivative_matrix

github-actions Bot marked this pull request as draft January 19, 2026 16:44

github-actions Bot added the Ready to review Label to be automatically added to a PR when it is ready to be reviewed label Jan 19, 2026

EmilyBourne reviewed Jan 20, 2026

View reviewed changes

Comment thread tests/multipatch/interface_derivatives/interface_derivative_matrix_Hermite_test.cpp Outdated

PaulineVidal added 8 commits January 20, 2026 09:09

removed added space in readme

45e4ee2

Fix English in interface_derivatives_matrix.hpp and README

4154f9e

Comments on src/**/README

0e97227

remove destructor

b5c54d3

Give more details about C_trunc in the documentation of the class

37ad8d8

CI markdown

753a30a

remove unused include

7160861

remove unused include

89f0a49

EmilyBourne reviewed Jan 21, 2026

View reviewed changes

Comment thread tests/multipatch/interface_derivatives/interface_derivative_matrix_Hermite_test.cpp Outdated

EmilyBourne reviewed Jan 21, 2026

View reviewed changes

Comment thread tests/multipatch/interface_derivatives/interface_derivative_matrix_Hermite_test.cpp Outdated

PaulineVidal and others added 2 commits January 21, 2026 09:30

Fix figures in readme

91fdf07

Merge branch 'devel' into pvidal_interface_approx_derivative_matrix

44bfa31

EmilyBourne reviewed Feb 4, 2026

View reviewed changes

Comment thread tests/multipatch/interface_derivatives/interface_derivatives_matrix_test_utils.hpp Outdated

EmilyBourne reviewed Feb 4, 2026

View reviewed changes

Comment thread tests/multipatch/interface_derivatives/interface_derivative_matrix_Greville_periodic_test.cpp Outdated

Merge branch 'devel' into pvidal_interface_approx_derivative_matrix

d9e78c0

EmilyBourne reviewed Feb 9, 2026

View reviewed changes

EmilyBourne removed the Ready to review Label to be automatically added to a PR when it is ready to be reviewed label Feb 16, 2026

EmilyBourne and others added 3 commits February 17, 2026 11:31

Clean InterfaceDerivative tests (#504)

3ee9a37

Reorganise the InterfaceDerivative tests in order to: - reduce code duplication (reduce overall code quantity) - group decisions (i.e. all choices related to a given patch configuration should be found together)

fix error tests/multipatch/interface_derivatives/interface_derivative…

af48845

…_matrix_Greville_periodic_test.cpp

Merge remote-tracking branch 'origin/devel' into pvidal_interface_app…

fbc50aa

…rox_derivative_matrix

PaulineVidal added 3 commits February 18, 2026 09:16

fix error interpolation points

67c497f

499 was merged

6269c0a

add comment for the boolean in the interfaces

81f26af

Uh oh!

Conversation

PaulineVidal commented Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

All Submissions

New Feature Submissions

Changes to Existing Features

Changes to the CI

Uh oh!

github-actions Bot commented Jan 12, 2026

Uh oh!

PaulineVidal Jan 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PaulineVidal Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PaulineVidal Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PaulineVidal Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PaulineVidal Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

EmilyBourne commented Feb 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

PaulineVidal commented Jan 12, 2026 •

edited

Loading

PaulineVidal Jan 13, 2026 •

edited

Loading

PaulineVidal Feb 4, 2026 •

edited

Loading

PaulineVidal Feb 9, 2026 •

edited

Loading

PaulineVidal Feb 9, 2026 •

edited

Loading

PaulineVidal Feb 9, 2026 •

edited

Loading