Learning Forum

[Akram Radwan]

Dear Jason,

I'm only referring to part (b) of your questions.

 

Everything you need for this scenario exists in Fluent, but it might not be obvious how to use it for this specific use case.

There are three workflows: one manual and two variations with the gradient-based optimizer.

All three use the same underlying technology by combining multiple sensitivity fields. Therefore, the challenges are also comparable:

• Optimizations with multiple conditions are stiff and there might not be one obvious solution.
• You might need to experiment with different weightings by setting target changes for the objectives (e.g., -5%/-5% vs. -0.5%/10% for the target changes for a single design change). It is not possible to know in advance how to set these objectives.
• The used observable (cost function / objective function) plays an important role. It must be valid for both flow directions. Observables with comparable expected outcome can result in different sensitivity fields. For example, optimizing for uniformity or variance should both give the same end result. But since the mathematical formulation of both are quite different, there can be two (or more) possible optimization results. Likewise, optimizing for abs(pressure drop) and (pressure drop)^2 should be comparable (to minimize regardless of flow direction), but only the second is differentiable and should therefore be more stable during the optimization. I strongly recommend thinking about possible objective functions for your problem statement because one might work, a slightly different formulation might not.

 

Manual workflow

You found the correct source for the manual workflow already. You calculate the two sensitivity fields separately, load both of them, and define how the observables should change.

 

Gradient-based optimizer

When you only use pressure boundary conditions, you can use the gradient-based optimizer with multiple conditions. See also the Fluent 2024 R2 User's Guide, part III, chapter 48.2.6. Using the Gradient-Based Optimizer. Look for the subsection for "operating conditions" for details.

This workflow is limited to changing input parameters, hence the limitation to just changing the pressure values on either side of the channel.

When you use this, use a fixed step size for the objectives. Adaptive stepping does not work well. And, as mentioned above, you might need to experiment with weighting the objectives for the two conditions to be able to improve the design at all.

Gradient-based optimizer with different boundary condition types
If you need velocity or mass flow inlet vs. pressure outlet boundary conditions, you can do this with the same gradient-based optimizer, but you need a few lines of script to change the type based on the value of an input parameter.

1. Create an expression with a fixed-value input parameter. For example, a value of 0 is the primary flow direction, a different value the reverse.
2. Setup the optimization like in the previous workflow.
3. Create an execute command with the code to change the boundary conditions. In the current version you can only use Scheme to do this, PyFluent is not supported for the needed trigger words yet.

The code looks somewhat like the following (untested):

(if (eqv? (get-input-parameter-value 'flow_direction) 0)
  (begin
    ; Execute this for the primary flow direction
    (ti-menu-load-string "/define/boundary-conditions/zone-type opening1 velocity-inlet")
    (ti-menu-load-string "/define/boundary-conditions/zone-type opening2 pressure-outlet")
    (ti-menu-load-string "/define/boundary-conditions/set/velocity-inlet (opening1) vmag 5 q")
  )
  (begin
    ; Execute this for the reversed direction
    (ti-menu-load-string "/define/boundary-conditions/zone-type opening1 pressure-outlet")
    (ti-menu-load-string "/define/boundary-conditions/zone-type opening2 velocity-inlet")
    (ti-menu-load-string "/define/boundary-conditions/set/velocity-inlet (opening1) vmag 5 q")
  )
)
;@before-flow

Important, you must adjust the code to your case:

• Replace "flow_direction" with the name of your expression. The single quote in front of it must be kept!
• Adjust the name of your boundary conditions, here: "opening1" and "opening2", and their respective types for the two flow directions.
• Adjust the text command to set the BCs accordingly.
• Test each text command (see TUI in the documentation) and the script as a whole before you start a single iteration! Each Scheme statement is always within a pair of parenthesis. Indentation and additional white space is ignored by the interpreter.

The ";@before-flow" is needed only within the execute command. Set the command to execute every design iteration and use this trigger word to define when it is executed during the design iterations.

You can find more information in the documentation (same page as above), search for "Execute Commands". Once the script is executed for each flow calculation within the optimizer process, you can use the input parameter in the operating conditions section to change the direction accordingly.

 

Please also note that scripts written in Scheme are not supported by Ansys. You can use the code but do not expect any technical support if you run into problems. Always save your case before the first use. And then test the code with simple statements and add additional statements slowly. It is very easy to make mistakes with the parenthesis which could turn a case useless, potentially. The statements from the example above are mentioned at different locations in the Fluent documentation, so it should be safe using them.