I would like to reproduce the results of the cylinder at Re = 3900 of your articles:
On the utility of GPU accelerated high-order methods for unsteady flow simulations: A comparison with industry-standard tools
Heterogeneous computing on mixed unstructured grids with PyFR
I downloaded the supplementary material of both articles. However, in the .ini, I did not see anything related to the spanwise or time average quantities, except the solver-plugin-sampler for the points. My guess was that you used the soln-plugin-tavg. But I am struggling to integrate the values along the spanwise direction with Paraview.
So:
could you give any tips on how to integrate the field quantities in the spanwise direction ?
how were you able with PyFR to separate the time average wake profiles of the mode-H and mode-L ?
regarding the probes in the solver-plugin-sampler, should not also these quantities been averaged in the span wise direction to compare it with the article of Lehmkuhl et al. ? If you did this, how did you perform it ?
I downloaded the supplementary material of both articles. However, in
the .ini, I did not see anything related to the spanwise or time average
quantities, except the solver-plugin-sampler for the points. My guess
was that you used the soln-plugin-tavg. But I am struggling to integrate
the values along the spanwise direction with Paraview.
The manuscript pre-dates the time averaging and point sampling plugins
by some years. As such all post-processing was done by hand. Files
were written to disk with some frequency and then averaged together as a
post processing step.
- could you give any tips on how to integrate the field quantities in
the spanwise direction ?
Usually the best solution is to sample a set of points along a series of
straight lines in the spanwise direction. Each line can then be
integrated using the trapezium rule. ParaView can be used to perform
the required sampling.
- how were you able with PyFR to separate the time average wake profiles
of the mode-H and mode-L ?
If I recall, we perform a windowed average and so we ended up with
multiple time averages that could be inspected.
- regarding the probes in the solver-plugin-sampler, should not also
these quantities been averaged in the span wise direction to compare it
with the article of Lehmkuhl et al. ? If you did this, how did you
perform it ?
This can be accomplished by placing multiple probes along a given
spanwise coordinate and then averaging as appropriate.
Hi,fdw, I have some questions. They have been bothering me for a long time.
I also want to reproduce the results of the 3D cylinder re = 3900 in related papers. However, I encountered a problem in setting the tavg plug-in. I set it like this, and the settings of other modules are guaranteed to be exactly the same as your ini configuration file.
My idea is that the wake has been fully developed after 1000s, in fact, it should be equal to 240tc. I set the tavg output every 10s at will, because I only care about the final result. That is, I asked it to use continuous model to count 1000tc, and the results obtained should be consistent with the results in the literature in my opinion. However, in fact, my results are consistent with those in the literature in some cases, and there are obvious differences in some cases.
Can you understand why this is not consistent? I may really need your advice.
From your description, I understand that you used windows mode in the original manuscript, but I want to get the final result in the literature. Should it be more appropriate to use continuous mode?
At the same time, I also noticed that the time setting in your ini configuration file is 26,000 s, which seems to have far exceeded 1000tc, because 1tc =1/0.2366431913, and the process described in your paper can be realized in about 5000s. Where am I wrong?
Thank you very much for your answer. It will be very helpful to me.
Regards.
The Re = 3900 cylinder case has two shedding modes (this is noted in our paper and the papers of others). Which mode a simulation will develop into (and when it will transition between modes) is chaotic. It is likely you are just finding yourself in a different mode or, over a large averaging period, a combination thereof.
Thank you for your timely response, fdw!
I appreciate your help in deepening my understanding of the cylinder case.
Do you have any suggestions for better replicating the cylinder case results?
For instance, should I use the ‘continuous’ mode, which hasn’t appeared in the draft of the paper yet?
Is there a better configuration for the ‘tavg’ plugin settings, and how can I improve it?
Any details about replicating the cylinder case are very important to me, and I am genuinely grateful.
I think, as Freddie says, this doesn’t have anything to do with the time average plugin configuration. Instead, this case has two shedding modes, an L mode and an H mode. Which mode you end up in initially is somewhat random as it is highly sensitive to numerical errors. You could compare your results to DNS results that are available for the two modes and see if what you are getting looks reasonable for one of the modes.
There is something else to note: this mode can change mid-simulation, and you could end up with a situation where some of the time is in one mode and the rest is in the other.
I think I roughly understand, but I’m not sure if my understanding is correct. I’m still uncertain why you mentioned that the time average plugin configuration is not important.
Currently, I have been using the continuous mode, and my post-processing results seem to indicate that the simulation remains in one mode as time progresses. How can I capture the flow in another mode?
According to your understanding, since the flow is chaotic, should I use the windows mode so that each tavg result is just an average over a window of time? Would this allow me to capture both modes?
Or is it that my simulation remains in one mode not due to its relation with continuous mode, but because the simulation time is not long enough? In fact, it has already reached 1100tc.