applied-scientific-research / omega2d Goto Github PK

When you remove a boundary and then create a new one before reseting the simulation, feature draw will draw the old boundary, and then when the simulation starts the current boundary will be drawn.

When moving the simulation around with the mouse, if you drag your mouse over the Omega2D/Simulation design window(?) (not sure what to call it) it will keep dragging the simulation around even after you stop pressing your left mouse button.

All of my jsons with Polygon objects in them do not load. Seems simple.

There is a simple and standard format for airfoils (wing sections) which we should support, see https://m-selig.ae.illinois.edu/ads/coord_database.html or http://www.airfoiltools.com/ for many examples. It would be nice if our json format would support either a file name or the raw data itself.

Upon loading, we'd need to join the trailing edge points (they are often non-zero thickness), and also compute spline paths for the segments to allow us control over panel size.

Particles seem to be created away from the main vorticity area during shedding, but only if the solid body has an angle less than 90 degrees. Pull down the "Select a Simulation" tab, pick the "Flow over triangle" case, increase the particle brightness and decrease the particle scale. After a short time, particles will appear with a flash in the far-field away from the flow. I suspect it's a problem with computing the normal for a target point near an acute angle.

Currently the Polygon Boundary Feature can only do equidistant vertices, which prevents it from making many types of parallelograms and other shapes.

Whether loaded from the dialog or from the command line, we should not take the first time step (init the sim) right after json load - the featuredraw should be displayed. Omega3D now acts like this.

In Points the assertion else assert(_in.val.size() == _in.nelem && "Input ElementPacket with vortons has incorrect size val array"); fails with the speed test on windows.

When you create a square boundary with any parameter set and then run simulation using any kind of flow, the program immediately crashes and gives this message:

Taking step 0 at t=0 with n=0
Inside Diffusion::step with dt=0.01
  Solving for BEM RHS
  Solving for velocities on 616 Reactive Fixed Panels
    convert vels to RHS vector for 616 Reactive Fixed Panels
    putting data into rhs vector from 0 to 1232
inside Surfaces.initGL with E=2 and M=3
  new GlState with 4 buffers and 1 shader programs
  Solving BEM for strengths
Shader compilation successful
Shader compilation successful
    solver.solve:	[0.003110] cpu seconds
zsh: segmentation fault  ./Omega2D.bin

Boundary features with straight edges now create boundary segments to reduce the amount of code creating panels. We need a similar process for curved segments for circles, ovals, and the airfoil.

Comp_ellint_2 crashes the program when creating an oval with a smaller diameter than its minor diameter. While it is obvious the minor diameter should be smaller than the diameter, we should probably create a check to prevent the program from crashing.

If every boundary element had a small chance every time step of generating a new inert particle. we could visualize wakes more interestingly (to many people) than with vorticity. It would recreate the look of releasing milk from an object in a water tunnel.

XML-based VTK files can use one of three compression algorithms for data arrays (LZ4, ZLib, LZMA), and PNG writing can use only ZLib. We should support zlib compression for png and vtu file output. Hopefully Paraview can read compressed files - I recall it failing to read any file with "appended" data.

Since zlib is relatively small, we should consider copying a header-only, compliant-licensed library into our repository. Consider zstr, miniz, or gzip-hpp.

Also, since Vtk output needs not only an encoding library but a compression library, maybe we should make it it's own cpp file (to generate a .o file), and not as a pure header - this will save compilation time.

Doing this in real time would allow the user to see how their current features may interact once the sim starts, and this would probably bring use a step closer to allowing the user to create custom objects. This would probably require rethinking our feature info window positioning

As a step toward the hybrid solver, we need to be able to read boundary (only) elements from an .msh file as output from GMSH and turn them into a BoundaryFeature. For starters, we can keep the elements all linear and 1st order.

