Hi @fdw,
I have been able to set the 1D kernel, but what about updating it in real time? For matrices there is the .set method, but what about scalars then?
Best regards
Use a one element matrix. Then .set can be used as expected. While there is a mechanism for scalar arguments it is somewhat more involved (if you want to see how it is used look at how the current time is passed to kernels; particularly around the bind method).
Regards. Freddie.
Hi @fdw,
thanks a lot the bind method worked as expected. One last thing: I need to loop over the face pts and the neles within the mako template (BC). Actually is indexed by nvars hence for example ul[0] is rho etc, but if I try ul[0][i][j] I get an error. How, if possible, this can be accomplished?
Best regards
Kernels in PyFR come in three types:
- Those which operate on each point of each element (2D kernels).
- Those which operate on each element.
- Those which operator on a sequence of flux points (1D kernels).
However, there is no kernel type which does what you want. As such you will want to split you task down into multiple smaller kernels that fit into these categories.
Regards, Freddie.
Hi @fdw,
could you provide an example for each category so that I can look at the syntax of each typology? For reference: I need to compute the mean value of ul[i] for a given variable index i.
Moreover, is there any way to get from the plugin the ul state of a BC? I tried with the projection onto the face but it is different from the ul of the solution
Best regards
- PyFR/pyfr/solvers/euler/kernels/tflux.mako at c70a927a1b2386c2c3f01df8309e1e855ba3c374 · PyFR/PyFR · GitHub
- PyFR/pyfr/solvers/euler/kernels/entropylocal.mako at c70a927a1b2386c2c3f01df8309e1e855ba3c374 · PyFR/PyFR · GitHub
- PyFR/pyfr/solvers/euler/kernels/intcflux.mako at c70a927a1b2386c2c3f01df8309e1e855ba3c374 · PyFR/PyFR · GitHub
To get the solution at a boundary see the fluid force plugin as an example.
Regards, Freddie.
Thanks a lot for the kernels info, I’ll give a look to them. One last info about the ul in the BC kernel. What is the shape of ul[i]? (1,nfpts, neles)? If I want to make a matrix multiplication with ul[i] * A, how should I size A?
This gives the information about ur[i]. I would like to know that is the left state and to bring this in the plugin
Best regards
There is not necessarily such a state at all. Some boundaries generate a right-hand side given information from the left-hand side and then pass this into the usual interface flux machinery. However, other boundaries, for example the adiabatic wall, just impose a flux directly and never compute an intermediate state.
If your boundary types fall into the former class, you can reproduce the relevant formulas in the plugin.
Regards, Freddie.
Thanks for the explanation,
just this point left:
Best regards
In the BC kernel ul[i] is a scalar as:
where you can see that what the kernel sees is ul being an array of nvars (and corresponds to the solution at a single flux point).
Regards, Freddie.
Thank you very much.
To bypass such issues, I could use a plugin to apply such modifications, but what is the computational cost of the plugin call? Is it related to the call of intg.soln (does it perform a copy from GPU at every call?) or is it more related to the plugin operations themselves?
Best regards
Both. Copying the solution can be a costly operation. Additionally, most plugins are written in Python and only run on a single core which tends to be a lot slower than the backend code.
If the plugin is not being called too frequently this is not an issue, but if it is every timestep then it may significantly slow down the simulation.
Regards, Freddie.
1 Like
Do you have any idea on how to implement a cost effective correction in runtime?
Best regards
Just only have it run once every ~500 time steps.
Regards, Freddie.
Hi @fdw,
Regarding the same paper, could you describe a little bit more the startup procedure? In the available config file the ics is just
[soln-ics]
rho = rhot
u = 0.0
v = 0.0
w = 0.0
p = pt
but I don’t think it is the procedure reported, namely “The simulation was initiated at t = 0 and advanced in time through to t = 230.0 via a series of partial-span-periodic and then full-domain runs, with second-order and then third-order polyno- mials used to represent the solution within each element of the mesh, and po = 0.7910 uniformly at the outflow plane. This was done to wash out large-scale initial transients.”
I’ve been trying a bit with different ics for my case but I’m currently failing in getting it forward in time
Best regards
What grid are you using?
Regards, Freddie.
Hi @fdw,
regarding this, do you have a way to find which were the factor (i and p) that worked the best in your case to have an effective control. Also did you use an activation frequency of 500 steps?
Best regards
The config file we used for the T161 simulations is public:
https://pyfr-mtu-t161-dns-data.s3-us-west-2.amazonaws.com/config.ini
Regards, Freddie.
There is no “i-factor”, “p-factor”, that are those used in the plugin. I was referring to those values.
Best regards