Learning Forum

[Lucjan Nastalek]

Hi,

Here's my stumbling block: 

I'm trying to set up non-conformal mesh interfaces in my simulation. I want the interfaces to be mapped (and coupled). 
However, whenever I create them, they appear also as matched - which I specifically do not want. 

Whatever I do, edit, recreate - they always end up the same, with the "matching" forced on me. 

 

To quote a classic, my question is: what the heck?

Is there a way to switch this matching interface enforcement off?

 

Thanks,

LN

[Rob]

If you turn off the one to one pairing (there's a TUI command) you can set as much or little as you want. Note, some settings will automatically trigger others, I can't remember whether mapped & matching do that. 

[Lucjan Nastalek]

Thanks Rob, I'll try that.

From documentation, when you switch on "Mapped", "Coupled" gets switched on also. But that is exactly what I want. 

 

I'll report back on the result.

 

Thanks,

LN

[Lucjan Nastalek]

 

 

Right on! 

I’m not sure if this is a bug, but it sure looks like a bug. 

In version 2023 R2, there are two ways for switching the one-to-one-pairing off:

 

 

1. by typing in /define/mesh-interfaces/one-to-one-pairing? no
2. by switching on the turbo model. This seems to automatically switch off the pairing, also.

 

 

Initially, I:

 1. loaded the model,

 2. switched on the Turbo models,

 3. created the Turbo interfaces (which switched off the one-to-one)

 4. proceeded to set up all other, Mapped, interfaces. This enforced Matching option to every other interface that I’d made, even though I hadn’t selected the option (I wanted Mapped+Coupled, but ended up with Mapped+Coupled+Matching instead).

Just 10 minutes ago I finished setting up the interfaces in a reversed order:

 1. I have first switched off the pairing,

 2. then created the general interfaces (Mapped+Coupled) – which now recorded the correct options w/o the enforced “Matching” option,

 3. after which I switched on the Turbo models

 4. and created the Turbo interfaces last.

This time, the other interfaces retained their options ( Matched+Coupled, no Matching “nonesense” added). 

 

Perhaps this behavior is intended. Perhaps even it is very well documented, and I simply glossed over it somehow. But it feels very counter-intuitive to me.

By the way, in the first option, I tried to edit the Matching interfaces to switch off the option, but it would do nothing at all: the Matching option remained switched on.

Of course, there’s no guarantee that this will have improved my case’s convergence, but at least I’ve learned something about setting up interfaces in Fluent 2023 R2. I am therefore putting it out there for anyone else interested. 

 

Any further comments and/or clarifications and/or corrections are welcome!

 

Thanks,

LN

[Rob]

Thanks for the update. I'll mention it to a colleague who does spinning things, but suspect we won't be able to comment. 

It's more likely an intended setting from the Turbo side, which has a specific role and is to simplify set up. The "normal" nonconformal interface in Fluent has many (mis)uses so is marginally less straightforward but was always very adjustable to suit what we were (not supposed to be) doing. 

 

[Rob]

Do you have the same mesh on either side of the interface? 

[Lucjan Nastalek]

 

Rob, 

No, the mesh is not identical, the interfaces are non-conformal. 

– edit –

To summarize my adventure with using the different types of interfaces…

Switching on turbo models on, and then setting up general interfaces would enforce the “matching” option on all of them.

Not switching turbo models on, does not enforce it. 

Just a strange (perhaps intended?) behavior that I’ve noticed. I’d like to hear from the developer team if this is indeed intended.

I could, therefore, create the general interfaces with “mapped”+”coupled” options (but not “matching”) prior to turning on turbo models.

Turning turbo models after the creation of those general interfaces would not alter those settings (they would remain “mapped“+”coupled”  w/o “matching“).

– end of edit —

However, I’ve discovered that :

1. yes – the interfaces were partly causing the divergence issue.
2. no – the interfaces were not entirely responsible.
3. running the case, first with constant density of air allowed it to converge, albeit with wrong pressures
4. switching to ideal gas after 3. allowed me to converge the compressible case.
5. Because I am modeling a full 360° wheel geometry/mesh, I found it better to avoid using the turbo interfaces.
6. I think (in my opinion, not backed up by any research into it as yet), that the turbo interfaces do not “like” to be applied at an axial exhaust of a radial turbine – perhaps something to do with the radial distance of 0 at the centerline, and therefore some division by 0. 
7. general interfaces work like a charm, even with the MRF approach.

Would you be able to confirm or deny the limitations of the Mixing plane/ No Pitch Scale interfaces for radial machines? 

 

Thanks,

LN

 

 

 

 

[Rob]

Shortish answer. Don't use the turbo tools for fully enclosed 360 zones (ie mixing tanks etc), use the traditional sliding interface for that. I'll ask a colleague to review the DOC once 2024R1 is out to check it's clear on what should be used where. Turbo is quite a specialised application area so there's a good chance they didn't consider alternative uses of their tools. 

[Lucjan Nastalek]

That makes perfect sense, thanks! 

I do appreciate that writing a documentation is like teaching - audience's perceptions vary.

I will be reviewing the documentation, though - I do sometimes scan for the information that I need. 

Anyhow, I shall mark this as answered.

Thanks,

LN