[mlatour]

Hi everyone,

What I am currently trying to do is run a very simple multi-zone simulation of a passage with Euler walls at the top and bottom (see attachment). It’s a compressible Euler simulation with horizontal flow at the inlet at M=0.4. My config for the boundaries are as follows:

% -------------------- BOUNDARY CONDITION DEFINITION --------------------------%
% Euler wall boundary marker(s) (NONE = no marker)
MARKER_EULER= ( wall1_1, wall1_2, wall1_3 )
%
% Zone interface boundary marker(s) (NONE = no marker)
MARKER_INTERFACE= ( outflow_1, inflow_2, outflow_2, inflow_3 )
%
% Inlet boundary type (TOTAL_CONDITIONS, MASS_FLOW)
INLET_TYPE= TOTAL_CONDITIONS
%
% Inlet boundary marker(s) with the following formats (NONE = no marker)
% Total Conditions: (inlet marker, total temp, total pressure, flow_direction_x,
% flow_direction_y, flow_direction_z, ... ) where flow_direction is
% a unit vector.
MARKER_INLET= ( inflow_1, 297.4, 113134.0, 1.0, 0.0, 0.0 )
%
% Outlet boundary marker(s) (NONE = no marker)
% Compressible: ( outlet marker, back pressure (static thermodynamic), ... )
MARKER_OUTLET= ( outflow_3, 101325.0 )
%
% Interface (s) definition, identifies the surface shared by
% two different zones. The interface is defined by listing pairs of
% markers (one from each zone connected by the interface)
% Example:
% Given an arbitrary number of zones (A, B, C, ...)
% A and B share a surface, interface 1
% A and C share a surface, interface 2
% Format: ( marker_A_on_interface_1, marker_B_on_interface_1,
% marker_A_on_interface_2, marker_C_on_interface_2, ... )
%
MARKER_ZONE_INTERFACE= ( outflow_1, inflow_2, outflow_2, inflow_3 )
%
% Specifies the interface (s)
% The kind of interface is defined by listing pairs of markers (one from each
% zone connected by the interface)
% Example:
% Given an arbitrary number of zones (A, B, C, ...)
% A and B share a surface, interface 1
% A and C share a surface, interface 2
% Format: ( marker_A_on_interface_1, marker_B_on_interface_1,
% marker_A_on_interface_2, marker_C_on_interface_2, ... )
%
MARKER_FLUID_INTERFACE= ( outflow_1, inflow_2, outflow_2, inflow_3 )
%
% Kind of interface interpolation among different zones (NEAREST_NEIGHBOR,
% ISOPARAMETRIC, SLIDING_MESH)
KIND_INTERPOLATION= NEAREST_NEIGHBOR
%

I expected this to work as all the interfaces and zones have been defined and the interpolation is given as nearest neighbor. Unfortunately when I run it I get a segmentation fault (see attachment) in the SetnSlidingStates function. I can’t seem to figure out what exactly this does, but I am guessing it has to do with transfer of information from one zone to the next. This simulation is not for turbomachinery, so I thought it would be quite simple (adding turbomachinery sliding mesh configurations to the config file does not resolve this issue).

When I leave MARKER_ZONE_INTERFACE out the simulation runs but immediately starts diverging and doesn’t give a normal result; it also does not do multiple zone preprocessing. I think this marker needs to stay there, but I am not sure what exactly the difference is between this one and MARKER_FLUID_INTERFACE.

I was wondering if you could help me understand how exactly I should set up a simulation for correctly transferring flow from one zone to the next and maybe shed some light on why it’s going wrong.

Kind Regards,
Marc

[pcg]

Hi Marc,
Comparing the settings you have with the ones in test case "sliding_interface/rotating_cylinders_WA.cfg" the only difference I see is the kind of interpolation (the test case uses WEIGHTED_AVERAGE).
But maybe there are others, I would try to mimic one of those testcases as closely as possible and then customize the options one by one. SU2 is not great in issuing warnings about incompatible settings unfortunately.
Cheers,
Pedro

[mlatour]

Hey Pedro,

