-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flowfield is not "clean" in 3D test case #20
Comments
I have just tried them now without any issues. |
Yes, I know the effect of restart file, and every time I run in a directory containing only the grid file and configure file. I run the case of DDES of a cylinder, and the result is normal. Then I run DDES of ONERA M6, and the flowfield looks normal. I wonder if there are some errors in parameters in configure file in original test cases. |
I have rerun both DDES and ONERA test problem with the provided DAT files, without any issues. So it is not clear what could be the root of your problem |
The test case is downloaded from "https://doi.org/10.5281/zenodo.3375432", and the ONERA M6 that I tested is located in "TEST/3D/RANS/ONERA_M6". I confirm that the code runs with the DAT file in this directory to get a non-physical result(strange high speed flow region under the wing ), but when I change the "CODE CONFIGURATION" from default value 0 (the DAT file in ONERA M6 case sets 0 ) to 9, the result looks normal. The problem occurs when I compile the code and simply run the ONERA case without any modification of the original DAT file in that directory. So I wonder if you modified something of the original DAT file in "TEST/3D/RANS/ONERA_M6". Now I think I solve the problem, but I think there is a parameter error in the DAT of the ONERA M6 case, and one cannot get a physical result when simply running. |
make sure that you have only three files grid.msh, UCNS3D.DAT and your ucns3d_p. |
Thanks, yes I ensured to keep only these 3 files before beginning the run, when I tried second time. The array index out of bounds error appears when I run with these 3 files. Attached is the UCNS3D.DAT which I used - attaching it as a notepad text file due to GitHub limitations on upload type. |
Hello sir, But it terminates at this point, with almost the same error messages - this time there are no array bound problems, but the simulation gets killed somehow towards this 4530 iteration. I had even changed wall clock time to a much higher value than default 82000 seconds. RESTARTING 0 0.000000000000000E+000 0
UCNS3D Running BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
|
don't copy the entire output message from the code with large fonts for better readability. Please attach the UCNS3D.DAT file used and the history.txt file |
Sorry for that mishap. Yes, I ran the case with just 3 files in the directory - the grid.msh, ucns3d_p and UCNS3D.DAT files. No history/restart files in the directory when run was initiated. Attached is the UCNS3D.DAT file for your reference. The history.txt file is attached. It got generated automatically during the run. Thanks |
Hi! Can someone please help with this thread? The issue occurs when np exceeds a count of 66 or 67, out of the 128 cores in the node (Single thread run). It is very weird, as to why this issue of code termination would occur just beyond a certain np. However, I am able to utilize all 128 procs or cores of the single node, when I use a much coarser mesh for the simulation. Any insights, or advise on how to ensure the fine mesh case also runs smoothly with all 128 procs? |
You need to have clear specification of thread placement over cores, otherwise when using more than 64 if the threads placement is not by default correctly placed in your cluster they might be assigned in one socket (possibly overpopulating the cpu and eventually running out of memory). |
Hey guys. Recently I run test cases of this code, and I meet some problems. When I run 2D cases, the results are qualitatively OK. However, for 3D cases, e.g, "ONERA M6", I found that the flowfield is qualitatively abnormal. There exist some zones with abnormal variables far away from the wing, where the flow should be close to inflow variables. The test cases were downloaded from link given in "README_TESTS.txt", and were run directly with the given mesh and configured file. I wonder if there are some problems in freestream preserving or boundary conditions? Does someone give some ideas?
The text was updated successfully, but these errors were encountered: