execution sequence of ground
 

Hi,

I try to couple Phoenics with an other kind of CFD code. The coupling is definited using boundary conditions. The values for an inlet are in that sence changing during the computation. The solution I choose is to use ground coding for the implementation aspect of the coupling. My problem is due to a rought comprehension of the ground structure.

I anderstood that the boundary conditions are expressed in terms of XY plan layer. I want to limit the use of the coupling step. So can I be sure to update the inlet values only every time step iteration (not for all z or for all iterations). I think to answer this question I have to better anderstand the execution sequence of the ground subroutine. All ideas are wellcome. Thanks for help.

L. Founier

Re: execution sequence of ground
 

Dear Luc

In PHOENICS, BC are implemented as source terms into the transport equation and, as you had said, are accessible via Ground coding.

I don't understood what you mean with "expressed in terms of XY plan layer". If you have a 3D simulation, and the inlet boundary is at certain XY plane, then you will obviously express your inlet condicions as a general funciotn of X and Y coordinates.

I pressume you had inserted your code into the Group 13 (in ground.f file), and you should know this Group is visited every iteration, for every slab, during the simulation. This makes able to implement implicit source terms. If your boundary condition do not change during the sweep, you don't have to warried about it.

Change the boundary values, according the external code, every time step into the Group 19, and PHOENICS will introduce it into the proper equation when it reads the code from Group 13. It will work if you have properly coded your BC in Group 13.

Let me know more specific info and maybe I will can focus a little bit some help.

Kike

Re: execution sequence of ground
 

Dear Kike,

Thanks for your answer. It help me to be sure of the way phoenics perform it computation. I mean, that the group 13 is visited every iteration and every slab. In fact, this is the first I have to use this group. I 'm testing this coupling startegy (using only the group 13 and a setup of network communications in the main.f). But to give you more details, I only want to be able to modify BC and source terms in run time form an other process. The communication cost can be hight, so I try minimize the communication step.

In pratice the external process is an other CFD code which solve roughtly a large scale problem.

So, thnak's for your help and if you see a better way to do this, I'll always be interested.

Luc.

Re: execution sequence of ground
 

Dear Luc

I will assume you are using MPI to communicate your processes. Nevertheless I think it could be equivalent for PVM or LAM.

You can use mainf.f to spawn, from PHOENICS, all the external process you need and to monitoring the communications, but I recommend you "grex3.f" which is called several times during the execution.

There may be several ways to assign the BC from one external process. If you uses a user defined array (other than F array) then you can implement the reception from any section into Group 19 visited only every time step. The array will be read unchanged every sweep into Group 13 BC, and with the updated values at the begining (or end) of the time step, after processes communication.

It means that, as far as I can see from your mail, the Group 13 is unappropriate for receiving information unless you have a well controlled and syncronius communications between the external process and PHOENICS. In that case you can use the PHOENICS integer variable ISWEEP (and ISLAB or IZ) to control the exact time of MPI transfer and receiving inside Group 13.

In my oppinon, in your case (two individual processes interconnected, I think), it is better to use Group 19 than Group 13 (for MPI_SEND or MPI_RECV). You will save time, even if you use MPI_BARRIER inside it.

I am sorry if I have lost the focus of your first question. Good luck

Kike