How to map a single parameter to multiple tidal boundary points in OpenDA (Delft3D)?

[zwj0729]

Description

I am using OpenDA to calibrate a Delft3D model and encountered an issue related to parameter mapping for tidal boundary conditions.

In my setup, I intended to optimize a total of six parameters:

• roughness-u
• roughness-v
• M2 amplitude (global)
• M2 phase (global)
• S2 amplitude (global)
• S2 phase (global)

In D3DStochModel.xml, only these six parameters are defined.

For the tidal boundary, I have 10 boundary points. In D3DModel.xml, I included all boundary points and their corresponding M2 and S2 amplitude and phase entries. However, these entries share the same vector IDs (e.g., "M2.Amplitude", "M2.Phase", etc.), because my intention was to apply a global adjustment (i.e., one parameter affecting all boundary points).

Issue

During calibration, OpenDA only updates the first boundary point (e.g., tide_805_359). The other boundary points remain unchanged, even though they are defined in the configuration.

This suggests that using identical vector IDs for multiple elements may not create a one-to-many mapping as expected.

Questions

1. Does OpenDA support mapping a single parameter (e.g., "M2.Amplitude") to multiple boundary elements simultaneously?
2. If yes, what is the correct way to define such a one-to-many mapping in D3DModel.xml / D3DStochModel.xml?
3. What is the recommended approach to implement a global amplitude/phase correction across multiple tidal boundary points?

Expected Behavior

A single parameter (e.g., M2 amplitude scaling) should be able to update all boundary points consistently.

Actual Behavior

Only the first boundary point is updated, while others remain unchanged.

Any suggestions or best practices would be greatly appreciated. I am happy to provide configuration files if needed.

Thank you!

D3DModel.xml
D3DStochModel.xml
D3DWrapper.xml

[erikpelgrim]

Hi zwj0729,

unfortunately the nl.deltares.openda.models.d3dflow.D3dAstroComponentFiles data object creates separate exchange items with unique id's for all boundaries. Exchange items can not be merged and there can not be multiple exchange items used with the same id. That means for your case "mapping a single parameter (e.g., "M2.Amplitude") to multiple boundary elements simultaneously" is not possible.

But if you are able to develop in Java and since OpenDA is open source, there is the option of adding your own code and building your own version. But that can be quite challenging ;-)

Regards,
Erik

[zwj0729]