For this, a new BoundaryFeature subclass will need to be created for "user-defined" outlines (see #56). Once this is functional, we can expand the msh-reader to include the volume elements (quads first) and then high-order volume elements.

It should be a static class function just called read_json instead since they only pertain to a certain class

Currently it crashes, so the gui is set to max it at 17. Ideally we wouldn't care about the sides, or at least cap it at a much bigger number.

Particle and field/volumes output should include vorticity. This means creating gradient versions of all core functions and the panel-point influence formulae, toggling velocity gradient calculation only during vtu output, storing a ug velocity gradient tensor where required, pulling vorticity out of that tensor, and writing it to the vtu files.
Related to this is the fact that in the hybrid code, we will need to draw vorticity as returned from the high-order Eulerian solver, so the proper shader program will be needed to draw quads or tris, and a scalar vorticity uploaded to the GPU.

Currently we have large write_vtu_x files for specific classes. Instead those classes should have a write_vtk function which uses functions from the VtkXmlHelper file (the writer itself could be a class).

Line of emitters doesn't seem to be working. Attached file draws the emitter points, and it seems that points are being created, but they are not moving. Also, there's a point at the origin.

Argh, can't attach json files here. See the Discord window.

When a user creates a new flow or boundary feature, it is not drawn. Only after a reset and restart is the feature drawn on the flow field. It would reduce confusion and help setup if they were drawn immediately upon creation.

In the GUI, when I add a boundary, select movement "according to formula", and add any non-zero formula, the resulting motion does not happen during the simulation. When I save the json, the movement formula is not saved. But when I load a json from the "Select a simulation" pull-down, and that simulation has movement, the objects do move correctly.

It appears that the Body object is not being created correctly when the BoundaryFeature is made. Look at the output json to check this.

Omega2D will soon support volumetric computational elements, and ultimately high-order elements. VTK has supported biquadratic quads in the past, which aid visualization in ParaView, but not smooth contours. Since 5.5.0, ParaView has supported additional high-order elements. Here are some links pertaining to the support and definition of these elements.

Arbitrary order Lagrange finite element support in PV 5.5
Detailed discussion and node ordering of Lagrange elements in VTK from Kitware
Discussion and links from GLVis issue
Code specifying VTK element IDs and node order from MFEM - shows VTK_QUAD is 9 and HO Quad is 70
List of standard VTK element types
C++ code to create quad and hex meshes in legacy VTK format
FMS as an interchange format for HO elements

Also, look at Process_Results.f90 for quick-and-dirty node ordering (not sure where this is).

When a boundary feature is centered on a point other than (0,0), it follows a circular path around its center instead of rotating in place.

We can't use Vc-accelerated methods on Windows because of a mismatch in the calling conventions between Vc (which requires vectorcall) and whatever Visual Studio uses. This makes the Windows version up to 8x slower than it could be.

When a json file uses old or incorrect syntax, the program crashes ungracefully. The culprit is lines in read_json functions like this:
m_thickness = j["thickness"];
One solution is to use an alternative assignment line that accepts a default value:
m_theta = j.value("rotation", 0.0);
But it would be even better to also inform the user that a property was not found and a default value was assigned.

When paths are long, or if you just want to see all the buttons, you can resize the FileIO window. But on Linux, when you let go of the resize handle, the window pops back to its original size.

All json and gmsh input which are strings should convert to lower case internally before comparison (except file names, obviously) - things like boundary conditions in the gmsh file, and key words in the json.

A new BoundaryFeature subclass needs to be created for "user-defined" outlines, for which some external system generates a set of N coordinate pairs (x,y), assumed to have the first connect to the last (ultimately multiple sets of outlines and holes).

This set of pairs could come from a user-generated and selected text file, the user drawing on the screen, an airfoil file in Selig or UI-A formats, or the wall boundaries from a CFD-standard mesh file format (like from GMSH). The user would have the option to force only one computational element between each adjacent pair of nodes, or to allow Omega2D to re-discretize the outline into uniform-sized elements.

This seems to be a necessary first step before fully implementing a gmsh reader.

Important question: how would this interact with BoundarySegments?

We should support a MeasureFeature which logs the velocity at a given point once every step. Then upon request for vtu output, writes the time-series to a file. This data can then be passed to an FFT external to the software for calculation of shedding frequencies, etc.

On Windows, when saving the simulation setup to json, if the user does not type the .json file extension, the file is not saved anywhere (or it is, but just as output.json. Can we check for the correct extension and add it if necessary?