2
$\begingroup$

My simulation creates a 2d grid of vectors and scalars (EDIT of velocity, depth etc), at 60 frames per second. Is it correct? It looks sort of right... but who knows? How can I tell what's happening - especially for debugging?

Thoughts so far:

  • Arrows for velocity field is difficult to see what's happening in small areas/fine detail. And if using length for magnitude, you have to get the scale right, or the arrows disappear (too small) or become lines (too big).

    • Or, can use colours for magnitude (standard rainbow key, to map colours to numbers). Still has the scaling problem.

  • particles (dots), evenly placed and moved by the velocity field. Density of dots then implies divergence; and cirlcular motion implies vorticity.

  • Green/red for curl (vorticity), clockwise/counter-clockwise

  • Grey-scale for divergence (compression)

  • Height field as a 3d isometric surface, with labelled axes and scales

Is it better to dump all the data to a file/s, and then visualize it later, with a separate tool? You could then move forward and backward in time, like a movie, and switch between quantities to visualize, and methods of visualizing. Maybe, in practice, just hacking the code to display different things is the best way to make progress?

I'll have to create the visualization code myself, and it seems a bit of a project in itself, so I'm hesitant. I'd like to get some guidance from those more experienced, as to what is actually most useful, before diving in.

  1. what quantities are most useful to visualize?
  2. how to display them?
  3. how (and when) to select which one to display (a UI issue)?

EDIT I should add, I'm developing on android (on the device itself, not on a PC), so many popular tools/apps aren't available. And, since my main project is to display real-time simulation, also visualizing some data isn't that different a task.

|cite|improve this question
$\endgroup$
  • 1
    $\begingroup$ I am not sure I understand. Do you wish to debug the results of your simulation (Velocity, pressure, etc.) or the visualization aspect? For the latter, I believe a simple unit testing approach is more efficient. For the former, you should really look into something like the method of manufactured solutions to be sure the solution you are getting is good. $\endgroup$ – BlaB May 23 '17 at 12:08
  • $\begingroup$ @BlaisB Thanks, I meant the former; edited to clarify. "Manufactured solutions": guess a class of analytical solution, then add the errors to the NS equations (as source terms), to make it correct. Now, can check simulation results with it. Clever! But seems to need industrial stength tools to work out the analytical errors. "several pages to print out just the energy equation source term". I think my openGL rendering (visualization) code is OK - but I'm curious: how could unit testing be applied to it? $\endgroup$ – hyperpallium May 24 '17 at 8:07
  • $\begingroup$ I have regrouped my two comments as an answer, I think this presents a clearer perspective. $\endgroup$ – BlaB May 26 '17 at 11:49
  • 1
    $\begingroup$ The pressure. It's easier to explore since it is a scalar. And if something's going wroing you will see it in the pressure first. $\endgroup$ – Jan Jun 1 '17 at 8:26
  • $\begingroup$ @Jan Thanks, that makes sense. Actually, I started with pressure$^{1}$, but because I'm using compressible equations, you get pressure waves everywhere, and it's hard to see what's going on. But maybe there's a way to make it clearer, because you're right... maybe, somehow have waves with smaller magnitude than larger-scale pressure variations? Or, wait for it to settle down to a steady-state? [1] actually density, not pressure; and actually water depth, not density - but the point still stands. $\endgroup$ – hyperpallium Jun 1 '17 at 13:21
2
$\begingroup$

A good way to obtain to verify the CFD portion of your code is to proceed using the method of manufactured solution (MMS). You can look at the book by Oberkampf & Roy or even this article by me.

The key principle of MMS is to decide on an analytical solution to your problem (in this case a velocity and/or pressure profile) and, using a symbolic calculator, to calculate the source term that corresponds to this flow profile inserted within the Navier-Stokes equation.

There are numerous commercial (Matlab, Mathematica, Maple) or open source (Python + SymPy, Sage) ways to calculate this source term. I have found that SymPy is super easy to use and is very efficient. The source terms can be quite long, but if you take trigonometric functions in your flow profile, they generally simplify to simple expressions. You can take the flow profile from my article as an example.

