When attempting to run the interactive mode of the 'microelectronics' example, the program would crash, however when running the associated 'microelectronics.mac' macro file within my Mac terminal alongside the execute command for the example ( ./microelectronics microelectronics.mac ), the visualize window would pop up, and disappear once the run was ended, however data was available in the output .root file. In an attempt to troubleshoot, I removed the line of code in the 'microelectronics.cc' file that would automatically run the macro file upon the execution of the interactive mode. Upon execution, this yielded the interactive mode, and upon running the commands that are in the macro file one by one (/control/execute vis.mac, etc.), the program would respond well, visualizing the geometry, setting the particle type (proton), setting the particle's energy, and initializing the run, with everything appearing to work just fine. Upon further troubleshooting, it seems as though the existence of the command '/run/beamOn 2' within the macro file is what is causing the crash, as removing it from the macro file results in the smooth operation of the program, whether it be in interactive mode, or in the command-line execution of that command. However, when re I believe this is indicative of a bug within Geant's macro interpreter. This is because all of the commands from within the interactive terminal work fine. The only problem is when macro files are involved. Please reach out if you have any more questions about my problem. Thanks, Conrad
Dear Koichi, please, redirect this problem to me. Vladimir
This error does not appear in linux platforms and is not related to the advanced examples. Koichi, please, could you give a look?
dear Susanna, Koichi, this is advanced example microelectronics. Not clear what is the software environment in the case described in this report. It is well known that macro, prepared for the batch mode not necessary work properly in the interactive mode. A general G4 approach is that example maintainer should provide vis.mac. In this particular case, Damien Lambert <damien.lambert@cea.fr> intended to fix the issue. Vladimir
Dear all, i see the two problems in this example. 1) The default macro name set to microelectronics.mac. This macro executed vis.mac internally. This will create and close opengl window even when application executed in batch mode. I can suggest remove invocation of vis.mac from microelectronics.mac file. Alternatively you can considering to use off-screen driver like TE'S_OFFSCREEN to write graphics to file without creation of graphic window. 2) The second problem related to Mac computers with M1 CPU. If you use opengl graphics driver and put the /run/beamOn NN command in the same macro ( microelectronics.mac in this case ) the application will crashed. This is known problem , the visualisation group working on it. The possible work around: comment out /run/beamOn command and type it later by hand or replace /vis/open OGL command with /vis/ope TSG. The TSG driver not suffer from this error. I would like propose to the developer of this application replaces line 107 in microelectronic.cc with line: UImanager->ApplyCommand("/control/execute vis.mac"); Remove first line "/control/execute vis.mac" from microelectronics.mac macro and remove unused microelectronics.in from the directory of this example and from CMakeFile.txt. Cheers, Igor S.
Sorry, the file microelectronics.in was use as input for Jenkins tests , must be keeping. The name of off-screen driver TSG_OFFSCREEN or TSG_FILE. Igor S.
Hello all I try with putty/xming and it seems that I see sometimes the same problems. Not easy to identify I will try tomorrow on my linux station. Regards Damien
Hello all I tried: * on my linux station -> no pb * on my linux station from a remote linux station -> no pb * on my linux station from a remote windows laptop (with putty/xming) -> pb Regards Damien
I tried on my linux platform connecting from windows with a MobaXterm terminal and I had no problem
Hi Susanna, Demien, it will be strange if you observed the error appeared on new Mac with new Apple CPU cheep only ( see issue #170 ), runnining program on linux and windows. Against putting visualisation commands like /vis/open OGL inside the batch macros is not a good practice and may produce some side effects. The best wishes, Igor S.
Hello all, if you agree, I suggest to add a "#" at the beginning of the line: #/vis/open OGL 600x400-0+0 for my test configurations, it is ok. are you ok with this suggestion? regards Damien
yes, sounds good
either comment or remove
Ok! I will commit this!
In the last git release, the "#" has been already added to the "/vis/open " line into the vis.mac file. So I think, we could consider the 2548 pb fixed, Regards Damien
