Nektar++ Solvers can be run in parallel with third party applications and other Nektar++
solvers, where run-time data exchange is enabled by the coupling interface. The interface is
configured in the COUPLING tag as
The coupling type may be any of the types described later in this section, while the name can
be chosen arbitrarily. Inside each coupling block, the send and receive frequencies are defined
by the SendSteps and ReceiveSteps parameters, respectively. Which variables are to be sent
or received is specified by the SendVariables and ReceiveVariables. By default, the send
and receive frequencies is set to zero, which disables the corresponding exchange in
this coupling. An empty SendVariables or ReceiveVariables list has the same
effect.
| Option name | Required | Default | Description |
SendSteps | ✗ | 0 | Frequency (in steps) at which fields are sent. Sending is disabled if set to zero. |
SendVariables | ✗ | <empty> | Comma-separated list of sent variables. Sending is disabled if the list is empty. |
ReceiveSteps | ✗ | 0 | Frequency (in steps) at which fields are received. Receiving is disabled if set to zero. |
ReceiveVariables | ✗ | <empty> | Comma-separated list of received variables. Receiving is disabled if the list is empty. |
This coupling type allows the user to exchange fields at run time by reading from and writing
to files. Besides the basic parameters which define the exchanged variables and the exchange
frequency, the file coupling type requires the SendFileName and ReceiveFunction
parameters to be set. The Coupling name is not used for this type and can be ignored.
SendFileName specifies a file name template to write the field data to. Currently, only .pts
files are supported and the file is only created once fully written, avoiding race conditions
between sender and receiver. Receiving is implemented by evaluating a session function
specified in the ReceiveFunction parameter. The coupling waits for the file given in the
receive function to appear.
| Option name | Required | Default | Description |
SendFileName | (✓) | - | File name where the sent fields should be written to. Required if sending is enabled. Time dependent file names are supported. |
ReceiveFunction | (✓) | - | Function to evaluate to obtain the received fields.Required if receiving is enabled. |
–cwipi and a unique application name, e.g:
CWIPI uses the names of the current application and the coupling to identify two peers
in cosimulation setups. The name of the remote application must be provided by
the RemoteName parameter. Unlike the File-type coupling, a linear interpolation in
time is applied to the received fields if non-unity values are set for ReceiveSteps.
Additional options which define the coupling include SendMethod, the method used to retrieve
the physical values at the locations requested by the remote application. Available options are
NearestNeighbour, Shepard and the default Evaluate. The last option directly evaluates the
expansions using a backward transform, giving superior accuracy at acceptable computational
cost.
When using non-conforming domains, the current application might request values outside of
the computational domain of the remote application. How to handle these not-located
points is specified by the NotLocMethod parameter. When set to keep, the point
value is not altered. With Extrapolate, the nearest neighbor value of the current
application is used. Note that this can be very inefficient when using many MPI
ranks.
| Option name | Required | Default | Description |
RemoteName | ✓ | - | Name of the remote application. |
SendMethod | ✗ | Evaluate | Specifies how to evaluate fields
before
sending. Available options are
|
Oversample | ✗ | 0 | Receive fields at a higher (or lower) number of quadrature points before filtering to avoid aliasing. |
FilterWidth | ✗ | 0 | Apply a spatial filter of a given filter width to the received fields. Disabled when set to zero. |
NotLocMethod | ✗ | keep | Specifies how not located
points
in non-conformal domains are
handled. Possible values are
|