|cite|improve this answer
$\endgroup$
  • 1
    $\begingroup$ In my cases I had some test cases with div u not equal to 0, because of the VANS equations. However, if you have regular Navier-stokes, I suggest you choose U such that by construction div u = 0. Actually I did like you did, I would calculate each derivative one by one using Simpy, I felt more secure that way and it was super fast anyway. To me a transient regime (or solution) is a solution such that $$u=u(t,x)$$ therefore, with a non-zero time derivative. Similarly, a flow profile is a solution for velocity $$u=u(x,t)$$ a function that defines $$u(x,t)$$ everywhere in space/time. $\endgroup$ – BlaB Jun 1 '17 at 12:08
  • 1
    $\begingroup$ No prob, pleasure is mine. MMS is regretfully not used enough in the verification of CFD codes. To me, I cannot trust CFD results if at least MMS has not been carried out... If you code does not follow the theoretical order of convergence in MMS cases, then something, somewhere is inconsistent. $\endgroup$ – BlaB Jun 1 '17 at 14:25
  • 1
    $\begingroup$ @hyperpallium Many questions! The transient case is run at constant CFL. I mention it in the article, thus the time step decreases at the same rate as the mesh size. Theoretically, if your scheme is second order in space, you should recover second order convergence in space. If you do not, there is an arrer somewhere somehow with your discretization. This way of measuring the order of convergence is super sensitive, an error in a single mesh element, at a single node, on a single boundary, will lower the order of convergence and you will catch it. $\endgroup$ – BlaB Jun 8 '17 at 12:38
  • 1
    $\begingroup$ @hyperpallium. In many circumstances, discretizing the source terms is a major source of error. For example, shallow water flow with variation of the bottom surface. You discretize the differentiated terms using the best approved methods, and add in the source terms point wise. Then try the evil lake problem Free surface height = constant, velocity identically zero. The lake will start to move spontaneously. Schemes that avoid this are called well-balanced and their construction is non-trivial. put "well-balanced schemes"into Google Scholar. $\endgroup$ – Philip Roe Jun 8 '17 at 22:01
  • 1
    $\begingroup$ You should try to avoid to have discussions in the comment section. If you have an error in your scheme, you will see the order of convergence reduce drastically and you error will level off to a plateau. The order of convergence is generally greatly affected if there is an error in your scheme (reduction to order 1, or order zeroth). The rate of convergence of a scheme is only asymptotic, so if you are getting 2.02 instead of 2.00, like in my case, it just means that i have not reached the asymptotic region of my convergence yet (but I am close to it). $\endgroup$ – BlaB Jun 9 '17 at 14:26
1
$\begingroup$

Creation of own visualisation code, it is hard to justify, unless you will have some strong arguments why existing codes are not good enough. It is a couple of great open codes.

You can do visualisation on the fly when you do analysis, http://www.paraview.org/in-situ/ great tool, or as result of post-processing, see Paraview, openDX, visit a large number of possibilities.

Paraviev catalyst is particularly interesting; you can link your app. to it and do all in parallel when your run the analysis.

|cite|improve this answer
$\endgroup$
  • $\begingroup$ Thanks, I'm developing on an android device (not just for it; i.e. no PC is involved), so I thought tools would not be available. But through your answer, I found kiwiviewer.org an "open source...visualization app for exploring scientific...datasets that runs on Android...devices". I'll have to work out its fileformat, and try it out. From your paraview link, it's interesting that most visualization is post hoc, not in situ.BTW opendx.org seems down. $\endgroup$ – hyperpallium May 23 '17 at 3:04
  • $\begingroup$ I had a play with kiwiviewer. It's very smooth, and has some pretty cool touch controls, for zooming, and enabling/disabling layers; but no scales. You also can't add your own data (it has presets, or you can use a http: url - bit not a file:) It seems intended for use as a library, but requires ant for compilation, which I don't have access to. $\endgroup$ – hyperpallium May 23 '17 at 7:58
  • $\begingroup$ On the plus side, I realize it's very easy to automatically scale nicely, if you can look at all the data before displaying: just note the range. BTW a pure java library is another alternative for android (kiwiviewer is C++, though with bindings). $\endgroup$ – hyperpallium May 23 '17 at 8:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.