Field function for defining "pressure oulet"
 

Hi all,

I'm looking for explanation of the syntax in the field functions.

i need a field function to modify my pressure outlet for each 5000 iteration fx.

an example could be:
0-1000 iteration -> Pressure = 1bar
1000-1500 iteration -> pressure = 2bar
1500-2000 iteration -> pressure = 3bar
...

currently i'm at:
(${Iteration} >= 1000) ? ${P_INLET} = 10e5
but i'm sure it is wrong.

Thanks in advance

you have the syntax wrong and the result is output to your input menu, scene etc and not within the equation:
(${Iteration} < 1000) ? 1e5 : (( ${Iteration} < 1500) ? 2e5 : (( ${Iteration} < 2000) ? 3e5 : 4e5 ))

your stepping of the pressure might cause instability and so you could consider a simple linear ramp with something like this:
(${Iteration} < 2000) ? ${Iteration} * 400.0 : 4e5

(both assume you want the pressure to be get to 4e5 at 2000 iterations - you did not specify what happens after 2000.

Hi Ping,

Thank you, very helpful.

Instead of crazy syntax-based nested conditions - I'd suggest external .csv-table (Iteration-Pressure) and interpolateTable() function with LINEAR option.

cwl, could you explain the external .csv method?

anyone who has got to this level in their studies should be encouraged to learn the wonderful power of field functions and equations in star since it opens up so much potential.
tables will do this task well too but is painful if you decide to change a setting since a new table is required to be created and imported - better suited to importing a long time series of data and then interpolating. you can read about it in tools, tables.

Create a .csv-file table with contents like following
Load it in Tools -> Tables

Then - you can use it in Field Functions like:

Honestly speaking - I wouldn't call it wonderful power, for functions they lack functionality of functions:
- arguments;
- loops;
- calling other functions;
- something more handy for dealing with ranges than inhuman ternary operator.


Table can be just reloaded.
Again, I would not call using tables painful in such case - compared to multiple nested (...) ? ... : ... conditions.

No doubt that tables were intended to be used fpr dealing with data series, but given current limitations of capabilities - I'd use them in this case.