Hi Erik, Thank you very much for your clear explanation — that helps me understand the limitation much better. In my case, the east open boundary is divided into nine segments, involving a total of 10 boundary points. If I treat each point independently and optimize both amplitude and phase for M2 and S2, this results in: 10 points × 2 constituents × (amplitude + phase) = 40 parameters for the boundary plus 2 parameters for roughness (roughness-u and roughness-v) So in total, there are 42 parameters. I did try this full-parameter setup, but the optimization performance was not good. I suspect that the parameter space is too large and that there may be strong interactions between boundary parameters and bottom roughness, making the calibration unstable. This is why I was trying to reduce the dimensionality by using a smaller number of “global” parameters for the boundary. Regarding your suggestion: while modifying OpenDA in Java is theoretically possible, I’m afraid that my programming experience is quite limited. I mainly use OpenDA as a user and do not have a deep understanding of its internal implementation, so developing a custom solution in Java would be very difficult for me in the short term. Given this situation, I would like to ask for your advice: Do you think my current boundary parameterization (10 independent boundary points) is too detailed for calibration purposes? Is there any recommended way to reduce the number of boundary parameters? Is there standard to divide the open boundary? Are there common practices in Delft3D/OpenDA applications for calibrating tidal boundary conditions together with bottom roughness? Have you encountered similar issues (e.g., too many boundary parameters leading to poor calibration performance), and how were they typically handled? Any suggestions or best practices would be greatly appreciated. Thank you again for your help! Best regards, Wenjun Original From:Erik Pelgrim ***@***.***> Sent Time:Mar 27, 2026 17:08 To:OpenDA-Association/OpenDA ***@***.***> Cc:zwj0729 ***@***.***>, Author ***@***.***> Subject:Re: [OpenDA-Association/OpenDA] How to map a single parameter to multiple tidal boundary points in OpenDA (Delft3D)? (Issue #476) erikpelgrim left a comment (OpenDA-Association/OpenDA#476) Hi zwj0729, unfortunately the nl.deltares.openda.models.d3dflow.D3dAstroComponentFiles data object creates separate exchange items with unique id's for all boundaries. Exchange items can not be merged and there can not be multiple exchange items used with the same id. That means for your case "mapping a single parameter (e.g., "M2.Amplitude") to multiple boundary elements simultaneously" is not possible. But if you are able to develop in Java and since OpenDA is open source, there is the option of adding your own code and building your own version. But that can be quite challenging ;-) Regards, Erik — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[erikpelgrim]

Hi Wenjun,

I am not an expert on calibration, but I from my practical experience from other applications you can try

• calibrating less boundaries at a time and use the results for those boundaries as constants for a next setup where you calibrate other boundaries.
• in case you use the https://docs.openda.org/en/latest/Quadratic_cost_function.html in your Algorithm.xml you can try weakParameterConstraint="true" this will increase the cost for parameters when their values are changed more, this can keep parameter values closer together.

If this is not sufficient perhaps one of my colleagues has other suggestions.

Regards,
Erik

[nilsvanvelzen]

The number of parameters is likely too much unless you have many spatial divided measurements for your model.
Question you have to ask is whether the impact of individual parameters can be distinguished from each other in the measurement data.

The trick is not to calibrate 42 parameters but introduce parameters that add an offset of apply a factor to a group of this 42 parameters. This is should be possible in the black box wrapper since it is used to calibrate bottom roughness (parameter on each grid cell) where a single parameter is calibrated that influences a large number of parameters in the model (spatial blocks in the model). This is done in the model wrapper and not in the optimiser. @erikpelgrim with bottom roughness calibration in mind, are you able to find some example xml to show how to configure this? I do not think it is present in one of the example models in OpenDA (at least I have to search for it)

[erikpelgrim]

Ah yes, that would be way to do it.

For Wenjun that would mean in D3DStochModel.xml something like:

    <regularisationConstant scale="1">
      <stdDev value="0.05" transformation="identity"/>
      <vector id="tide_805_359.M2.Amplitude"/>
      <vector id="tide_805_351.M2.Amplitude"/>
    </regularisationConstant>

Instead of

    <regularisationConstant scale="1">
      <stdDev value="0.05" transformation="identity"/>
      <vector id="M2.Amplitude"/>
    </regularisationConstant>

And then not renaming the vector id's in D3DModel.xml, or at least not making them all te same.

[zwj0729]

Thank you very much for your suggestion, I will try this. I also have one more question regarding phase parameters. Since phase is a cyclic variable, I am wondering how it should be constrained during calibration so that it remains within one cycle (for example, 0–360° or -180° to 180°), instead of increasing to several hundred degrees or decreasing to negative several hundred degrees. In my current setup, I use the following setting for phase parameters: <regularisationConstant scale="1"> <stdDev value="10" transformation="identity"/> <vector id="S2.Phase"/> </regularisationConstant> but I am not sure whether this is appropriate. Could you please let me know how phase parameters are usually handled in OpenDA / Delft3D calibration?

[nilsvanvelzen]

I do not think is will walk away in a well posed optimisation problem. What I do advice, as a start to select the week constrained optimisation mode. This will add a penalty for the amount of change of a parameter related to the initial value at the start.

Other advantage is that with will make you object function more convex. The standard deviation of the uncertainty of your parameters is used to weight the error for "walking away".

Note calibration is an art. First try to get is (a bit) to work. Investigate the results (*) after an optimisation of a couple DUD iterations, make changes to you setup and continue.

(*) note when the differences between model and measurements are not primarily caused by the parameters you have provided than things do not work out as you hoped for. Then it is up to de modeller to see which set of parameters need to be used.

Note2: If you can experiment first a bit with less parameters ans shorted model runtime, that I advise you to do see. Again it is an art, and you definitely not work (in the way you hope) the first time.