Hey,
Have you tried to move the coordinate system? What matters when exporting is the relative position between the wing and the CS.
Best wishes,
Luis Calzado
Greetings @agrenke,
No, I am still stuck with this problem, I have reported it to SimScale support and I am still awaiting an answer from them to solve it.
Best regards.
Hi
I’ve no idea why I can’t unite car with my front wing. When I’m exporting front wing to .stl it’s looking like… I don’t know like what, but for sure not like a front wing. And it’s not letting me import that into SimScale. When I do unite of .stl of front wing with the car’s .stl using the program, uniting is going good, but when trying to import into SimScale same error occurs.
So as in the SimScale geometry tool has no unite option, I can’t get the simulation of full car running.
I’m using Inventor 2017 to create models.
Link to my simulation: https://www.simscale.com/workbench?publiclink=2858fe07-aa1e-4eca-808d-a712e1db0a67
I have the same problem in my simulation and have no idea on what to do.
I got this in my Solver Log.
I forgot to make only half of front wing. Does it mean I have to start once again?
Hey! Were you able to figure out the problem. I’m in the same boat.
“The job execution was aborted, possibly due to a numerical instability. Review the log to identify reasons: unphysically large field values, extremely small time step size, etc. Modifying numerical settings and time step size could resolve the issue.”
Share the project link please.
I have the same numerical instability problem. Mesh worked fine, I’ve double checked my values with the Workshop 2 Tutorial. See below for link:
At the end of the meshing log:
Checking faces in error :
non-orthogonality > 75 degrees : 1746
Non-orthongality is usually not a huge concern, because it can be corrected in laplacian and snGrad schemes. But with such a huge amount and not knowing where these faces are located, you may not want to use full correction on laplacian:
Use 0.3333 or 0.5. Somestimes my grid has a few faces with non-orthogonality as high as 80, but a full correction is still stable, probably because those faces are located in low-gradient regions of the flow.
You can also use 1 or 2 non-orthogonal corrections to improve stablity
But remember, the more the correctors, the longer it takes to solve.
Finally, I don’t know why the inlet omega is set to 40-ish ( I guess the inlet value is the initial value because the BC’s on SimScale are packed to save your time ). Based on the given omega, k and nu, the inlet turbulent viscosity ratio nut/nu is like 100, a number not realistic for external aerodynamics at all. You would aim for nut/nu = 1~10 for a wind tunnel validation.
But…after going through the logs, the reason why the runs have failed probably has nothing to do with what I just said.
This is the run log from Run 3:
Time = 1
smoothSolver: Solving for Ux, Initial residual = 0.00550511416334, Final residual = 4.33389007056e-05, No Iterations 2
smoothSolver: Solving for Uy, Initial residual = 0.0136866929635, Final residual = 0.000111771168718, No Iterations 2
smoothSolver: Solving for Uz, Initial residual = 0.0231768809005, Final residual = 0.000159057920557, No Iterations 2
[11] Signal 8 encountered
[11] Going to reraise SIGTERM after writting
[11] Resetting old handlers (just in case)
[11] Unset SIGFPE(8) signal handler
[11] Unset SIGSEGV(11) signal handler
[11] Unset SIGQUIT(3) signal handler
[11] Writing old times:
[11] 1 times to write
[11] Writing current time 1
[11] Printstack:
[11]
[11] #0 Foam::error::printStack(Foam::Ostream&) at ??:?
[11] #1 Foam::writeOldTimesOnSignalFunctionObject::sigHandler(int) at ??:?
[11] #2 in "
[11] #3 Foam::GAMGSolver::scale(Foam::Field<double>&, Foam::Field<double>&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::Field<double> const&, unsigned char) const at ??:?
[11] #4 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const at ??:?
[11] #5 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
[11] #6 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) at ??:?
[11] #7 Foam::fvMatrix<double>::solve(Foam::dictionary const&) at ??:?
Just my guess: because the solver stopped before the pressure matrix, the divergence probably has nothing to do with the GAME solver but what feeds into the GAME solver…
I downloaded your mesh to run checkMesh, and this is the log…
Checking geometry...
Overall domain bounding box (-9.825 0.000999886032362 -4.16333634234e-17) (18 7.201 7.2)
Mesh (non-empty, non-wedge) directions (1 1 1)
Mesh (non-empty) directions (1 1 1)
Boundary openness (9.62135227303e-17 -5.77334538733e-16 1.19294240686e-15) OK.
***High aspect ratio cells found, Max aspect ratio: 4.94847754682e+94, number of cells 477
<<Writing 477 cells with high aspect ratio to set highAspectRatioCells
Minimum face area = 1.25708398248e-09. Maximum face area = 0.0682384707207. Face area magnitudes OK.
***Zero or negative cell volume detected. Minimum negative volume: -4.07373908016e-09, Number of negative volume cells: 477
<<Writing 477 zero volume cells to set zeroVolumeCells
Mesh non-orthogonality Max: 179.94355699 average: 12.7161686236
*Number of severely non-orthogonal (> 70 degrees) faces: 4226.
***Number of non-orthogonality errors: 1075.
<<Writing 5301 non-orthogonal faces to set nonOrthoFaces
***Error in face pyramids: 3516 faces are incorrectly oriented.
<<Writing 2678 faces with incorrect orientation to set wrongOrientedFaces
***Max skewness = 170.329678972, 685 highly skew faces detected which may impair the quality of the results
<<Writing 685 skew faces to set skewFaces
Coupled point location match (average 0) OK.
With zero or negative volume cells, FVM won’t solve. Should re-mesh.
Greetings,
Has someone arrived to a solution to this simulation run error?:
“The job execution was aborted, possibly due to a numerical instability. Review the log to identify reasons: unphysically large field values, extremely small time step size, etc. Modifying numerical settings and time step size could resolve the issue.”
My simulation has now failed three times in a row after following the tutorial correctly and the deadline for the homework is in one day.
Here is a link to my project:
Best regards.
Problem solved… It seems, it was problem with export of one feature or what…
I got the same error, the pressure graph had a big fluctuation. I’m re-running the simulation with 6000s on the End Time.
Hello,
I have a problem to run my simulation. It gets into an erro caused by the numerical settings. I configuerd them as the tutrial says. The Error Log says:
pirun noticed that process rank 16 with on node exited on signal 15 (Terminated).
and the event log:
The job execution was aborted, possibly due to a numerical instability. Review the log to identify reasons: unphysically large field values, extremely small time step size, etc. Modifying numerical settings and time step size could resolve the issue.
this is the projekt link. If anyone could help i would be thankfull.
Gereetings Sebastian
Actually, the solver won’t solve the grid you created, because there are zero/negative volume cells.
Checking final mesh ...
Checking faces in error :
non-orthogonality > 75 degrees : 2508
faces with face pyramid volume < 1e-13 : 2026
faces with concavity > 80 degrees : 254
faces with skewness > 4 (internal) or 20 (boundary) : 4
faces with interpolation weights (0..1) < 0.01 : 32
faces with volume ratio of neighbour cells < 0.0075 : 78
faces with face twist < 0.005 : 1770
faces on cells with determinant < 0.005 : 252
Finished meshing with 6924 illegal faces (concave, zero area or negative cell pyramid volume)
Finished meshing in = 1263.4 s.
End
Finalising parallel run
This is your current snap control:
try to follow this page: Advanced Settings for Hex-Dominant Parametric | SimScale
But following that page may or may not solve the problem. You’d play with refinement zones to get rid of low quality cells.
2 Likes
Thank you! That was also exactly what I was doing wrong.
I think that it would be a good idea to include this tip in the Homework description. It is a small mistake that can be really annoying…
Hello dylan,
I tired both. but it didn’t worked. the mesh controll still says that the mesh ist not OK. but what i reconized is that the Eventlog shows this text.
Illegal triangles were found after surface tesselation. There could be a problem with the CAD geometry. Trying to proceed anyway.
2017-01-06 02:17
The tesselated surface is not closed. There could be a problem with the CAD geometry (such as self-intersections). Please inspect your geometry. Trying to proceed anyway.
I checked the cad model multiple times but couldn’t finde the issue, if anyone could take a look at it i would appreciate it.
@Akrem is it possible to hand in anunfinished but hardly tryed homework and still get full credit?
sblock
It might be worthwhile to ask for assignment extension @Akrem , because it seems most people are stuck with a non-watertight CAD. Usually commercial CAD allows geometry check and/or bridging small gaps. I believe the exercise is for people to pick up CFD skills, so it is worthwhile to finish it.
I get the same strange meshes where the edges of my Fronwing end up in these sharp edges. I tried for nearly 12h now to fix it on my own or with the questions previously asked. The simulation won’t run with this mesh. Has anyone another idea how to fix this? Could it be because the wing intersects the cars body?
Here is a link to my project if it helps: https://www.simscale.com/workbench?publiclink=8602e4eb-1d49-4fb3-9fe8-5b32e0454d73
Does the front wing have to connect to the car model at some point? Mine is floating in front of it but should not self-intersect (though there are faces that are butted directly against each other. Is this a problem?)