Hi
In another thread, we began discussing an issue regarding the name of the folder in which the results of Saturne 2.3.2 were stored
Here the latest comment
"Hello,
Good to know the issue has dissapeared.
But the case directory should be date_time, and not _6 (unless you changed the default behavior in the runcase by adding "--id _6" to the "code_saturne run" command).
Do you always have this behavior ?
Best regards,
Yvan
"
In fact, to test Saturne 2.3.2, i compiled it, then took an exisiting case from another Saturne version, just edited the launch command and/or solver command of the previous Saturne install (to point the new Saturne version) and started to work.
It seems (see the picture):
a. when i start Saturne 2.3.2 with the case's ./SaturneGUI command, the folder's name is date_of_computation_time_of_computation
b. when i start Saturne 2.3.2 from the installation path with ./code_saturne gui then load the computation case, the folder's name is _number_of_computation_since_the beginning
Results folders in Code Saturne 2.3.2
Forum rules
Please read the forum usage recommendations before posting.
Please read the forum usage recommendations before posting.
-
- Posts: 4208
- Joined: Mon Feb 20, 2012 3:25 pm
Re: Results folders in Code Saturne 2.3.2
Hello,
I just managed to reproduce and understand (partially) the bug:
"code_saturne run" must be run from inside a case directory. When not running under the GUI, it will fail when not run from a case directory. When run from the gui, the case has enough additional information not to fail, but has buggy behavior. The GUI should add "cd <case_dir>" to the commands that it runs to fix this.
We'll fix it before 3.0 final.
Best regards,
Yvan
I just managed to reproduce and understand (partially) the bug:
"code_saturne run" must be run from inside a case directory. When not running under the GUI, it will fail when not run from a case directory. When run from the gui, the case has enough additional information not to fail, but has buggy behavior. The GUI should add "cd <case_dir>" to the commands that it runs to fix this.
We'll fix it before 3.0 final.
Best regards,
Yvan