Accessing Flow Rate Through Face for Multiple Load States

[tfjield]

Hi!  I'm really hoping this is a simple question and I'm just an idiot!  Really!

When running the Steady Fluid Flow or Unsteady Fluid Flow for a given load state, I am able to get the total mass flow at a given pressure boundary condition, for example, by changing the Results Contours to Flow Rate Through Face, then selecing a Surface and using Results Inquire -> Current Results and choosing Sum for the Summary.  Easy peasy.  I can then save the data to the report, etc.

Here's my question:  How do I export this data if I have n > 1 load case?  I know I can do it manually load case by load case, but...  What if I have 600 load cases?  Two common scenarios where I may want this information:  Simple flow versus pressure curves, or flow versus time when the pressure is varying.

In the output files, I get node velocities.  I assume I could then write code to use the node coordinates, calculate element areas on a given surface, and then calculate and sum the mass flow through the surface for each of the load cases...  But I'm really, really hoping there is a simpler way!

Thanks in advance!

[John_Holtz · Accepted solution]

I agree that it is a simple question. But I do not know of a simple answer. I thought that the flow rate was a result that could be graphed, but I was apparently mistaken.

But if you can write a program, an easier solution is to write a program to read the binary file that has the flow rate results and does whatever you need. By inquiring on the results in the Results environment and saving it, your program can get the part, element, and face numbers where you want to sum it. I have attached the old documentation that describes the file format.

[tfjield]

Thank you, John.  Yes, that's much easier than calculating flow based on nodes and velocities!!

If you happen to discover a method to dump the data out directly, that would be appreciated, but it won't take me long to write up a script to pull it from the binary file.

[tfjield]

Hi John,

I have a detailed followup question for you regarding the file format.

I am able to read the file and sum the values on the appropriate faces so that the result matches that calculated by Results Inquire exactly.  So, success!!

But there is one minor discrepancy.  I have 600 time steps, plus time step 0 of 600 in which all the flows are 0, totalling 601 total time steps (0-600).  The header in the binary file lists 601 for TimeStepCount, so I expected everything would match up.

However, the first TimeStep in the file actually corresponds to time step 1 of 600 in Simulation.  And the last TimeStep in the file gives me a weird number that doesn't actually match up with anything.

It's always possible that I've done something wrong, but I just thought I would doublecheck...  Is there anything you can tell me about that unusual time step result?

[Joey.X]

hi, tfjield

Thanks for the interests on the flow rate, yes, flow rate is an effctive way to check result fidelity of mass conservation, for incompressible flow, user can cut any flow section to verify the inflow and outflow mass balance. The postprocessor provides way to cut (optional)/select/sum flow rate in visual fashion, this is a common approach for general users to explore in software.

- Flow rate is a derived result from fluid nodal velocity; it needs complicated integration using element shape functions (different kind of 3D element types). This is usually difficulty for customer to calculate flow rate.

- The relative easy way to parse outputted flow rate result file, this is element based result, i.e., each 3D element has 6 items corresponding to generally six faces for brick element, however, it needs handling/interpreting  arbitrary degenerated elements (4,5,6 nodes) in fluid domain, typically with boundary layer mesh enforced for fluid flow which has many wedge, pyramid elements. So this approach is also not direct to user without official documented APIs.

For you last question, please post you model (if it's small) so that we can see the issue?

Thanks, 

[John_Holtz · Accepted solution]

Hi,

I agree with your findings. I confirmed in my test model that he time step count given in the header is one larger than the number of results actually in the binary file, and the binary file does not contain the results for time=0.

[tfjield]

Hi Guys,

Joey, thank you for the reply.  Visually in the application works well if a user has only one or two load cases, but if one is performing a transient analysis with varying inputs, many load cases might be necessary.  In fact, in the model I'm working with, I have 600 load cases where I look at flow at a particular time in order to calculate the time constant for the system response.  Visually, one by one, is just not a practical way to deal with it.  Luckily, the information John gave me was enough for me to be able to programmatically pull the data that I needed to get to.

John, thanks for checking into that.  I will desregard the last load case in the file.

Thanks again!  I really appreciate the quick responses that you guys post to the forums.