******************* This email from originates from outside Imperial. Do not click on links and attachments unless you recognise the sender. If you trust the sender, add them to your safe senders list https://spam.ic.ac.uk/SpamConsole/Senders.aspx to disable email stamping for this address. ******************* Hi Nitish, Great to hear it works for you, i will add the note to the userguide then. Regarding the implementation: The Coupling writes its received data directly into the m_Forcing array. Unfortunately, the Upate method in ForcingBody.cpp would allocate a new array each time step. By using FIELDFORCETIMEFCN, the m_hasTimeFcnScaling flag is set to true and Update is called only once during initialization (which is fine), so the arrays stay the same. The condition with the "x y z t" does not check the expression of the CouplingSource function, but its variables, which are set elsewhere in the code and cannot be altered by the user IIRC. So that has nothing to do with the Coupling. Cheers, Kilian Am 14.01.20 um 07:03 schrieb Nitish Arya:

Dear Kilian,

I looked into the code and found that when no value is provided to an expression, it adds "x y z t" to it. In the ForcingBody.cpp the coupling force is read if there is no value (or the other way round, I am still confused)  provided for the CouplingSource function. But the following worked for me.

     <FUNCTION NAME="CouplingSource">        <E VAR="p,u,v,w" VALUE ="  "/>      </FUNCTION>     </CONDITIONS>     <FORCING>       <FORCE TYPE="Field">               <FIELDFORCE> CouplingSource <FIELDFORCE/>               <FIELDFORCETIMEFCN> 1.0 </FIELDFORCETIMEFCN>       </FORCE>    </FORCING>

I am able to read the source terms as well as the base fields now.

regards, Nitish

On Tue, 14 Jan, 2020, 1:24 AM Kilian Lackhove, <kilian@lackhove.de <mailto:kilian@lackhove.de>> wrote:

Hi Nitish,

i am glad to hear you got the setup working. Regarding the forcing, you need to set

<FIELDFORCETIMEFCN> 1.0 </FIELDFORCETIMEFCN>

(see e.g. solvers/DummySolver/Tests/Dummy_3DCubeCwipi_0.xml for an example)

This is a workaround for an incompatibility between the way the forcing is implemented and how the coupling works. Let me know if it worked for you so i can add this piece if info to the userguide.

Cheers,

Kilian

Am 09.01.20 um 16:16 schrieb Nitish Arya: > Dear Kilian, > > Thank you very much for your suggestion. The cwipi functionality in > the new release really solved my problem. I also successfully compiled > the openfoam interface [3] with the acoustic solver in nektar. The > reception of base fields (u0,v0,w0) is absolutely fine. However, when > I tried receiving the source terms (F_0_p, F_0_u, F_0_v, F_0_w), the > corresponding fields are not reflected in nektar. The source terms are > zero everywhere (since they were initialized to zero in the > configuration file). This could mean that after the transfer they are > being modified to the value in the configuration file. Am I missing > something? > > I have also attached the conditions file in the mail. > > > > regards, > Nitish > >