Thanks for the advice. I've tried a couple of the test cases and have seen that they differ in configuration, even though they all contain multiple zones.
I now seem to be getting convergence for my simulations, and found that it was because I had used the marker MARKER_INTERFACE for the zone and fluid interfaces, which was apparently not supposed to be done. Getting rid of this marker gives me the results I expected.

Regards,
Marc

[eskimmel]

Just wanted to bump this thread because it helped solve my issue. I was also getting a segmentation fault, and it was because I was defining both MARKER_ZONE_INTERFACE and MARKER_FLUID_INTERFACE in my fluid-fluid multizone simulation. However, I get divergence quickly when only one is defined.

[pcg]

MARKER_FLUID_INTERFACE is required for fluid-fluid multizone simulations and MARKER_CHT_INTERFACE is required for CHT simulations. Both in addition to MARKER_ZONE_INTERFACE

[eskimmel]

Whoops, it looks like I misread the cause of the segmentation faults in the original post. You are correct, it still does not perform well when one of the marker definitions is removed. I have been trying to couple two fluid domains for quite some time now, which seems like it should be a somewhat simple process, but have run into segmentation faults and immediate divergence every way I try it. SU2 seems to pre-process the zones and interfaces correctly, but I get a segmentation fault right as the solver begins.

If possible, could you please tell me if there is something that I am doing incorrectly in my configuration files? I am trying to run a multizone fluid-fluid simulation, where there is recycled supersonic flow over a flat plate that is fed into another domain with a compression ramp. I would like to run this as an unsteady simulation with zone coupling at each time step.

I am attaching a picture of my setup with boundary condition names (black text), the master configuration file, the two sub-configuration files, and the output I am receiving from the cluster I am running on. I would greatly appreciate any insight you may have into my issue. Thank you!

[pcg]

I would simplify down to the examples we have in testcases and build up from there (periodicity etc.)
I had no idea we could use wall functions in navier stokes, are you using a special branch?

[eskimmel]

I am currently in the process of making a simpler case to see if that works. I have successfully created a periodic channel with SU2 before, so it is the multizone implementation that is causing the trouble. I have a fine mesh near the wall, so I am wondering if the problems I'm having are similar to the problems explained here: https://github.com/su2code/SU2/issues/1429. I will follow up in this thread with the results I receive from the simplified case.

No, I am not using any special branch (I don't think). Now that you mention it, I am not seeing any mention of the wall model in the output log (whereas all of my other defined parameters/markers are mentioned). Now I'm wondering if activating that feature is actually doing anything for my simulation.

[eskimmel]

I have just created my own simplified case and also ran TestCases/sliding_interface/channel_3D. There are two things I am noticing:

1) The compressible Navier-Stokes solver is causing immediate divergence (the residual blows up before anything even occurs) for reasons I am unsure of. However, the Euler solver does not have this issue. I am not finding any test cases or examples that use the compressible Navier-Stokes solver for multizone problems, so I'm wondering if is this a known issue?

2) The segmentation fault is avoided (and instead replaced with immediate divergence) when the interface domain does not appear in the sub-configuration file. I am trying to link a recycling flow domain with a ramp domain. To define the recycling domain, I must impose periodic boundary conditions in my sub-configuration file. Because the donor marker for the periodic flow is the interface domain, I think mentioning it again in the sub-configuration file is causing the segmentation fault.

[Amber0922]

Originally Posted by eskimmel

I have just created my own simplified case and also ran TestCases/sliding_interface/channel_3D. There are two things I am noticing:

1) The compressible Navier-Stokes solver is causing immediate divergence (the residual blows up before anything even occurs) for reasons I am unsure of. However, the Euler solver does not have this issue. I am not finding any test cases or examples that use the compressible Navier-Stokes solver for multizone problems, so I'm wondering if is this a known issue?

2) The segmentation fault is avoided (and instead replaced with immediate divergence) when the interface domain does not appear in the sub-configuration file. I am trying to link a recycling flow domain with a ramp domain. To define the recycling domain, I must impose periodic boundary conditions in my sub-configuration file. Because the donor marker for the periodic flow is the interface domain, I think mentioning it again in the sub-configuration file is causing the segmentation fault.

Hi,
I wat to create a rescaling/recycling at the inlet. Have you solve this problem? And I want to know, if the multizone is essential for rescaling/recycling simulation?