I'm wondering about the lines:
! For a specific face to face coupling, geometric assumptions are made
if (ifaccp.eq.1) then....
That are found in csc2cl and cscpfb. Does the specific face-to-face coupling imply that neighbouring cells either side of a coupled boundary essentially contain the same common face?
I am testing two coupled meshes where I have such a face-to-face coupling but ifaccp = 0 and the pressure is non-continuous as I have previously discussed. However, if I manually change ifaccp = 1 the pressure continuity appears to be improving over the interface. I'm still testing a lot of different variables but if someone could let me know that I have the right understanding of the variable iffacp it would be great.
Thanks,
James
Face-to-face coupling (ifaccp)
Forum rules
Please read the forum usage recommendations before posting.
Please read the forum usage recommendations before posting.
-
James McNaughton
Re: Face-to-face coupling (ifaccp)
For anyone interested I have found an answer in the code. ifaccp = 1 if a rotational vector (omegax,y,z) is specified in usini1, and zero otherwise.
-
David Monfort
Re: Face-to-face coupling (ifaccp)
Hi James,
Sorry for answering only now...
As you found out, ifaccp is an indicator of coupling to domains with meshes that have "corresponding faces" (not necessarily conforming but at least nearly coplanar). This is only activated when dealing with rotor/stator interaction, and thus when the code knows that the rotation vetor has been set for one of the two domains; nonetheless, you can enforce it in the usini1.f90 subroutine.
When set to 0, this variable activates another set of interpolation formulae between domains, that can leads to good results for velocity and scalars but sometimes very "awkward" results for the pressure (due to a Neumann approach). This has not been validated and must be used with cautious ;)
David
Sorry for answering only now...
As you found out, ifaccp is an indicator of coupling to domains with meshes that have "corresponding faces" (not necessarily conforming but at least nearly coplanar). This is only activated when dealing with rotor/stator interaction, and thus when the code knows that the rotation vetor has been set for one of the two domains; nonetheless, you can enforce it in the usini1.f90 subroutine.
When set to 0, this variable activates another set of interpolation formulae between domains, that can leads to good results for velocity and scalars but sometimes very "awkward" results for the pressure (due to a Neumann approach). This has not been validated and must be used with cautious ;)
David
-
James McNaughton
Re: Face-to-face coupling (ifaccp)
Hi David,
I see now that I have started out with what I thought to be a simpler (stationary) problem to lead up to the rotating case when in fact the methods are different and so my path has been longer than required - a shame but I have learnt a lot. Now I understand the two instance method better I hope to make some good progress.
Do you mean that only the Neumann BC approach in invalidated or in fact the whole unsteady option?
Thanks,
James
I see now that I have started out with what I thought to be a simpler (stationary) problem to lead up to the rotating case when in fact the methods are different and so my path has been longer than required - a shame but I have learnt a lot. Now I understand the two instance method better I hope to make some good progress.
Do you mean that only the Neumann BC approach in invalidated or in fact the whole unsteady option?
Thanks,
James
-
David Monfort
Re: Face-to-face coupling (ifaccp)
Basically, there are two different cases you want to handle when coupling two domains:
- The two domains never overlap (like in the rotor/stator interaction, or at least this is what we assume). Then, we try to mimic what is done for calculating fluxes at the interior faces. Of course, this is far from being perfect because the coupling is done at a boundary-condition level (sort of explicit) but it leads to good properties of flux conservation.
- The two domains may overlap. Then, we cannot make anymore some assumptions on the geometry and applying the same interpolation as in the previous case may lead to instabilities. That's why the interpolation approach is a bit different.
Finally, the Neumann "issue" is (nearly) orthogonal to the interpolation "issue". When defining the pressure boundary conditions at the interface, we may want to preserve the continuity of the pressure value (Dirichlet) or of the pressure gradient (Neumann).
In the 2.0 version, only the first interpolation (face-to-face coupling) with a Dirichlet condition for the pressure has been validated, for rotor/stator interaction.
David
- The two domains never overlap (like in the rotor/stator interaction, or at least this is what we assume). Then, we try to mimic what is done for calculating fluxes at the interior faces. Of course, this is far from being perfect because the coupling is done at a boundary-condition level (sort of explicit) but it leads to good properties of flux conservation.
- The two domains may overlap. Then, we cannot make anymore some assumptions on the geometry and applying the same interpolation as in the previous case may lead to instabilities. That's why the interpolation approach is a bit different.
Finally, the Neumann "issue" is (nearly) orthogonal to the interpolation "issue". When defining the pressure boundary conditions at the interface, we may want to preserve the continuity of the pressure value (Dirichlet) or of the pressure gradient (Neumann).
In the 2.0 version, only the first interpolation (face-to-face coupling) with a Dirichlet condition for the pressure has been validated, for rotor/stator interaction.
David