The problem seems semi-random (which is why it is hard to debug), but occurs more frequently on some machines than others (and as we mentioned before, seems related to the latency or type of the filesystem you are using). If we could reproduce it on our machines, it would already have been solved
The file I posted will not change the problem, but hopefully pinpoint exactly where it occurs, so this is why I am interested in your log file... Otherwise, we are stuck with launching directly using the runcase file on some systems...
What exactly do you want me to do/send ? Because I can run a case from the website to be able to post every log you need, it will be easier than using a confidential study where I am not allowed to send information.
The only information I need is the one similar to the one you posted before when you indicated which messages you had with my modified version....
With each modification (debug messages) on my side, if you test that modified version and indicate what message you have in the console, it can help me. There might not be any visible difference in the result, but this is also some useful information....
I don't need the content of other files in this case, since the computation does not even start. Just knowing if files are created in the results directory is enough, so confidentiality is not the issue here (not knowing which process is stuck and having no easy way of knowing is the difficult part for this very specific case).
This bug would probably already be a difficult one if I reproduced it on my own machine, but at least I could iterate more easily and try attaching debuggers. Debugging remotely using messaging is of course much slower, so this is a painful way to debug as it requires many iterations (an I can't guarantee the results), but it might finally be a way to find this elusive bug... So if you still have some patience for a few tests, I'll be happy to continue hunting this bug. Otherwise, for you own usage, running the runcase directly is probably tempting...
I understand that debugging a problem without this problem in front of you must be very difficult so if I can help, just in testing some things, I will. I think it would help other people having the same problem.
So, I had this in the terminal when I tried to run the calculation with the version 4.0.9.
noam@noam-VirtualBox:~/Documents/2-ESSAIS$ code_saturne409 gui wind90.xml
starting command: /home/noam/Documents/2-ESSAIS/SCRIPTS/runcase
entering ListingDialogView.__init__
calling CommandMgrDialogView.__init__
finished CommandMgrDialogView.__init__
connected buttons
before self.proc.start /home/noam/Documents/2-ESSAIS/SCRIPTS/runcase
after self.proc.start /home/noam/Documents/2-ESSAIS/SCRIPTS/runcase
dialog created
finished command: /home/noam/Documents/2-ESSAIS/SCRIPTS/runcase
I also tried this with other versions (5.0.9, 4.3.4, maybe I shouldn't ?) and nothing appeared in the terminal...
in the runcase file, before the "code_saturne run" line, and see whether that message appears (probably not, which is the purpose of the next instrumentation I will suggest, bt at least that test is easy).
I just tried to put echo "I am here" in the runcase but, as expected, it didn't appear in the terminal.
If you need some information to make instrumentation, please ask me.
I added a small tracing call in CommandMgrDialogView, which is to be placed under Base (where BatchRunningView is under Pages).
You should only see an additional message ("call slotReadFromStdout CommandMgrDialogView.") if the code get mixed up between the base class (CommandMgrDialogView) and its adaptation to the man cs_solver run (BatchRunningView), but that in itself would be important information.
I put the file you sent me in the directory Base/ but, when I launch the calculation, the message in the terminal is exactly the same than the message I had before.
Ok, thanks for the feedback. I'm starting to run out of ideas of things to test, but I'll try to check more info on the workings of the PyQt/process/shell interactions and see if there are variants we can try. I'll probably get back to you in a few days...
